Out of curiosity, what methods of initialisation are you confused with?

We have default constructors, copy construction, move construction, braced initialisation and std::initializer_list.

For my part I am working at work on a C++2003 codebase and although I can initialise my C-style array with braced initialisers, I would love to be able to initialise my vector in the same way, but I cannot as it is C++2003. eg.

int myArray[] = { 0, 1, 2, 3}; vector<int> myVector = {0, 1, 2, 3}; // This is impossible in C++03

It may be that the OO implementations you have seen are bad because they don't understand encapsulation or haven't designed their classes from the outside in (i.e., design them interfaces first so that they are expressed from the simple point of view from the vocabulary of the user, not from you who designed the class).

I have worked with horrible C++ that had a hierarchy of inheritance yet failed to understand the point of virtual functions so would cast to child elements from a base class to decide which function to call on the child object, or would have functions in the base class that would dynamic_cast to every possible type of possible child to work out what to do. This was truly horrible. (The correct solution is to use a virtual or pure virtual function on the base and implement this in the children so that the right function gets called). This was within an apparently "object-oriented" system, so if this is your sort of experience I can understand why you would detest it.

The other horrible thing is writing C++ like it is C - pointers everywhere, no understanding or use of RAII, C-style casts everywhere (do you really know better than the compiler what a type is???), writing a million functions to do the same thing instead of a single template function etc. etc. And no const correctness, no use of STL algorithms, putting everything in a C array instead of using the correct STL container for the job, etc. etc. the list is endless

I think people are starting to get annoyed at how how these are all equivalent, and the switch in a lot of books seems to be towards the third version with braces.

    int x = 0; // makes sense
    int x(0); // sure
    int x{0}; // braces?

> these are all equivalent

I'm almost positive that isn't the case. Need to find my copy of Effective Modern C++ and get back to you. It's been a while

except they are not all equal. hence why there's 3 ways to do it.

(Optimizations can change things, but per the spec, they are not the same)

the first creates a new variable with a default value and then copies 0 into it. (This is trivial with an int, but not so with a more complex type)

the second case creates x using the copy constructor

the third uses an initializer list, and works similarly to #2

> the first creates a new variable with a default value and then copies 0 into it.

No, no default constructor is invoked. In this specific example, until C++17, a temporary int object is created then x is copy constructed from it [1]. The compiler is explicitly allowed to omit the temporary+copy and directly construct from the parameter as per int x(0), but the constructor must be non-explicit.

From c++-17 on this is actually required and additionally a copy constructor is not required to exist. In practice is equivalent to #2 except for the non-explicit requirement.

Pedantic, I know, but as long as we are trying to clarify the rules is better to be clear.

[1] note: is different from default initialize then assign.

As a C++ programmer I'm more annoyed that they're not equivalent.

> One of my largest gripes making the switch, is the OO paradigm.

C++ supports object-oriented programming, but OO is not intrinsic to the language. OO is just one of the many tools. You can write good functional and procedural C++. If you try to shoehorn every problem into the OO model, you're probably doing it wrong.

From the Bjarne Stroustrup himself:

http://www.stroustrup.com/oopsla.pdf

and again here:

https://isocpp.org/blog/2014/12/myths-1

"C++ supports OOP and other programming styles, but is deliberately not limited to any narrow view of “Object Oriented.” It supports a synthesis of programming techniques including object-oriented and generic programming."

Classes get useful once you're tired of adding "this" pointers to all your "methods" and all the "this->" inside them...

Once a C program gets large enough, it seems to become rather "OO" naturally: there's going to be data grouped into structures, and code that operates on that data. That's what classes and methods are useful for. But you don't have to obsess over "forcing" your design to be OO, i.e. things like debating between A.foo(B) or B.foo(A), because sometimes foo(A,B) or even foo(A,B,C) is the answer.

I agree completely with the complexity argument --- and I'll add that hidden ("encapsulated", "abstracted", whatever you want to call it) complexity is still complexity that can get in the way of debugging and efficiency both in terms of machine and programmer time. The latter point is something that a lot of "modern C++" seems to miss, finding more complex ways to do simple things, which look simpler on the surface but are actually far more complex in total.

> Once a C program gets large enough, it seems to become rather "OO" naturally

Very well put. One of my current projects started in plain C but gradually evolved to the point that it just "became" a C++ project. Once you write the same code a few times in a few different places, it's blindingly obvious what would be would be less painful if represented as objects. And so on with other language constructs (inheritance, templates, etc.).

The main point I'm trying to get across is to let it happen naturally, instead of trying to force everything to become objects and methods. There will still be parts that are "not OO", but they are not OO because they don't need to be; and that's perfectly fine.

> It's like they just keep adding new ways to do things, for no other reason than because they can. What's wrong with only have one way to do simple things like that?

Precise control over those things is a feature in C(++).

If you weren't unfortunately forced to use C++, a principle of Python is to (try to) have one obvious way of doing things. https://www.python.org/dev/peps/pep-0020/

We need a book with modern best practices like what happened in the Javascript world with "JavaScript: The Good Parts" from which we can glean a clean effective dialect, leading to a new C++ uptake and renaissance similar to what happened in the Javascript world in 2008

"JavaScript: The Good Parts" is outdated and should be no longer recommended. Even when I was first reading this book I had issues with some parts (adding methods to global classes, module pattern)

2008 revival in JS is not because of this book but from node.js, npm, jQuery and browsers becoming more capable. There where other factors like that fact that there is no alternative to JS on client side and HTML was lagging behind before HTML5. Both Java Applets an Flash become abandomware leaving no alternatives.

There is Rust, there should be stronger push towards this language. C++ is like PHP even with heroic efforts cannot be fully fixed. There is too much cruft, arcane syntax, platforms compatibility issues and finally lack module system.

They're not really equivalent, but Scott Meyers' series of books on C++ are some of my favorite technical writing ever, and his most recent book "Effective Modern C++" should be on the shelf of every working C++ programmer.

I agree with this - I finished reading this just before last year and I cannot recommend this book enough. It really is excellent (including topics like reference collapsing, type deduction in different scenarios, idiosyncrasies of async tasks). A great book and essential.

I don't think it will ever happen, at least in the enterprise space.

Companies are quite happy to use more productive, safer, languages like the ones on top of JVM and CLR, with C++'s role being left to infrastructure code.

The OSes and tooling from Apple, Google and Microsoft are good examples of it.

C++ is there on the lower levels, for hardware support, low level graphics, language runtimes but everything else ends up in Objective-C, Swift, Java, VB.NET, C# and F#.

From all those OSes, UWP is the only one where C++ enjoys parity with the remaining languages and apparently isn't that much used.

Even Microsoft does most of their UWP presentations in C# and despite in ongoing work in C++/WinRT as C++/CX, I doubt it will change the situation that much.

There you go: https://en.wikipedia.org/wiki/The_C_Programming_Language

"However, no new edition of The C Programming Language has been issued to cover the more recent standards."

The book should be read by every C programmer, but it is really outdated and has many bad practices including buffer overflows etc. in examples. For learning "good parts" it certainly isn't the right thing.

Which section(s) contain buffer overflows? Also, do you remember the details on any other bad practices from the book? Thanks!