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

21–30 of 187 posts

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

#21

Post by deaddodo »

Someone wrote: post #4
JonathonW wrote: post #3

Earlier quoted context omitted.

The author also seems to really, really want C++ to be Python, despite that they're completely different languages for completely different purposes that make completely different sets of design tradeoffs. In that respect, the author probably wouldn't be happy with modern C++, either. For example, C++ is never going to be a garbage-collected language (by default, at least). Modern C++ gives you better tools to deal w…

I’m not aware any exist, but implementations of C++11 can have garbage collection by default. https://isocpp.org/wiki/faq/cpp11-library#gc-abi : ”Garbage collection (automatic recycling of unreferenced regions of memory) is optional in C++; that is, a garbage collector is not a compulsory part of an implementation. However, C++11 provides a definition of what a GC can do if one is used and an ABI (Application Binary…

That's not "by default". The compiler doesn't provide it, the language provides for you as the developer using the language to implement your own (or use a third-party) GC and utilize it. D and Rust both offer the same amenities and are not "garbage collected" languages.

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

#22

Post by asdfasgasdgasdg »

That C code wouldn't work if the strings in the map are mutable (which they are in C++). It wouldn't work if the strings were allocated dynamically either. Once you write all the code required to get it working that way, the C starts comparing less favorably to C++.

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

#23

Post by UncleMeat »

downerending wrote: post #15
jfkebwjsbx wrote: post #8

Earlier quoted context omitted.

That is the point of backwards compatibility. It is a feature, not a bug. Whether that feature is a good idea or not and to what degree, is the question.

I'm not saying it's a bug. I'm saying that backwards compatibility means that you still have to deal with all of the historic flaws of the language today . The article is indeed still relevant.

But that’s true for literally everything. If you have a cpp code base and are building new stuff in rust to interop then you still have legacy cpp code even though rust has fewer problems.

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

#25

Post by nineteen999 »

AtlasBarfed wrote: post #24

"C++ isn't a language, they say, it's a language construction kit! Build the language of your dreams in C++! And it'll be portable and scalable and fast and standardized!" This is the power and achilles heel of Lisp as well.

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

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

#26

Post by DenisM »

Quekid5 wrote: post #6

I certainly agree that Modern C++ is vastly bett... actually this is just someone posting an old polemic and trying to stir resentment/controversy. IGNORE THIS CRITICSM OF C++ ... there are much better and more relevant ones which are worth taking seriously. This is not worth taking seriously. (I wonder how many of these posters are real or fake. Given the karma and post of this poster I'm inclined to... wait. Last c…

From the rules:

[...] Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. [...]

https://news.ycombinator.com/newsguidelines.html

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

#27

Post by dana321 »

saagarjha wrote: post #17
dana321 wrote: post #7

C++ is mostly an abstraction layer over C. I would rather use C++ because i would have the option to use abstractions like std::map, std::string, std::vector, std::any etc. as they would save a lot of time and code complexity. IMHO the worst thing about using C/C++ is getting other libraries to play with your project well even if you are using cmake or vcpkg, its not enough. You have to have solid knowledge of each o…

> C++ is mostly an abstraction layer over C. That depends on how you write it. It’s possible to write C++ that bears no semblance to C whatsoever. (I have done so for effect; I once assigned some students to write a C program but wanted to provide a reference implementation with source so I gave them one in C++ that wouldn’t translate directly at all.)

Internally, i mean, thats how it was originally built and it generates code much in the way that C would, if you would have manually coded it. Maybe not jump on my head without thinking first!

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

#28

Post by TheOtherHobbes »

nineteen999 wrote: post #25
AtlasBarfed wrote: post #24

"C++ isn't a language, they say, it's a language construction kit! Build the language of your dreams in C++! And it'll be portable and scalable and fast and standardized!" This is the power and achilles heel of Lisp as well.

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?

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

#29

Post by Quekid5 »

DenisM wrote: post #26
Quekid5 wrote: post #6

I certainly agree that Modern C++ is vastly bett... actually this is just someone posting an old polemic and trying to stir resentment/controversy. IGNORE THIS CRITICSM OF C++ ... there are much better and more relevant ones which are worth taking seriously. This is not worth taking seriously. (I wonder how many of these posters are real or fake. Given the karma and post of this poster I'm inclined to... wait. Last c…

From the rules: [...] Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. [...] https://news.ycombinator.com/newsguidelines.html

That's fair... but how exactly are we to call out these abuses otherwise? (Without having a trivially traceable e-mail address.)

Maybe it's an idea for a new "button" other than spam/flag/etc..

FWIW, I think I backed up my accusation adequately for at least a mod review.

EDIT: To be even more meta... I sense a certain pattern in your comments, sir. What gives?

EDIT#2: Love your retaliation by downvoting totally unrelated comments, btw. Wtf?

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

#30

Post by cmroanirgo »

Rusky wrote: post #18
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…

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…

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 too hard to grok the stack when debugging. We ended up with less memory fragmentation, less dangling ptrs, etc etc. In the rare case there was something in STL that was actually cool (or faster, which was very rare), we'd gut it and reef out the part that was cool to use in our implementation.

I presume these comments aren't popular (sorry about that, but this is during 90s and early 00s when dev cycles were clearly different). Eg. We had string classes in all different flavours, some would interop, some wouldn't. Eg. We had tree and hash classes that, while templateable, had a few core implementations that made compilation fast. We had various ptr management systems (ref counted, stack based, etc).

We made STL between verboten in all APIs because we been burnt so many times using (/trying to use) other ppls APIs that exposed STL in its library. (We were exclusively a windows shop, if that helps understand my confusion... PS. I'm retired these days and have been out of the c++ game >10yrs)

Post reply on HN