V8pp: Header-only library to expose C++ classes and functions into V8(github.com)
github.com
V8pp: Header-only library to expose C++ classes and functions into V8
https://github.com/pmed/v8pp
8 comments
I wish all of these C++ template metaprogramming-based javascript binding generators would standardize into a single API. Embind is another one for use on the client side: http://kripken.github.io/emscripten-site/docs/porting/connec...
I'm the author of v8pp. Thanks for the link, didn't know about Embind.
BTW, contrary to popular believe in certain C++ circles 'header-only' isn't a hallmark of good design. Header-only means implementation-only programming without separation of interface and implementation (the implementation is the interface) using the built-in macro language called templates. Not surprisingly, this style of C++ programming has been successful in academic rather than real-world programming.
Header-only often is just a consequence of templates using. There is no other way in C++ yet.
Sure, you can use v8 (as described in its Embedder's Guide) without any binding library. But amount of boilerplate code may become unacceptable for a real-world application.
Here is a diff for Node.js addons using node wrapper and v8pp: https://github.com/pmed/v8pp/commit/34c6344bdb1bdf7f0b46db6e...
Sure, you can use v8 (as described in its Embedder's Guide) without any binding library. But amount of boilerplate code may become unacceptable for a real-world application.
Here is a diff for Node.js addons using node wrapper and v8pp: https://github.com/pmed/v8pp/commit/34c6344bdb1bdf7f0b46db6e...
It is a consequence of how templates work and compatibility with C toolchain as a way to get C++ adopted in the early days.
As such you also get into header only libraries for anything template related in the real-world programming.
Maybe if C++17 does get modules, eventually header-only and pimpl might be a thing of legacy code only.
However even if it does happen, it depends on the final design of modules and developers willing to wait around 4 more years for it[0], instead of switching to something else.
[0] No typo, time for approval plus compiler adoption
As such you also get into header only libraries for anything template related in the real-world programming.
Maybe if C++17 does get modules, eventually header-only and pimpl might be a thing of legacy code only.
However even if it does happen, it depends on the final design of modules and developers willing to wait around 4 more years for it[0], instead of switching to something else.
[0] No typo, time for approval plus compiler adoption
> t is a consequence of how templates work and compatibility with C toolchain as a way to get C++ adopted in the early days.
Not at all! It's a programming style, nothing else. Compare this "Header-only library to expose C++ classes and functions into V8" to the real V8. The latter doesn't use 'header-only', template-only C++. Why? Because Google cannot do it? No, because it makes no sense for real-world programming.
Not at all! It's a programming style, nothing else. Compare this "Header-only library to expose C++ classes and functions into V8" to the real V8. The latter doesn't use 'header-only', template-only C++. Why? Because Google cannot do it? No, because it makes no sense for real-world programming.
I didn't bother to read the contents of the library and was just stating the fact that in the real world header only libraries are usually a consequence of heavy template use, e.g. boost.
Interesting to me as a native node.js addon author (nanomsg), but I'm more concerned with the upgrade cost; NaN seems to suit me well in this regard.