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

91–100 of 187 posts

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

#91

Post by kllrnohj »

pjmlp wrote: post #89
kllrnohj wrote: post #88

Earlier quoted context omitted.

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.

> 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 other dependency. They don't provide it, they don't care. It can even be quite a pain in the ass to use the "native" STL of a given compiler, like trying to use libc++ with Clang on most Linux distros.

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

#92

Post by klingonopera »

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

> To the contrary, modern C++ has solved very few, if any, of the problems described in the article. The author, after a long and dubious appeal to authority, claims that: * C++ exceptions are outright evil and should be avoided * C++ string class "is so utterly godawfully stupid" because it has no garbage collection or refcounting, and in short doesn't precisely match Python's implementation. He also felt personally…

> "Using the "+" operator with two string constants gives a weird compiler error about adding pointers?"

He'd have that in C too, and that's the expected behaviour. What he would want is:

  #define STRING1 "hello"
  #define STRING2 "world"
  const char* gString = STRING1 " " STRING2 "!\n";
  #include 
  int main() {printf(gString); return 0x0;}

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

#93

Post by adev_ »

TheOtherHobbes wrote: post #28
nineteen999 wrote: post #25

Earlier quoted context omitted.

Difference is, C++ actually has more than single digit mind/marketshare outside the safety of the HN eggcup.

Market share, maybe. Mindshare - Lisp has its zealots. C++ is tolerated rather than adored, because it's more of a Katamari Damacy of stray CS than a language with a coherent focus. How many other languages have a Turing complete sublanguage built into them just to handle templating?

> Mindshare - Lisp has its zealots. C++ is tolerated rather than adored

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” ― Bjarne Stroustrup

A language does not need to be adored, it just need to do the job and have users.

Every language has its quirks, if they are not obvious enough, it just means your language is too young for now.

Languages/Frameworks with their zealots, evangelists and fanatics are generally the ones that will probably disappear in less than 10 years.

"coherent focus" (often mean dictator driven) never survives the test of time.

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

#94

Post by pjmlp »

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…

Only ISO C++ compliant platforms matter.

As having multiple implementations to choose from, that is the beauty of language standards.

Abseil and boost do not fall under that umbrella, and I belong to the C++ subculture that never ever touched them, or plans to.

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

#95

Post by AstralStorm »

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.

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

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

#96

Post by AstralStorm »

klingonopera wrote: post #92
rumanator wrote: post #78

Earlier quoted context omitted.

> To the contrary, modern C++ has solved very few, if any, of the problems described in the article. The author, after a long and dubious appeal to authority, claims that: * C++ exceptions are outright evil and should be avoided * C++ string class "is so utterly godawfully stupid" because it has no garbage collection or refcounting, and in short doesn't precisely match Python's implementation. He also felt personally…

> "Using the "+" operator with two string constants gives a weird compiler error about adding pointers?" He'd have that in C too, and that's the expected behaviour. What he would want is: #define STRING1 "hello" #define STRING2 "world" const char* gString = STRING1 " " STRING2 "!\n"; #include int main() {printf(gString); return 0x0;}

If you make them string constants rather than character arrays with the new literal ""s added in C++14, problem is gone. Author is using outdated C++.

This is all due to C compatibility.

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

#97

Post by fctorial »

pjmlp wrote: post #87
fctorial wrote: post #85

Earlier quoted context omitted.

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.

Java apps are actually pretty small in size. It's the assets that make take up the most space, and that is independent of language.

App installation is a one time cost anyways. Did you mean s/download/startup/?

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

#98

Post by klingonopera »

AstralStorm wrote: post #96
klingonopera wrote: post #92

Earlier quoted context omitted.

> "Using the "+" operator with two string constants gives a weird compiler error about adding pointers?" He'd have that in C too, and that's the expected behaviour. What he would want is: #define STRING1 "hello" #define STRING2 "world" const char* gString = STRING1 " " STRING2 "!\n"; #include int main() {printf(gString); return 0x0;}

If you make them string constants rather than character arrays with the new literal ""s added in C++14, problem is gone. Author is using outdated C++. This is all due to C compatibility.

Ah, yeah... no clue about C++'s strings, I just read his question and that sounded familiar to the problem, whose solution I posted above.

There's some overlap between C and C++, but maybe this wasn't such a case? Sorry, if it was uncalled for.

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

#99

Post by steerablesafe »

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…

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

AFAIK unordered_map is the most awful of all standard containers.

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

#100

Post by Munksgaard »

AnimalMuppet wrote: post #64
TheOtherHobbes wrote: post #28

Earlier quoted context omitted.

Market share, maybe. Mindshare - Lisp has its zealots. C++ is tolerated rather than adored, because it's more of a Katamari Damacy of stray CS than a language with a coherent focus. How many other languages have a Turing complete sublanguage built into them just to handle templating?

I don't know about templating, but... is Haskell's Hindley-Milner type identification system Turing complete? For that matter, Lisp's macros are definitely Turing complete, and they are... a templating system on steroids, maybe? About mindshare: Lisp has zealots, but they are few, even if they are loud, and they are on HN more than many other places. C++ is perhaps not loved, but in some circles it is very well respe…

The beauty of Lisp's macros are that they're specifically _not_ expressed in a separate language: They're ordinary Lisp expressions that work directly on the AST.
Post reply on HN