4 ms·
By memory allocation I meant memory usage by the compiler itself. Plus libstdc++ which is not easy to get rid of, and if you do dump it, you at least cut off C+
by mojuba 15y ago
By memory allocation I meant memory usage by the compiler itself. Plus libstdc++ which is not easy to get rid of, and if you do dump it, you at least cut off C++ exceptions.
I once switched from C++ to C because g++ just couldn't handle the module even having all optimizations turned off. That was a huge automatically generated C module with thousands of functions. A rather rare situation but showed very clearly that C++ is not almighty.
- burgerbrain 15y agoCompiler speed/memory use are generally entirely irrelevant with embedded stuff. If you're natively building on your tiny target instead of cross compiling from your beefy workstation, you're doing it wrong. No, for the very real issues with C++ in small installations, you will have to look at the language itself.
- mojuba 15y agoBelieve it or not, it was on a beefy workstation (I think the number of functions was tens of thousands actually). Of course I could have split the module or find some other solution, but the thing was, switching to C solved the problem. More importantly, I was able to switch on compiler optimizations.
- burgerbrain 15y agoI am not getting what makes this any different from any other very large build then.
- mojuba 15y agoThe size of a single module with say 50,000 automatically generated functions 3 to 10 lines each. You want to try it? ;)