Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You can't make C++ not ugly, but you can't not try (2010)

apenwarr.ca

Post reply on HN
Print view View original

131–140 of 187 posts

Re: You can't make C++ not ugly, but you can't not try (2010)

#131

Post by 2zcon »

tonyedgecombe wrote: post #112
rumanator wrote: post #84

Earlier quoted context omitted.

> which means that in the real world you have to learn and deal with all of it. That makes as much sence as claiming that to develop software in, say, Python on the real world you have to learn and deal with all of its standard library. That is not the case. That has never been the case ever for any programming language, be it large or small. Specially in C++, where since it's inception the standard approach is to, a…

Making a language so big and complex that you can't expect to understand it all isn't a good idea. You might be able to get away with using 50% of the language but if some project you depend on uses a different 50% then you have a problem.

OK but if you're a competent, adult software engineer it should be fairly easy to overcome that problem.

Re: You can't make C++ not ugly, but you can't not try (2010)

#132

Post by gpderetta »

> The problem is that the default C++ string class is so utterly godawfully stupid. No garbage collection? Check. No refcounting? Check.

the irony is that in 2010, many std::string implementations were in fact reference counted (including libstdc++). This was generally considered a major mistake (because it doesn't work well with threads and when it does is a major performance pitfall) and prohibited in C++11.

Re: You can't make C++ not ugly, but you can't not try (2010)

#133

Post by kouteiheika »

gpderetta wrote: post #113
kllrnohj wrote: post #57

Earlier quoted context omitted.

You have that backwards. The STL containers are for when you have a hyper-specific niche use case. They are otherwise terrible defaults and everyone should use boost or abseil by default otherwise. std::map, for example, is only appropriate if you need a red-black tree specifically. Which almost nobody does. std::unordered_map is less awful, but abseil has a literal straight upgrade. With the same API. So... why woul…

on the contrary, std::map is a good default container with predictable performance. If you need fast O(1) look up std::unordered_map is really not fit for purpose and requires you to come up with an hash function.

> on the contrary, std::map is a good default container

If you care about performance then it's not. (And if you don't care about performance then why are you using C++?) The standard requires that `insert` will not invalidate iterators, which basically forces everyone to implement `std::map` as a red-black tree, and those are pretty bad performance-wise on modern hardware mostly due to cache misses.

> If you need fast O(1) look up std::unordered_map is really not fit for purpose and requires you to come up with an hash function.

Modern hash table implementations (along with a modern hash function) are exactly what you should use if you need fast average-case O(1) lookup, so I'm confused why would you say that it's not fit for purpose? Unless you specifically meant only `std::unordered_map` which, yes, is pretty atrocious performance-wise (again, due to the iterator invalidation requirements).

Re: You can't make C++ not ugly, but you can't not try (2010)

#134

Post by taejo »

kccqzy wrote: post #73
cmroanirgo wrote: post #30

Earlier quoted context omitted.

If everyone can forgive my ignorance... I used to call everything in the std:: namespace as just that, the standard template library (STL) (whatever it's iteration). So is this C++03 /C++11 stuff just updates to this library, or is std::string recognised at the compiler level? (Genuinely confused). (In old man voice) We ended up rolling out own stuff and marking std:: verboten. Why? Stl was too slow, too verbose, and…

That is indeed a very different time. I believe in the 90s the STL was considered too radical in its use of templates to be practical. People's perception has come a long way. Heck, instead of sane std::list people used to do intrusive linked lists by having T inherit from a linked list base class. What a terrible idea.

Do people use std::list? I can't think of a time when I've needed a non-intrusive linked list (either vector is better or I need an intrusive list).

Re: You can't make C++ not ugly, but you can't not try (2010)

#135

Post by pjmlp »

gpderetta wrote: post #122
pjmlp wrote: post #76

Earlier quoted context omitted.

Actually C++11 introduced a GC API.

It seems to me that just a couple of do nothing placeholders were added to please Hans Boehm and get him to work on the c++ memory model :).

Even so, there are the .NET, Unreal and COM/UWP programming models as well, which while not taking advantage of C++11 GC, do bring a GC into C++ world. :)

Re: You can't make C++ not ugly, but you can't not try (2010)

#136

Post by nmeofthestate »

gumby wrote: post #2

This decade old article describes an ancient and obsolete language (C++03 probably though some of the text suggests it might be C++98). It's not worth reading in 2020. Modern C++ is a very different language though it can still almost completely interoperate with quite old code. C++11 and C++14 already addressed most of the things brought up, and contemporary C++ (obviously most code is not in it yet) even supports g…

True - some of the specific problems have been handled, but C++ is still kind of a disaster. The language has got even more complex in many ways. Some coders like that and get really into understanding the byzantine complexities, so the codebase inevitably gets dragged into unmaintainable, hard-to-debug cleverness. From my experience, C++ development is getting better, largely because tools are getting better at hand-holding and pointing out all the foot-shooting mistakes you can and do easily make on pretty much every line.

Maybe C++30 will have fixed everything...

Re: You can't make C++ not ugly, but you can't not try (2010)

#138

Post by leetcrew »

mehrdadn wrote: post #127
kllrnohj wrote: post #57

Earlier quoted context omitted.

You have that backwards. The STL containers are for when you have a hyper-specific niche use case. They are otherwise terrible defaults and everyone should use boost or abseil by default otherwise. std::map, for example, is only appropriate if you need a red-black tree specifically. Which almost nobody does. std::unordered_map is less awful, but abseil has a literal straight upgrade. With the same API. So... why woul…

Small vectors break iterator guarantees, for one thing. They also really only make sense for tiny objects (ints, etc.) given you don't want a pickup truck's worth of data on your stack. They're most definitely not general-purpose. There are lots of subtleties STL containers have to worry about in designing containers, regarding everything from iterator & pointer invalidation to allocation and allocator propagation. A…

how do small vectors break iterator guarantees?

Re: You can't make C++ not ugly, but you can't not try (2010)

#139

Post by leetcrew »

steerablesafe wrote: post #99
kllrnohj wrote: post #57

Earlier quoted context omitted.

You have that backwards. The STL containers are for when you have a hyper-specific niche use case. They are otherwise terrible defaults and everyone should use boost or abseil by default otherwise. std::map, for example, is only appropriate if you need a red-black tree specifically. Which almost nobody does. std::unordered_map is less awful, but abseil has a literal straight upgrade. With the same API. So... why woul…

abseil's might have a similar API but it's most definitely not the same (function signatures looking the same doesn't make it the same API). Some of the standard containers can't be fast because too strict/specific standard requirements, not because they don't try hard enough. Having said that I think using abseil's containers is reasonable, even as a default, if you can afford the dependency. > std::unordered_map AF…

what's wrong with unordered_map? it's at least more useful than map.

Re: You can't make C++ not ugly, but you can't not try (2010)

#140

Post by jimktrains2 »

diegoperini wrote: post #137

Can a native English speaker kindly explain the title? With that many negative tenses, it's really hard to parse the motivation of the author.

It's in the vein of "even if you can't do something, you should to try anyway"

Not ugly is more of a less strong "pretty" and can't not is more of a "should" (rather than "can"), so the title can be read as "you can't make c++ pretty, but you should try (to make it pretty)".

Post reply on HN