Live data from Hacker News

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

apenwarr.ca

11–20 of 187 posts

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

#11

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 .

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.

... but it's worth considering that this is a 'question' from 2010. Just saying...

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

#13

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…

There's also

  Callback cbk = std::bind_front(instance, Instance::method);
in C++20. I'm going to ignore std::bind as it has weird conventions. :)

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

#15

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 .

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.

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

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

Not everything; see for example std::auto_ptr.

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

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

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

#18
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 do silly things when you use `c[..]` syntax with no element there. (Both when trying to insert and when trying to retrieve!)

* The general level of language size and complexity, especially around templates, has only gotten worse. Concepts will finally help in some ways here.

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

#19

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 .

Not everything; see for example std::auto_ptr.

Interesting (and also another thing to know).

Is there a list somewhere of features that have actually been removed from C++? (i.e., that would cause old code to break)

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

#20
post #18
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…

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