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

111–120 of 187 posts

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

#111

Post by rumanator »

kllrnohj wrote: post #91
pjmlp wrote: post #89

Earlier quoted context omitted.

Because STL is part of the compiler, guaranteed to work on every platform supported by the compiler, and does not require lots of paperwork for adoption at many shops.

> Because STL is part of the compiler, guaranteed to work on every platform supported by the compiler No it isn't and no it's not. There are even platforms where an STL isn't even provided out of the box, you have to pick one. And there's quite a few at that - libc++, libstdc++, stlport, etc... But clang, g++, etc... they don't care. To them it's just another library you're linking against, no different from any othe…

> No it isn't and no it's not.

Your assertion is so patently wrong that you either are entirely clueless or you're just trolling.

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

#112

Post by tonyedgecombe »

rumanator wrote: post #84
downerending wrote: post #5

Earlier quoted context omitted.

You wish. Unless I'm terribly misinformed, "modern C++" contains all of the features of the prior versions, which means that in the real world you have to learn and deal with all of it .

> 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.

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

#113

Post by gpderetta »

kllrnohj wrote: post #57
vlovich123 wrote: post #47

Earlier quoted context omitted.

I still think the STL containers are the sane default to reach for & switch to more obscure ones when the problem domain and performance requirements say to use a different one.

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.

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

#114

Post by gpderetta »

AstralStorm wrote: post #95
kccqzy wrote: post #73

Earlier quoted context omitted.

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.

Intrusive lists are so good they are likely to land one of these days in standard. Except via templates and traits not silly unnecessary inheritance. (Boost-like.)

Yes, boost::intrusive is particularly great.

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

#115

Post by pjmlp »

ggambetta wrote: post #104

[The [] operator] is an absolute failure of engineering! Do you want to know what real engineering is? It's this: map_set(m, 5, "foo"); char *x = map_get(m, 5); So like map::insert and map::at? Did these not exist in 2010?

They did.

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

#116

Post by gpderetta »

vlovich123 wrote: post #45
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…

Every new standard incorporates language & library changes. A perfect example of this is r-value references. That was a new language feature in C++11 & was adopted by all the standard library containers & algorithms. Not sure which part of std::string you're referring to but the compiler generally doesn't contain any knowledge of the library itself. It does goes the other way though where the standard library has to…

As non exhaustive list, compilers have have intimate knowledge of:

* various operator new * all the type traits * a lot of the names inherited from the C library

compilers could do much more, but in general they prefer to implement generic optimizations instead of targeting a specific library name (for example removing allocation for stack allocated std::strings was not done until the generic removal of alloc/free was implemented).

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

#117

Post by atq2119 »

vlovich123 wrote: post #45
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…

Every new standard incorporates language & library changes. A perfect example of this is r-value references. That was a new language feature in C++11 & was adopted by all the standard library containers & algorithms. Not sure which part of std::string you're referring to but the compiler generally doesn't contain any knowledge of the library itself. It does goes the other way though where the standard library has to…

> even in Rust I suspect they use builtins in certain places of their standard library.

There are places in the rust standard library which just omit the implementation because it's magically filled in by the compiler based on the type and function names. Which, for really low-level and fundamental functionality, seems fair game to me.

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

#118

Post by rumanator »

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.

IMHO C++ is unfairly singled out with regards to it's extension. That criticism rings true if applied to pretty much every single programming language ever devised, including "small" languages such as C.

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

#119

Post by nineteen999 »

praptak wrote: post #103
nineteen999 wrote: post #36

Earlier quoted context omitted.

> How many other languages have a Turing complete sublanguage built into them just to handle templating? On the bright side, C++ doesn't have obscure keywords like "cdr" and "car" that refer to specific hardware elements of an obsolete computer built in 1954.

Car and cdr are a shallow critique of Lisp, the equivalent of "omg, significant whitespace" critique of Python.

I was aiming for funny and accurate, not deep. Sad, for some, I guess that its heyday is long past, and that it will never ever rise to compete even with C/C++ commercially again, no matter how hard some people kick the dinosaur corpse.

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

#120

Post by gumby »

UncleMeat wrote: post #20
Rusky wrote: post #18

Earlier quoted context omitted.

To the contrary, modern C++ has solved very few, if any, of the problems described in the article. Being generous: * There's now `std::string_view` to address some of the problems with `std::string`, but the rest are still there. There are some attempts to specify the encoding now, at least. * Lambdas and `std::function` pretty much solve the function pointer complaints, with some added complexity. * Containers still…

I think most people agree that operator[] is a big footgun for containers, but rigorous use of const helps at least prevent surprises.

And operator new is hardly used any more in modern C++ code.
Post reply on HN