Re:How fast can you allocate a large block of memory in C++?
by clarry on Thursday January 16, 2020 @02:44AM
(#22062425)
C has changed much less over the years. Arguably C89 was the most important change, C99 brought a bunch of small quality of life improvements (which you might or might not need, arguably the most important are stdint and snprintf), C11 got us a threading model, C17 is a bugfix.. After C89, no new version of the standard really changed the way you write idiomatic C without code smells.
[ Parent
| on HN ]
Re:How fast can you allocate a large block of memory in C++?
by pjmlp on Thursday January 16, 2020 @03:10AM
(#22062541)
Fact is it did change, it even introduced breaking changes, like gets() and Annex K removal on C11.
And you are missing the compiler extensions that I also mentioned.
It did not change even more, because nowadays C is left for UNIX clones and embedded development, having been superseded by other languages on most corporations, even its major compilers have been rewritten in C++.
Re:How fast can you allocate a large block of memory in C++?
by throwaway17_17 on Thursday January 16, 2020 @09:29AM
(#22064801)
I don’t know if parent is ‘missing the compiler extensions [you] mentioned’ or is just not addressing them. But I will take a stab: compiler extensions may be neat/effective/revolutionary, but they are unequivocally not a part of a programming language. That is why they are compiler specific extensions. I could code a compiler extension for LLVM that is a conservative, generational garbage collector and have the extension flag be —-no-more-manual-memory, but no one is then going to say that because that extension exist C++ is a garbage collected language.
tl;dr -> compiler extensions are by definition not part of a language, no matter how useful, and therefore do not count towards the argument.
Re:How fast can you allocate a large block of memory in C++?
by pjmlp on Thursday January 16, 2020 @10:25AM
(#22065341)
C++ supports garbage collection since ISO C++11.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n267...