Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> The true lesson learned for language developers is: Don't break backwards compatibility. Ever.

Certainly true, and yet this is the situation that led to a lot of the hate for C++.

The reason for the numerous meanings of the "static" keyword for example is because if you introduce more keywords then you might break peoples code that used those proposed keywords as variable names.

And then of course a large percentage of C++'s baggage is due to backwards compatibility with C in the first place. Without that baggage C++ would be a much better language and yet you can't deny C++'s success from that decision.

So the moral of the story is that you either make a language nobody uses or you continue to cop flak for all your old decisions forever.



"There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Bjarne Stroustrup


Yeah, life sucks. There's no good solution to all that.

The approach used for new keywords is to use lots of '__' on one end or the other. Anybody that used variables with those names was asking for trouble. Yet, then, the new keywords look like crap. Nobody wins.

My favorite, years ago, was the usage in the normal C header files in Linux of a linked-list variable with the name 'new'. It was obvious that nobody in Linux-land had ever compiled a C++ program.


New C keywords now use a leading underscore (_Atomic, _Bool, _Static_assert, ...) and come with a header file you can include to get a more friendly name (stdbool.h, stdatomic.h, assert.h, ....).

As to not keeping your C code C++ clean: Just use a dedicated C compiler and link the object files.


Then what header files do you compile your C++ with? That's all there was at the time.


If it occurs in public header files or if you use C++ keywords as external symbols, that is indeed a bit... inconsiderate, to say the least.

Header files intended for public comsumption should stick to the intersection of C and C++ in most cases.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: