News for hackers. Stuff that matters.
Re:The C++ Build Process Explained by kccqzy on Thursday November 15, 2018 @01:00AM (#18457221)
> In principle you're right, but the notion that header file exposes just the "interface" is completely false. Class definition, private variables and functions, etc. are all exposed in header file.

If you don't want to expose class internals, just use the PIMPL idiom. It's an extra indirection to protect your own abstraction, so naturally C++ decides to opt for performance by default.

Re:The C++ Build Process Explained by klodolph on Thursday November 15, 2018 @05:21AM (#18458200)
That’s an annoying workaround at best. It’s not necessary in C. It wouldn’t be necessary in C++ if you could declare incomplete class types but still declare their member functions. This would have zero performance impact and improve encapsulation.
Re:The C++ Build Process Explained by jcelerier on Thursday November 15, 2018 @05:45AM (#18458298)
> It’s not necessary in C

sorry what ? most C libraries I know hide their implementations behind opaque types such as `typedef void* my_handle_t`.

Re:The C++ Build Process Explained by klodolph on Thursday November 15, 2018 @10:13AM (#18459823)
Right, I'm saying that's not necessary, you can just do this:

    struct my_type;
    struct my_type *my_type_new(void);
This is more common than `typedef void*` in my experience, because it actually provides some minimal amount of type safety.

You can also do this in C++ of course, but you can't use member functions this way. My real complaint here is that the Pimpl idiom in C++ is more cumbersome than a simple forward declaration and free functions, which is available in C.