C++ was my first language (`94?) and the one I am very passionate about; I worked on the Indiana concepts proposal & variadics for part of my dissertation, and my advisor & his colleagues designed large chunks of what would be C++11.
In my opinion, the very best C++ is plain-old-C that uses modern C++ standard libraries, while carefully controlling the definition of the memory allocator for those libraries.
You can use custom allocators to minimize dynamic allocation. STL now provides some of these allocators out of the box, but it still can be useful to define your own. Arena or memory pool allocators are the first that come to mind.
While I work in a field where such things are necessary (real-time audio programming), I doubt that such things are relevant for someone just starting out with C++...
True, but they would probably use a framework like JUCE which does a great job at hiding the complexity. Writing a VST3 plugin from scratch is not for the faint of heart.
>In my opinion, the very best C++ is plain-old-C [...]
Not to start a debate but just genuinely curious...
Do you avoid writing ~destructors() in C++ to adhere to "plain C" principles?
Imo, destructors (RAII) is one of the killer C++ features. There's a lot of buggy plain C code that has a malloc() but missing the associated free() and/or an openXyz() but missing the closeXyz(). Plain C has to manually write cleanup() functions or code generators to simulate dtors() which is a hassle.
I guess the related larger question is if the "best C++" means avoid writing any classes at all? (E.g. Linux source with plain C uses structs and function parameters to simulate OOP: https://lwn.net/Articles/444910/)
I use RAII via `unique_ptr<>` and friends. I would never have a "bare malloc": all allocation occur as side-effects of using containers, or are stuffed into `unique_ptrs<>`.
Is a perfectly reasonable way to allocate something on the stack and have it unwound at the end of the block. No pointers needed. Perhaps I'm misunderstanding your argument.
`new`, much less `malloc` hardly ever need appear. I'm working in a reasonably large code base that has four uses of new: three hidden in in internal graph node construction and one in a high-performance deserializer (actually that last is in the process of being replaced by code that simply requests pages from the OS). There are very few cases where user code might allocate memory with `new` these days.
unique_ptr<> is a mechanism to give automatic (this is what you mean by 'on the stack') life time to non-automatic objects, like FILE*s, mmap()s, defined results from malloc(), etc. It's not like I'm heap-allocating an int for local use.
IMHO that's a painful level of abstraction to work at.
Yes, 'automatic' variables in C or C++ are just stack allocated objects;, there's nothing about a FILE* that makes it automatic or static. But if you use, for example, streams you can just create one for a file and when it goes out of scope it closes the file and deallocates for you.
Likewise I would make a tiny class for my mmap'ed memory that did whatever cleanup (perhaps searializing data or zeroing pointers into it) before returning the pages to the OS pool. Sure you can write that code into a unique_ptr deleter and pass that in when you make them, or you could just let the compiler do it for you.
I don't use C++ in what would typically be called an "object-oriented" way, but this is a perfect example of where I would create a small class as a way of telling the compiler to do some bookkeeping on my behalf.
unique_ptr<> let's me override its destructor behavior with a function object that's called on the resource. I mostly use unique_ptr<> for 'wild' mmap()s, FILE*()s, etc.
But you don't have to. If you are trafficking in unique_ptr customizations, you are coding The Hard Way. std::unique_ptr is convenient mechanism, not an organizing principle. Make a named class or class template with a member that is a unique_ptr, and traffic in instances of that class, by value.
If you are working with FILE pointers, you are doing things the hard way. Do you have some library that demands you give it a FILE pointer? Otherwise you probably want a std::filebuf. Likely on the stack, or a member of class that provides a more useful abstraction than a raw file.
If you mean using C++ as a "better C" but using the powerful C++ standard library features (Algorithms, Containers etc.) then i very much agree with you. All OO/Generic/Metaprogramming techniques are to be tightly regulated in production code so as not to complicate and obfuscate the codebase. This is one of the reasons that i am cautious and wary of all the "modern" additions in C++11/beyond. Probably my viewpoint may change with time and experience but for now i feel that things have become quite complicated.
The worst way is to emulate Java, putting everything in derived classes with virtual functions, and trafficking in shared_ptr. We call that Java Disease.
Using C++ as a "better C" leaves almost all the potential benefit on the table, leaving you hardly more productive than you were in C. Coding C++ as C++, you can be worlds more productive, making the compiler do most of your work for you, and leaving the bugs behind in the code you didn't need to write.
Not quite what i meant. By "better C" i meant using a "safe subset" of the language without going crazy with all its features which is what i see happening often. Having used C++ since the early 90's i have seen too much incomprehensible and unmaintainable code just because the programmers had learnt a "shiny new technique" from some book and understood it as everything must be done that way(i must admit i too had fallen prey to this disease for a while :-) Thus for example, i have seen code with needlessly deep class hierarchies, design patterns madness, no free standing functions(everything had to be in a class!), complete ban on macros, template and metaprogramming incomprehensibility etc. C++ is powerful but that must be wielded judiciously and responsibly by the programmer which is only feasible with experience and maturity. Thus it is better to err on the side of caution and restrict usage to a well-defined subset of language features.
It is true that you need really good reasons to make virtual functions, or to do metaprogramming. I, also, usually avoid them. I have not made a more than two-level inheritance hierarchy in this millennium. There is no substitute for taste, design sense, or insistence on simplicity.
Stepanov referred to OO as "gook", and has publicly regretted making member functions like size().
But putting types to work for you is a great force multiplier.
In my opinion, the very best C++ is plain-old-C that uses modern C++ standard libraries, while carefully controlling the definition of the memory allocator for those libraries.