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.
You can't make C++ not ugly, but you can't not try (2010)
11–20 of 187 posts
Re: You can't make C++ not ugly, but you can't not try (2010)
#12Re: You can't make C++ not ugly, but you can't not try (2010)
#13Most 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…
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)
#14Re: You can't make C++ not ugly, but you can't not try (2010)
#15Earlier 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.
The article is indeed still relevant.
Re: You can't make C++ not ugly, but you can't not try (2010)
#16This 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 .
Re: You can't make C++ not ugly, but you can't not try (2010)
#17C++ 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…
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)
#18This 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…
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)
#19Earlier 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.
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)
#20This 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…