Google Wants To Make C++ More Fun

[allquixotic]

How the heck do can you fit anything C++ to the common MSP430? The models we used had 512 bytes of RAM and 16kb of flash, and we had trouble even fitting simple C programs in there.

Even the highest models seem to have at max 16kb RAM and about a meg of flash. That's certainly enough to fit some subset of C++ stl in the flash, but not enough RAM to do anything C++-y.

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.

[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.

[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.

[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.

[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?

[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]

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).

[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.

[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.

[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.