Google Wants To Make C++ More Fun

[strcat]

If you are on Windows, you have Visual Studio.

All I really hear from the guy in the video is that how he likes to do stuff is how stuff should be done.

Me, I like Notepad and kedit and vi, they don't try to impose policy on me.

I use vim for C++, but I make use of stuff like vim-clang-complete (and cscope, which works okay but isn't perfect). I don't see any problem with having good tools available on Linux, especially those that can integrate with someone's editor of choice.

Good autocompletion which gives you quick access to function prototypes, documentation, etc. is great and so are features like jumping to function definitions and context-aware refactoring (instead of just using search-and-replace as a hammer all the time).

[hoohoo]

If you are on Windows, you have Visual Studio.

All I really hear from the guy in the video is that how he likes to do stuff is how stuff should be done.

Me, I like Notepad and kedit and vi, they don't try to impose policy on me.

[mirv]

There's nothing inherent in C++ that makes it slower than C. If your primary goal is performance (even above readability or safety) and your C++ code is slower than your C code, you're probably doing something wrong. What you describe appears to be exactly what Linus said he wants to avoid by keeping C++ developers away: dumb developers that misuse the language (the C++ guy in your example). In this regard, C is usually better than C++.

Edit: everything said, I do consider C a better language for memory constrained platforms (16KB of RAM). If you do use C++, you'll probably end up using a subset that pretty much looks like C, and you will need to keep and eye on all developers to avoid using heavyweight features. Not to mention that it is hard to find good C++ compilers.

I was trying to differentiate between "full C++" and "the C subset of C++" actually. C++ without the "fancy features" is basically C anyway.

[Pseus]

Funny story from my industry experience: a company I worked for developing smartphones in the mid-2000s (our typical reference device had 64 MB of RAM with 128 MB on the near horizon) had a guy within the company who insisted on using C++ more in our code. Our platform was designed around using C and he thought that C++ would improve development speed without hindering performance. Well after a few long years of fighting for C++ he eventually got fired. I think he pushed a little too hard for it and management didn't want him trying to change the company's direction.

Besides, he created a prototype build and flashed it on a device with our base libraries re-implemented in C++, and the performance was about 20% worse. Hardly a compelling argument for C++. And these libraries were designed by a guy with like 15 years of industry experience with C++ working for tons of prestigious tech companies.

That's not to say that C++ is "slow", but it's certainly a bit slower than C, so if we could notice a performance difference on a device with 64 MB of RAM, I can't imagine how you could use it on a device with 16 KB of RAM. Even back in 2007-2008 our SoCs were probably several orders of magnitude more capable than a MSP430, being designed for flagship smartphones and all.

There's nothing inherent in C++ that makes it slower than C. If your primary goal is performance (even above readability or safety) and your C++ code is slower than your C code, you're probably doing something wrong. What you describe appears to be exactly what Linus said he wants to avoid by keeping C++ developers away: dumb developers that misuse the language (the C++ guy in your example). In this regard, C is usually better than C++.

Edit: everything said, I do consider C a better language for memory constrained platforms (16KB of RAM). If you do use C++, you'll probably end up using a subset that pretty much looks like C, and you will need to keep and eye on all developers to avoid using heavyweight features. Not to mention that it is hard to find good C++ compilers.

[Pseus]

Normally, there's not much difference. But if you don't need constructors/destructors, and/or can benefit from realloc, for example, C will win. Not by much, but enough to be worth it sometimes.

I still don't see your point. If you need to initialize data, you will need to do that in C as well (by initializing your data after malloc). If you don't need to initialize your data, you just leave the constructor/destructor out (and avoid using data types that use them).

There's nothing preventing you from using realloc, either. If you need that, you design your class accordingly, and call realloc when needed (you overload new/delete to call malloc and free, or you can use malloc and placement new, for instance).

[mirv]

I'd be hard pressed to take this as a fact. What exactly is worse in terms of performance in C++ dynamic allocation compared to C?

Normally, there's not much difference. But if you don't need constructors/destructors, and/or can benefit from realloc, for example, C will win. Not by much, but enough to be worth it sometimes.

[Pseus]

Memory management with C still reigns supreme over C++ in terms of performance. Always will I think. A project I'm working with has people treating structs + function pointers + hideously_ugly_glue_code as "objects". I want permission to remake a prototype in C++ to see if I can make the code a bit cleaner, but the only features that would help are classes and maybe virtual functions. Not sure what the compiler would produce in the end, but it helps that everything's statically allocated.
Of course, in my case there isn't a whole lot of difference between using C and C++. Once you go to the requirements of larger firmware....well that's still C and some custom assembly routines.

I'd be hard pressed to take this as a fact. What exactly is worse in terms of performance in C++ dynamic allocation compared to C?

[Pseus]

few other things about the type() declaration solution

-The default should be respected.
If the platform cannot full fill the defaults.
The programmer should not be able to use the default type().

-The implementation details about a type should not be about internal representation.
Should not be able to change that.
We work in a higher language for a reason.



-Different meaning, behaviour is a reason for making a new type.


-Working with versions allows me to let both old and new programs work with new infrastructure.
(making new programs work on old things will always be a problem)
This making it possible to get stuff working and make it keep working.

I'm not sure I follow you, what you describe appears to be possible in current C++.

myint<32> a = 3; //32 bits, specialized class template
myint a = 3; //default, N bits

And this is pretty much run-of-the-mill C++, nothing special about it.

[mirv]

Memory management with C still reigns supreme over C++ in terms of performance. Always will I think. A project I'm working with has people treating structs + function pointers + hideously_ugly_glue_code as "objects". I want permission to remake a prototype in C++ to see if I can make the code a bit cleaner, but the only features that would help are classes and maybe virtual functions. Not sure what the compiler would produce in the end, but it helps that everything's statically allocated.
Of course, in my case there isn't a whole lot of difference between using C and C++. Once you go to the requirements of larger firmware....well that's still C and some custom assembly routines.

[plonoma]

few other things about the type() declaration solution

-The default should be respected.
If the platform cannot full fill the defaults.
The programmer should not be able to use the default type().

-The implementation details about a type should not be about internal representation.
Should not be able to change that.
We work in a higher language for a reason.



-Different meaning, behaviour is a reason for making a new type.


-Working with versions allows me to let both old and new programs work with new infrastructure.
(making new programs work on old things will always be a problem)
This making it possible to get stuff working and make it keep working.

- maybe it's a good idea to have the default number of bits very low?
Like 16 bits for int().
please feedback me about this: negative feedback is okay but it has to give a reason for why it is bad: a consequence that would happen.