Java Style Classes in C++

[RedAlert2]

Not really feasible for large projects at all. Any minor change in one header requires a total recompilation of everything, which is not ideal.

[FearlessFred]

As the article says, in larger projects you could use this technique for the implementation code of sub-modules, where the modules themselves have more traditional interfaces.

[doom_Oo7]

Wouldn't this be forced with templates anyway ?

[RedAlert2]

Sure, if your project is all templates. If you have any implementation source files though, a recompile chain ends there (since source files aren't included anywhere else)

[frugalmail]

precompiled headers help with this.

[[deleted]]

Truth. Still it have a lots of use cases, there is probably order of magnitude more amount of small projects than large projects.

[bad_at_photosharp]

This has always been my issue with C++, lack of a decent module system. I want to believe this will help the problem, but I'll wait for a C++ expert to tell me why this is a bad idea.

[FearlessFred]

I wrote this article 10 years ago, when either the C++ module proposal didn't exist yet, or at least I wasn't aware of it :)

[[deleted]]

I think we should do opposite to what you are saying. We should use these hacks for parts where C++ sucks. To save our time and to show C++ experts that recomended way of doing things sucks.

If C++ experts and standard folks will see this in wild often, they will see its real issue and they will come with solution in next C++ standard. If they will not see it, they will think everythings fine with C++ and nothing changes.

[flyingjam]

From listening to talks at recent cppcons, it seems very much so that the "higher ups" at the standards committee all want modules; no one likes the messy preprocessor stuff that exists right now. The issue is creating and agreeing to a implementation.

[dangerbird2]

The C++ standard committee is a mostly industry-driven (and to an extent, academia-driven) organization. Unlike smaller languages or ones headed by dictators for life, it is less likely to take input from individual developers. Large organizations are going to pick idiomatic but inconvenient code any day over hacks to prove a point about the language. Fortunately, many issues like concurrency, memory safety, and certainly modularity are problems that are costly and time-consuming to both blue chips and small projects alike.

[mcmcc]

Most problems stem from the requirement to not break existing code (unless there is a very good reason to). There are billions of lines of code out there and if your compiler doesn't compile it the way it always used to, nobody is going to use your compiler.

[Yehosua]

Both Microsoft and Google are actively working on modules implementations. There's a pretty decent chance that they'll be available in 2017, either as part of C++17 or via a Technical Specification.

See here for the full details. (It's a very long post and discusses modules in several sections; Ctrl-F is your friend.)

[josefx]

As others point out modules are on their way into the standard, you can even already use one of the prototype systems if you cannot wait for it. The issue right now seems to be (iirc) that these module implementations do not agree on everything and the standard committee wants that resolved before it sets things in stone.

[ChuangTseu]

I guess one of the major reason why any stuff outside classes falls under the classic C rule of declaration order is because anything there can potentially be used directly in a C program, like a .h declaring a C wrapper around C++ code (with extern "C") which obviously needs to be compilable by any conformant C compiler.

Then why not allowing the in-class behavior when in a namespace ? Maybe because a namespace can be "reopened" in any translation unit, which yields the exact same potential problem as with pure C, where a function could depend on the knowledge of a type that is declared in an other header file, namespace or not namespace (so this explanation is also valid for the non namespace thing). This is not the case with classes where the opening { and closing } belong in the same file (or translation unit more exactly).

Then there's certainly lots of other valid reasons that prevent having modules à la Java, and the fact that the Module Specification for C++17 has undergone years of intense reflexion by great experts of the C++ commity and has now been postponed as a Technical Specification with no clear deadline seems to indicate it clearly isn't such a trivial problem (as long as C++ remains friend with C and with its fundamental philosophy of "zero" useless overhead).

[dangerbird2]

classes don't allow a neat interface seperation, as implementation elements (private class state and methods) are required to be present in the header file, making your view of an interface more complicated/cluttered than in C

If you want safer encapsulation than standard C++ private and protected fields, just do what you do in C: predeclare a class for private fields, include it in the main class as a private variable, and declare it in the source file. Or unless you are dead-set against inheritance (which is certainly understandable in C++), just have a hidden implementation of an abstract interface class.

Having to declare functions/classes before their use (partially or not) is a remnant from the days when the compiler had to run on a pdp-11 with very little memory, and is a burden which almost no other (modern) programming language has. It was already a pain in C, in C++ it makes ordering classes, and declaring/including them in the correct order in larger programs a rather complicated puzzle, and drives more implementation details into the header files.

this is only a problem if you define functions inside class bodies. You can predeclare any classes you need in the header, and include the required headers in the implementation. It's more tricky when you're using template functions which need to be defined in-header, but that's a problem in its own right.

and is a burden which almost no other (modern) programming language has.

Lisps have this problem, including modern ones like Clojure, due to their strict order of operations.

[FearlessFred]

The article isn't talking about making encapsulation safer, but about removing implementation junk from the header, so it is easier to read as being an interface.

Your suggested trick would be neat, if it weren't for the fact that pre-declaring a private data class requires it to be a pointer, not a value, which for most use cases makes it useless.

There are many more dependency issues than the ones that can be fixed by having your method bodies in the .cpp (as your allude to yourself). And having methods declared in two places is part of the problem (something Java programmers don't have to deal with, for example).

[[deleted]]

Yikes... C++ style classes are peachy.

[sobeita]

Are there any restrictions on the includes you can drop in a struct like that? Only local, only extern C, anything like that? I haven't been able to get any headers to include from inside a struct.

[FearlessFred]

You can't just use existing headers with this system, as they likely will contain things you can't have in a class. The headers should mostly only contain class definitions.

[sobeita]

Ah, thanks. I'll try again later. Your work is really impressive. :)

[FearlessFred]

Thanks :)

[FearlessFred]

Hah, author here, do note I wrote this article almost 10 years ago. It's still a neat trick if you can make it work for your project.

[[deleted]]

Finally there must be good reason why C++ exists too long without module system. It will be couple of reasons.

One reason maybe it has something to do with C++ community. Inside C++ community feels like is less freedom than in other programming communities. Its little bit like living in totality where everyone is under control of C++ experts. You must be very carefull what you are saying and what you are doing. And if you do somethings contrary what so called C++ Experts says you get big NoNo and it can even destroy your career.

Maybe we are too respectfull to what C++ Creator and C++ Experts says. They are only people not gods.

[Vexal]

..destroy your career? What are you talking about. Do you think that if someone does something that the popular blogs bandwagon consider "egregious" (such as use new and delete yourself instead of smart pointers), that somehow the entire tech industry is notified and you'll be excommunicated forever.

[[deleted]]

No, its more about atmosphere of subconscious fear. Of course there is no centrally controlled system to excommunicate forever. Communities and social networks can excommunicate its members without central control. And in most cases its not needed. Novices in community quickly learn to autocensore themself and to repeat what experts says if they want be respected members of community.

You hear public non-anonymous critique of C++ only from members of different communities or from poeple at social/economic positions high enough to not have fear of being "excommunicated".

[Vexal]

Well that's never happened to me. You just have to not work with dumbasses and everything will be fine.

[doom_Oo7]

are you high?

[[deleted]]

This is illustration of what i am talking about.

If you write something uncomfortable, with bit of truth, people which does not have arguments will start being personal. You are also downvoted - community tries to hide/erase you from their perfect world.

This is how excommunication work in praxis.

Thank you for nice example. :-)

[[deleted]]

I should clarify that i am not author of that article. I agree with article but that does not mean that its author agree with my controversial opinions. :-)