Hacker News Reader

Comment by buserror | Hacker News Reader

Well, you CAN do simplified C++. Apple even had their own version of it called 'Embedded C++' (the drivers in OSX are like that) -- basically, remove RTTI, exceptions, templating and a few other bits and you get a C with namespacing, objects, nice context-based stack based objects and a few other nice things, without the bloat.

So, yes technically you CAN write nice lightweight C++; but you won't be able to enforce it in a team, as everyone will need 'their' pet feature of doom to bring back the bloat.

How do I know? Well, I tried for years to do it like that; and eventually I had to give up. Now I do plain C, because it can't be corrupted in the same way.

"But, but, I just #included <vector>!!"

"... What, for a 5 byte constant array?"

"Yeah I know, but the compiler will just inline it!"

View on HN

Or worse:

    #include <boost/fusion/container/vector.hpp>

"Why do we need Boost for this single vector?"

"Well... We're using Boost elsewhere..."

Now we use C. Not C++.

If someone is using a vector for a small array of fixed size in C++, in a place where performance matters, then their knowledge level is so low that you are going to have issues with them no matter what, I'm afraid. Knowing that vector uses the heap is beginner level knowledge.

On the other hand, in C you are stuck with a built in array now. If you pass this to a function that doesn't get inlined, it will decay into a pointer, then inside that function the compiler has actually "lost" knowledge of the size of the array. Now you have to pay for a loop.

In C++ you can pass a std::array by const reference, the compiler knows exactly how big that array is at all times, and for small arrays the loop checks can be eliminated entirely.

Many of the arguments against C++ boil down to: if you're working with a lot of people who have a knowledge level below what I would expect someone with 1 year of good experience to have, then they can make more mistakes. Is the level of developers generally really that low?

To which my answer would be "write your own". Whenever I program in C I always use my own dynamic, bound checked arrays that store their own length.

I am often surprised that many C programmers often don't build their own abstractions. The OpenSSL library is a prime example of this - the same 4 or 5 arguments passed in the same order to hundreds of functions. I am always surprised they didn't just make a struct.

You are missing my point.

It can store it's own length, but the compiler will still not be aware of the length, except in a real local context (i.e. in the same block of code, either actually, or via inlining). So if you decide to loop over your array, you have to pay the price of looping (jumping and comparing).

If you know that you are working with an array of fixed length, and you use a C++ std::array, you can pass this by reference to functions and those functions will know at compile time how long the array is. So you don't have to pay for looping at all; if you do something small in a loop the compiler will unroll it to 3 assignments or what not.

In addition, the reason that C programmers don't build their own abstractions is because C does not have templates. So building your own abstraction either means that it's not very abstract (i.e. restricted to one data type), or you are using void, or macros, or both. These things are all horrible to work with, void based data structures also involve a performance hit. This tilts the trade-off between writing abstraction and single-use code far, far towards the latter.

In C++ you have templates which are far better for writing your own data structure than macros, and have no performance penalty.

Reply on news.ycombinator.com