Hacker News Reader

Comment by eigenbom | Hacker News Reader

From their GitHub page: "ChaiScript is one of the only embedded scripting language designed from the ground up to directly target C++ and take advantage of modern C++ development techniques, working with the developer how they would expect it to work. Being a native C++ application, it has some advantages over existing embedded scripting languages:

It uses a header-only approach, which makes it easy to integrate with existing projects.

It maintains type safety between your C++ application and the user scripts.

It supports a variety of C++ techniques including callbacks, overloaded functions, class methods, and stl containers."

View on HN

> ...modern C++ development techniques...

Shipping header only is really admitting that modern C++ still has a lack of technique, sidestepping the lack of modules and packaging for instance.

The decision to go with a headers-only design is only required if you want/need to provide templates.

Furthermore, it's ignorant to conflate headers-only libraries with a problem or a shortcoming.

Being realistic and admitting that C++ has tooling and packaging issues isn't being ignorant. Quite the opposite.

The fact that Header Only is one of the five bolded features of this project indicates that "modern C++ development" includes basically giving up on many desirable features of software projects. It's probably fair enough, but I wouldn't necessarily hold it up over other less "modern" designs like providing a C ABI, which you can still do with C++ using C++17, following basically all of CppCoreGuidelines in the implementation, using state of the art tooling, etc.

> giving up on many desirable features of software projects

Some C++ libraries are header only because they were designed for highest performance possible.

Classic example is std::sort versus qsort, C++ usually wins because inlining.

My favorite example is Eigen, they use template metaprogramming to save RAM traffic. When you write x=a+b+c for matrices or vectors, the library doesn't compute a+b intermediate vector. That C++ expression returns a placeholder object of a weird type, CPU computes a+b+c in a single loop over them, reading a,b,c, and writing to x.

Features are header only for performance. Entire libraries are rarely header only for that reason. Typically it's more for ease of consumption, but there are other major drawbacks to that approach, like having the widest possible API and ABI, making long term maintenance harder.

For instance, on some platforms system headers use preprocessor variables called "major" and "minor". If your code is in source files, you have strong control over whether you care. If your code is all in headers, your don't since all your code is affected by unrelated textual inclusions.

> having the widest possible API and ABI, making long term maintenance harder.

For cases where it matters, C++ can do that just fine.

Look at Direct3D, DirectWrite, Media Foundation. They're written in OO C++, and they use IUnknown ABI from COM. They're not COM objects, the ABI is the only feature they took from there.

Apparently, C++ library developers don't care enough.

That's what I was saying. I was also saying you basically give up on a stable narrow interface when shipping header only.

> you basically give up on a stable narrow interface when shipping header only.

I agree. But in some cases, you also gain performance not achievable with stable interfaces.

It’s about tradeoffs.

I think modern C++ needs stable ABI and well-isolated modules less than it did 10-20 years ago. 20 years ago people wrote everything in C++. Now C++ lost the majority of the market to higher level and safer languages, it’s only used for components where performance really matters. For such components, runtime overhead of stable ABIs sometimes matters.

> sidestepping the lack of modules and packaging for instance.

I'm tired of that nitpicking. These tools happen to be outside of the language for historical reasons and probably C compatibility. It's not in the language because apparently not enough people care.

And I think that the ideal way is standardizing of the OS package management first, not having a package manager (or several) for each language. But it won't happen for OS business reasons.

Considering modules are a major feature in C++20, I doubt the standards committee considers this language gap a "nit".

There are properties of C++, like textual inclusion, that make shipping and maintaining code hard. Piling up header files and expecting downstream users to understand how the include search path will work is the current approach. I would just label it realistic more than a best practice. If it's a best practice for packaging, that is only because the current options are so disatisfying.

And all of that is basically orthogonal to whether you use a language specific package manager or an OS specific one.

> Considering modules are a major feature in C++20, I doubt the standards committee considers this language gap a "nit".

C++20. __Twenty__, man! In the third decade of the language existing.

But I agree that it helps OS package managers.

Reply on news.ycombinator.com