5 ms·

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

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.

Olipro 6y ago
What use-case are you envisioning where one needs to "carefully control" the allocator for STL types? Your idea of heavenly C++ sounds like my idea of hell.
- hexane360 6y ago
  >Your idea of heavenly C++ sounds like my idea of hell. I'm concerned this may be the definitive C++ experience...
  - ska 6y ago
    True of pretty much all "big tent" languages, I suspect.
- ajoseps 6y ago
  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.
  - spacechild1 6y ago
    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++...
    - ajoseps 6y ago
      Oh yeah, I definitely agree. I don't think it's relevant for someone just starting out. Just wanted to put it out as an example
    - jcelerier 6y ago
      > I doubt that such things are relevant for someone just starting out with C++... you'd be amazed at the amount of people who start learning C++ because they want to write VSTs
      - spacechild1 6y ago
        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.
rramadass 6y ago
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.
- ncmncm 6y ago
  This is only the second-worst way to use C++. 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.
  - rramadass 6y ago
    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.
    - ncmncm 6y ago
      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.
jasode 6y ago
>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/ https://lwn.net/Articles/444910/)
- thechao 6y ago
  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<>`.
  - pooya13 6y ago
    What if the resource is not memory?
    - thechao 6y ago
      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.
      - ncmncm 6y ago
        You can make a world of pain in any language. 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.
carapace 6y ago
Ah, a breath of fresh air. Hat's off to you. I was tempted to say something like "Sure, look at the best C code bases." but that would have been too snarky.
- ncmncm 6y ago
  Good C is bad C++.

Olipro 6y ago

What use-case are you envisioning where one needs to "carefully control" the allocator for STL types? Your idea of heavenly C++ sounds like my idea of hell.

hexane360 6y ago
>Your idea of heavenly C++ sounds like my idea of hell. I'm concerned this may be the definitive C++ experience...
- ska 6y ago
  True of pretty much all "big tent" languages, I suspect.
ajoseps 6y ago
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.
- spacechild1 6y ago
  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++...
  - ajoseps 6y ago
    Oh yeah, I definitely agree. I don't think it's relevant for someone just starting out. Just wanted to put it out as an example
  - jcelerier 6y ago
    > I doubt that such things are relevant for someone just starting out with C++... you'd be amazed at the amount of people who start learning C++ because they want to write VSTs
    - spacechild1 6y ago
      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.

rramadass 6y ago

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.

ncmncm 6y ago
This is only the second-worst way to use C++. 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.
- rramadass 6y ago
  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.
  - ncmncm 6y ago
    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.

jasode 6y ago

>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/ https://lwn.net/Articles/444910/)

thechao 6y ago
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<>`.
- pooya13 6y ago
  What if the resource is not memory?
  - thechao 6y ago
    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.
    - ncmncm 6y ago
      You can make a world of pain in any language. 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.

carapace 6y ago

Ah, a breath of fresh air. Hat's off to you. I was tempted to say something like "Sure, look at the best C code bases." but that would have been too snarky.

ncmncm 6y ago
Good C is bad C++.