Nobody Understands C++: Intro (2007) • Hacker News Board

Re: Nobody Understands C++: Intro (2007)

#51

Post by nurettin » Sun, Oct 29, 2023, 8:25 PM UTC

rewmie wrote: post #49

nurettin wrote: post #21

Earlier quoted context omitted.

> Why is Boost, or any library at all, relevant in a discussion about C++? I don't have a dog in this fight, but I've been following the scene since early 2000s, a lot of boost made it into the standard. FYI.

> (...) a lot of boost made it into the standard. FYI. Some components that have been proposed to be admitted to the C++ standard were also contributed to Boost, but that's about it. There are far more components in Boost that were never even considered for the standard than the ones that were. Nevertheless, the relevant part is that Boost is not nor it ever was C++, or representative of C++. Conflating third-party l…

> Some components that have been proposed to be admitted to the C++ standard were also contributed to Boost, but that's about it.

Reality is: boost libraries were created, widely adopted, and once interfaces stabilized, we got technical reviews from wg21. Not the other way around.

So the point is moot.

Re: Nobody Understands C++: Intro (2007)

#52

Post by lelanthran » Mon, Oct 30, 2023, 6:53 AM UTC

IshKebab wrote: post #26

keikobadthebad wrote: post #2

> The comment in question begins “My take on C++ is that the best programs only use a fraction of the features.” The commenter further states that he is weary of operator overloading and templates. > In my experience, people who make comments like the above tend to be people who think they are C++ experts but who are actually only novices. I do not know the commenter personally, so I’m not trying to say anything abou…

> get just as much done with high quality C in half the time. Bullshit. C++ may have plenty of warts, and sometimes people go way OTT with templates (90% of Boost), but there's no way you're writing code as fast in C as C++ unless it involves no string manipulation, pointers, containers, etc. String manipulation alone is so awful in C that there's no way you're right. But throw in smart pointers, collections, JSON, r…

> Bullshit. C++ may have plenty of warts, and sometimes people go way OTT with templates (90% of Boost), but there's no way you're writing code as fast in C as C++ unless it involves no string manipulation, pointers, containers, etc.

For many of those things, maybe he already has existing libraries (strings, containers) that have been tested in the field?

Sure, it won't make him faster than in C++, but his speedup could come from needing to allocate less cognition to the language and more to the problem he is solving.

Even expert C++ programmers, who have been doing it for decades, still need to lookup language stuff for C++ in the odd corners. Someone who hasn't been focusing on C++ in depth, but has instead been focusing on the problems over their career might be faster in C than in C++.

It's a trade-off (isn't everything?): lookup everything in the language as you develop vs lookup nothing, or already know a lot and develop faster vs know very little and develop slower.

(I use "know" to mean "knowing the language and libraries")

Re: Nobody Understands C++: Intro (2007)

#53

Post by int0x80 » Mon, Oct 30, 2023, 7:33 AM UTC

rewmie wrote: post #50

int0x80 wrote: post #48

Earlier quoted context omitted.

When I mention constructors I am talking about initializer lists and all the subtleties and special cases around them. Basically most of the complexity I mention comes from memory management. It's just a lot of details to know about and keep in your head. It's the price to pay for the flexibility and power. In Java you need to understand references and object lifecycles or you get memory leaks and slow applications.…

> Basically most of the complexity I mention comes from memory management. It's just a lot of details to know about and keep in your head. It's the price to pay for the flexibility and power. That's basically the point: your complain is not really about C++. You're complaining about a computational problem that some programming languages abstract away with a heavy performance tradeoff. Programming languages that allo…

I know very well what it means to care about a memory allocation cost or an atomic operation in a fast path. In some applications though, that is not the dominating performance factor, instead the algorithm dominates. For example, with C++ an manual memory management our application could take something like 58 minutes to run while in Java it would take 60 minutes. The impact of the low level management is entirely insignificant for performance in the big picture in these cases.

The performance comes from the big O complexity. Memory management is a constant factor in the algorithm.