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

51–60 of 187 posts

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

#51

Post by dang »

Quekid5 wrote: post #46
DenisM wrote: post #44

Earlier quoted context omitted.

The rules I have previously posted contain the answer to your first question.

EDIT: Please don't be opaque about this stuff. Post an exact link to the ToC (or whatever) I violated if you truly want to be held accountable. I'm not even on a I-want-to-an-a-hole crusade here[0], but HN has a serious lack of accountability and transparency about this. I contend that it's full of shills, but I have yet to prove that, which I acknowledge. Anyway, I flagged it. I'd delete my post if I could. Wait, I…

Insinuations of astroturfing or shillage are the commonest toxic internet trope around, and we don't allow them here without evidence. People feeling differently about C++ doesn't count as evidence of anything other than that programmers feel differently and identify with different things.

I've posted hundreds of times about this, so I don't think it's true that HN has a lack of accountability and transparency about it. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...

Could you please review and respect the rules here? You've broken quite a few of them in this thread.

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

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

#52

Post by dang »

Quekid5 wrote: post #14

This is (robo?) spam (try the 'past' link), and the user should be permabanned. Sad to say, but...

That's inaccurate. Not only are reposts fine after a year or so (see https://news.ycombinator.com/newsfaq.html), we invited this repost. We do that sometimes: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu....

Please stop posting like this to HN.

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

#53

Post by badcede »

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.

Lisp gets there by being simple and having the optimal notation for it.

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

#54

Post by dheera »

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…

Yep. There isn't even a split/join method in std::string ... you need to use boost for that (wtf)

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

#55

Post by kevin_thibedeau »

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…

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.

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

#56

Post by saagarjha »

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.

I think this transcends comment enabled websites.

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

#57

Post by kllrnohj »

vlovich123 wrote: post #47
kllrnohj wrote: post #37

Earlier quoted context omitted.

> So is this C++03 /C++11 stuff just updates to this library, or is std::string recognised at the compiler level? std::string is in the STL. So is std::string_view. There are language changes as well that enable some of the new STL additions but some are just STL updates and you could "backport" them so to speak. Or do the same thing but yourself. Making std:: verboten these days would likely be a mistake, though. Th…

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 would you pick the slower thing when you're using C++? std::vector is only really appropriate if you know you never have small vectors, which is again a more obscure situation.

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

#58

Post by PaulDavisThe1st »

unlinked_dll wrote: post #9

Most of what the author complains about w.r.t callbacks is fixed with std::function and lambdas (member function pointer syntax is necessarily weird, because methods aren't just normal functions). I definitely don't miss the days of std::bind. Nowadays you just do something like using Callback = std::function ; // or whatever Callback cbk = [&](int i) { return instance.method(i); }; I've also seen some real evil hack…

Using lamdba's requires grappling with entirely new syntax compared to anything else in C++ (or C).

Using various bind equivalents just requires you to know what you're doing:

boost::function cbk = boost::bind (&SomeObject::some_method, instance_of_some_object);

...

cbk (22); // invoke callback

In addition, the author's complaints about nobody using ptr-to-method is absurd. Even in 2010, anyone using libsigc++ or its (few) equivalents was using them, which meant that any GUI app written using GTKmm was full of them. What's not to love?

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

#59

Post by BooneJS »

dheera wrote: post #54
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…

Yep. There isn't even a split/join method in std::string ... you need to use boost for that (wtf)

Or Abseil, which had a lot of handy string manipulation functions including Append/FormatAppend.
Post reply on HN