10 ms·

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

by Rusky 7y ago

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.

UncleMeat 7y ago
I think most people agree that operator[] is a big footgun for containers, but rigorous use of const helps at least prevent surprises.
- gumby 7y ago
  And operator new is hardly used any more in modern C++ code.
cmroanirgo 7y ago
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)
- kllrnohj 7y ago
  > 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. There's so many things that are just not controversial and not worth re-implementing. Like std::unique_ptr. Or std::array. Most of the containers are still better off ignored, though, many of them unfixable. The least worst of them is std::vector and it's still _ok_ but even there things like absl::InlinedVector are worth a strong consideration instead ( https://github.com/abseil/abseil-cpp/blob/master/absl/container/inlined_vector.h https://github.com/abseil/abseil-cpp/blob/master/absl/contai... ). Or boost's small_vector ( https://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_vector.html https://www.boost.org/doc/libs/1_60_0/doc/html/boost/contain... )
  - vlovich123 7y ago
    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.
    - kllrnohj 7y ago
      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.
      - Espressosaurus 7y ago
        Because that way you don't need to haul in dependencies unless you have a real reason. std::function is fine for prototyping, but its size hit is extreme, so in embedded code we use other implementations. But where size and speed doesn't matter? Why bother?
Tallasatree 7y ago
2 people equally confident in their own, completely opposing opinions. Every comment enabled website in a nutshell.
- saagarjha 7y ago
  I think this transcends comment enabled websites.
- ajna91 7y ago
  The real problem is everyone else who pattern-matches confidence with competence and upvotes.
- rumanator 7y ago
  > 2 people equally confident in their own, completely opposing opinions. Also known as a debate.
- Ragnarork 7y ago
  And as long as both are honest and well argued, that's incredibly rich.
dheera 7y ago
Yep. There isn't even a split/join method in std::string ... you need to use boost for that (wtf)
- BooneJS 7y ago
  Or Abseil, which had a lot of handy string manipulation functions including Append/FormatAppend.
rumanator 7y ago
> 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 insulted by the fact std::string is a template class. * He feels C function pointers are fine but believes function pointers in C++ weren't extended to support pointers to member functions, which he then backtracks and says they actually exist but they are "so horrendously ill-conceived that absolutely nobody uses it for anything", thus showing his ignorance and lack of experience. * For some reason he criticised std::map for the way it's std::map::operator[] returns a reference to the mapped value, eventhough that's what it is supposed to do by design and by the principle of least surprise. * The author made other claims, but the text grows so much in the style of "foaming from the mouth" that it's just better to stop reading after a point. In short, this article is just a rant where someone vents that a programming language other than Python is not Python at the eyes of the author. It's a pretty unconvincing rant and full of logical and rational holes, but a rant nonetheless. So the author loves Python and his personal take on C++ does not match his view of Python. That's fine. It's just weird how this sort of text floats up in a technical forum after over a decade after it has been published, as if it's expected to add or say anything of value.
- klingonopera 7y ago
  > "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 <stdio.h> int main() {printf(gString); return 0x0;}
  - AstralStorm 7y ago
    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.
gpderetta 7y ago
> Containers still do silly things when you use `c[..]` syntax with no element there. (Both when trying to insert and when trying to retrieve!) FWIW, I find std::map operator[] creating an object extremely convenient and it is very annoying having to use defaultdict to get the same behavior [edit: in python]. So ugliness really depends on what you are used to. > The general level of language size and complexity, especially around templates, has only gotten worse. Concepts will finally help in some ways here. variadic templates and type deduction greatly help. A lot of complex template metaprogramming is suddenly not needed anymore (I've used boost::mpl a lot in the past, but not once in the last 10 years). constexpr functions also helped get rid a lot more use cases. Finally if constexpr made a lot of sfinae hacks obsolete.
- eqvinox 7y ago
  > FWIW, I find std::map operator[] creating an object extremely convenient and it is very annoying having to use defaultdict to get the same behavior [edit: in python]. So ugliness really depends on what you are used to. Adding behavior to replace a NULL/None return with a default object is pretty easy. Removing the default object that you've been inflicted upon... how would you go about that?
  - gpderetta 7y ago
    if you do not like operator[] behaviour just use map::at
_pmf_ 7y ago
> Containers still do silly things when you use `c[..]` syntax with no element there. (Both when trying to insert and when trying to retrieve!) This is surprising for Java devs, but given that value semantics must be supported, there's no way to avoid it.
deleted 7y ago
[deleted]

by Rusky 7y ago

UncleMeat 7y ago

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

gumby 7y ago
And operator new is hardly used any more in modern C++ code.

cmroanirgo 7y ago

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)

kllrnohj 7y ago
> 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. There's so many things that are just not controversial and not worth re-implementing. Like std::unique_ptr. Or std::array. Most of the containers are still better off ignored, though, many of them unfixable. The least worst of them is std::vector and it's still _ok_ but even there things like absl::InlinedVector are worth a strong consideration instead ( https://github.com/abseil/abseil-cpp/blob/master/absl/container/inlined_vector.h https://github.com/abseil/abseil-cpp/blob/master/absl/contai... ). Or boost's small_vector ( https://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_vector.html https://www.boost.org/doc/libs/1_60_0/doc/html/boost/contain... )
- vlovich123 7y ago
  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.
  - kllrnohj 7y ago
    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.
    - Espressosaurus 7y ago
      Because that way you don't need to haul in dependencies unless you have a real reason. std::function is fine for prototyping, but its size hit is extreme, so in embedded code we use other implementations. But where size and speed doesn't matter? Why bother?

Tallasatree 7y ago

2 people equally confident in their own, completely opposing opinions. Every comment enabled website in a nutshell.

saagarjha 7y ago
I think this transcends comment enabled websites.
ajna91 7y ago
The real problem is everyone else who pattern-matches confidence with competence and upvotes.
rumanator 7y ago
> 2 people equally confident in their own, completely opposing opinions. Also known as a debate.
Ragnarork 7y ago
And as long as both are honest and well argued, that's incredibly rich.

dheera 7y ago

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

BooneJS 7y ago
Or Abseil, which had a lot of handy string manipulation functions including Append/FormatAppend.

rumanator 7y ago

> 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 insulted by the fact std::string is a template class. * He feels C function pointers are fine but believes function pointers in C++ weren't extended to support pointers to member functions, which he then backtracks and says they actually exist but they are "so horrendously ill-conceived that absolutely nobody uses it for anything", thus showing his ignorance and lack of experience. * For some reason he criticised std::map for the way it's std::map::operator[] returns a reference to the mapped value, eventhough that's what it is supposed to do by design and by the principle of least surprise. * The author made other claims, but the text grows so much in the style of "foaming from the mouth" that it's just better to stop reading after a point. In short, this article is just a rant where someone vents that a programming language other than Python is not Python at the eyes of the author. It's a pretty unconvincing rant and full of logical and rational holes, but a rant nonetheless. So the author loves Python and his personal take on C++ does not match his view of Python. That's fine. It's just weird how this sort of text floats up in a technical forum after over a decade after it has been published, as if it's expected to add or say anything of value.

klingonopera 7y ago
> "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 <stdio.h> int main() {printf(gString); return 0x0;}
- AstralStorm 7y ago
  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.

gpderetta 7y ago

> Containers still do silly things when you use `c[..]` syntax with no element there. (Both when trying to insert and when trying to retrieve!) FWIW, I find std::map operator[] creating an object extremely convenient and it is very annoying having to use defaultdict to get the same behavior [edit: in python]. So ugliness really depends on what you are used to. > The general level of language size and complexity, especially around templates, has only gotten worse. Concepts will finally help in some ways here. variadic templates and type deduction greatly help. A lot of complex template metaprogramming is suddenly not needed anymore (I've used boost::mpl a lot in the past, but not once in the last 10 years). constexpr functions also helped get rid a lot more use cases. Finally if constexpr made a lot of sfinae hacks obsolete.

eqvinox 7y ago
> FWIW, I find std::map operator[] creating an object extremely convenient and it is very annoying having to use defaultdict to get the same behavior [edit: in python]. So ugliness really depends on what you are used to. Adding behavior to replace a NULL/None return with a default object is pretty easy. Removing the default object that you've been inflicted upon... how would you go about that?
- gpderetta 7y ago
  if you do not like operator[] behaviour just use map::at

_pmf_ 7y ago

> Containers still do silly things when you use `c[..]` syntax with no element there. (Both when trying to insert and when trying to retrieve!) This is surprising for Java devs, but given that value semantics must be supported, there's no way to avoid it.

deleted 7y ago

[deleted]