91–100 of 140 posts
Earlier quoted context omitted.
The ultimate in garbage collection indeed! Highly recommend reading that short tale! This lore is slowly being forgotten, thanks for that link.
See also https://www.ibiblio.org/harris/500milemail.html (Is there a canonical lore repository for this kind of thing, other than the Jargon file?)
Earlier quoted context omitted.
> "if you're using C++ as a better C you're doing it wrong" As far as correctness and safety goes, this is still true. It's difficult to scale systems-level programming to large teams. C++ gives the opportunity for more explicit semantics and more aggressive compile-time checks. C can scale well and can be used safely, but you need to do a lot more through convention (always call xyz_Create and xyz_Destroy in pairs!)…
Agreed. It's the size and type of the project that determines the choice of language more than the newness of the language. C++ was designed to meet the requirements of certain types of projects that were coming into vogue at the time it was designed. It was not a replacement for C. Some of the structural advantages of C++ over C can be achieved in C by using generative programming for example and building in automat…
Sure it was for Bjarne, that is why he created it in first place.
After being forced to re-write his thesis from Simula to BCPL, he swore never having to deal with such low level languages again.
C with Classes was his solution to not having to write C directly, after he got his job at AT&T.
It was a very bad choice to choose a program based on Glib for this kind of experiment.
Earlier quoted context omitted.
Template instantiation surely only requires type substitution and re-running some analysis though. What makes C++ compilation slow is reparsing headers again and again and again because the C the preprocessor means that every time they are encountered they may have new semantics. The motivation for modules in C++ is similar to that of developing a Binary AST for Javascript, discussed on HN recently.
If modules ever happen, wow, C++ is going to feel like a whole new language. I remember large Pascal codebases compiling in as little time as it took to press the key, and this was in the era of computers with mere megabytes of memory. Turbo C++ was never as "turbo" as Turbo Pascal.
You can get Visual C++ with support for them.
clang has support, but the old style ones
Currently they are already a TS targeted for C++20.
FWIW, Donald Knuth was a proponent of using C over C++ at the time it first came out. He equated C++ with the use of frameworks in writing programs which he thought were a bad idea for the profession as it would dumb it down. C++ does make code reuse a lot easier.
Not really, with ABI issues and compiler incompatibility widely used C++ libs are either header-only, or have an "extern C" version of the public API. Id say C++ makes reuse much harder.
Earlier quoted context omitted.
> As for the "memory leaks" --- I haven't looked at the source, but something whose runtime is very short-lived, like pkg-config, may be very well justified in allocating and never freeing, letting the process exit itself be the "ultimate free". I've seen and done this many times myself. This makes sense, and then somebody has a vision for a use case beyond the original imagination, goes to turn the code into a libra…
That's the classic KISS/YAGNI vs. (not sure if there is an initialism for it) robust extensible modular best practices etc. debate, for which there has been much bikeshed from both sides.
e: it may be worth noting that I can't for the life of me remember what the I and D stand for... clearly I am much more of a KISS kind of programmer.
FWIW, Donald Knuth was a proponent of using C over C++ at the time it first came out. He equated C++ with the use of frameworks in writing programs which he thought were a bad idea for the profession as it would dumb it down. C++ does make code reuse a lot easier.
> C++ does make code reuse a lot easier. Not really, with ABI issues and compiler incompatibility widely used C++ libs are either header-only, or have an "extern C" version of the public API. Id say C++ makes reuse much harder.
2) Being "header-only" is no impediment to code reuse.
Earlier quoted context omitted.
> If C++ ever adopts the Pascal-style "module" extensions that have been kicking around in various proposals compile times could shrink by several orders of magnitude. I'm skeptical. Modules don't avoid the need for template instantiation.
Template instantiation surely only requires type substitution and re-running some analysis though. What makes C++ compilation slow is reparsing headers again and again and again because the C the preprocessor means that every time they are encountered they may have new semantics. The motivation for modules in C++ is similar to that of developing a Binary AST for Javascript, discussed on HN recently.
Really? And I thought that this is why C and C++ headers are typically wrapped in #ifndef-#define-#endif block, so they only produce whitespace after preprocessing on second inclusion.
Earlier quoted context omitted.
> This makes sense, and then somebody has a vision for a use case beyond the original imagination, goes to turn the code into a library and spends countless hours smartening up lazy resource management. That's THEIR problem then. Why should the original author care for that?
> That's THEIR problem then. It is their problem, clearly. > Why should the original author care for that? That's the question. Don't you think it's easy to think of reasons, though? What if the person porting the code to a library was a later version of the original author?
Then they know what they need to add, and can add it now that they need it -- instead of having it slowing them down when they didn't need it