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

81–90 of 187 posts

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

#81

Post by nineteen999 »

ridiculous_fish wrote: post #77
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.

Nope, only trap representations, in case you are using an Itanium for some reason.

Trap representations are an abstraction though, even if IA64 is one of the very platforms where they are used. CAR and CDR are literally named after CPU registers of the IBM 704.

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

#82

Post by rumanator »

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…

> You have that backwards. The STL containers are for when you have a hyper-specific niche use case.

That assertion makes no sense at all. The stl contrainers work very well as basic generic containers that can safely be used for pretty much any conceivable use where performance isn't super critical. I'm talking about cases like, say, you need to map keys to values but you don't really care about performance or which specific data structure you're using. That's stl's domain: robust, bullet-proof implementations of basic data structures that are good enough for most (or practically all) cases with the exception of a few very niche applications.

If you happen to be one of the rare cases where you feel you need to know if a container is built around a red-black tree or any other fancy arcane data structure, and if this so critical to you that you feel the need to benchmark the performance to assess whether you either need to use non-defaults or completely replace parts or the whole container with a third-party alternative... Then and only then the stl is not for you.

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

#83

Post by rumanator »

Tallasatree wrote: post #38
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…

2 people equally confident in their own, completely opposing opinions. Every comment enabled website in a nutshell.

> 2 people equally confident in their own, completely opposing opinions.

Also known as a debate.

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

#84

Post by rumanator »

downerending wrote: post #5
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…

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, at best, adopt a subset of all features and stick with it.

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

#85

Post by fctorial »

Espressosaurus wrote: post #62
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…

Because that way you don't need to haul in dependencies unless you have a real reason. std::function is fine for prototyping, but its size hit is extreme , so in embedded code we use other implementations. But where size and speed doesn't matter? Why bother?

I'll use java where size and speed doesn't matter.

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

#86

Post by pjmlp »

mrpippy wrote: post #68
kevin_thibedeau wrote: post #55

Earlier quoted context omitted.

Some of us still have to use outdated C++ compilers where the ::std namespace doesn't exist and all the modern goodies are but a dream.

Yikes, what platform is this?

I bet some nice embedded platforms making use of Embedded C++ dialect.

https://en.wikipedia.org/wiki/Embedded_C%2B%2B

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

#87

Post by pjmlp »

fctorial wrote: post #85
Espressosaurus wrote: post #62

Earlier quoted context omitted.

Because that way you don't need to haul in dependencies unless you have a real reason. std::function is fine for prototyping, but its size hit is extreme , so in embedded code we use other implementations. But where size and speed doesn't matter? Why bother?

I'll use java where size and speed doesn't matter.

I rather have my phone be fast, without the apps taking ages to download.

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

#88

Post by kllrnohj »

rumanator wrote: post #82
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…

> You have that backwards. The STL containers are for when you have a hyper-specific niche use case. That assertion makes no sense at all. The stl contrainers work very well as basic generic containers that can safely be used for pretty much any conceivable use where performance isn't super critical. I'm talking about cases like, say, you need to map keys to values but you don't really care about performance or which…

This makes no sense. The STL is the specialized containers with obscure performance characteristics & behaviors. Boost & abseil provide the generic, reasonable default ones.

You're arguing it's better to use something that's across the board worse for nearly every user, and by a lot, just because... why? It's slightly more convenient?

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

#89

Post by pjmlp »

kllrnohj wrote: post #88
rumanator wrote: post #82

Earlier quoted context omitted.

> You have that backwards. The STL containers are for when you have a hyper-specific niche use case. That assertion makes no sense at all. The stl contrainers work very well as basic generic containers that can safely be used for pretty much any conceivable use where performance isn't super critical. I'm talking about cases like, say, you need to map keys to values but you don't really care about performance or which…

This makes no sense. The STL is the specialized containers with obscure performance characteristics & behaviors. Boost & abseil provide the generic, reasonable default ones. You're arguing it's better to use something that's across the board worse for nearly every user, and by a lot, just because... why? It's slightly more convenient?

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.

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

#90

Post by kllrnohj »

Espressosaurus wrote: post #62
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…

Because that way you don't need to haul in dependencies unless you have a real reason. std::function is fine for prototyping, but its size hit is extreme , so in embedded code we use other implementations. But where size and speed doesn't matter? Why bother?

> Because that way you don't need to haul in dependencies unless you have a real reason.

These are all largely header libraries. You're already hauling in a dependency, and in every c++ file that uses it at that.

> std::function is fine for prototyping

std::function isn't part of the containers library of the STL (containers being all the stuff here: https://en.cppreference.com/w/cpp/container ). I agree std::function is fine, it even has a pretty reasonable small-size optimization.

Post reply on HN