The biggest issue with C++ for me is the confusing memory model. You have smart_pointers, you have move semantics, and then you have libraries like OpenCV doing their own refcounting (and also using std::shared_ptr). The C++11 features like lambdas are definitely welcome but at this point C++ epistemic footprint is just too large.
You can't make C++ not ugly, but you can't not try (2010)
151–160 of 187 posts
Re: You can't make C++ not ugly, but you can't not try (2010)
#152Earlier quoted context omitted.
> 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, espe…
> 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?
if you do not like operator[] behaviour just use map::at
Re: You can't make C++ not ugly, but you can't not try (2010)
#153Earlier 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.
And as long as both are honest and well argued, that's incredibly rich.
Re: You can't make C++ not ugly, but you can't not try (2010)
#154This 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 .
> which means that in the real world you have to learn and deal with all of it.
This is not what happens in the real world though.
While I agree that you have to deal with whatever is in your codebase at a given point, it also doesn't imply that you have to use everything and that everything can be useful for your project.
As standards keep coming and features get added, it's still increasingly prevalent to see guidelines and awareness around the topic of choosing your own subset of C++ to work with.
The main drawback is mostly that it incurs a cost in terms of brain power to discipline yourself to keep your work within a restricted set of language and standard library features.
It's extremely rare (and even debatable) whether a single person masters all the aspects and features of C++ (and if there's one, it's probably Alexandrescu).
Re: You can't make C++ not ugly, but you can't not try (2010)
#155Earlier quoted context omitted.
Because C++ is a nice, mostly safe, general purpose language, being spoiled by the 1% "performance above anything else crowd". I want my OWL, VCL back, not an hash table able to do lookups in micro-seconds
I know you're exaggerating here a bit, but come on, a hash table not able to do lookups in micro-seconds is just garbage. I expect better of any language, not just C++.
Indeed I was.
The point I was trying to make, was that from productivity point of view, there are more relevant stuff to fix in C++ than algorithm complexity of STL implementations.
Like catching up with what Java 5 standard library offers for networking and parallel/concurrent programming.
Re: You can't make C++ not ugly, but you can't not try (2010)
#156Earlier quoted context omitted.
abseil's might have a similar API but it's most definitely not the same (function signatures looking the same doesn't make it the same API). Some of the standard containers can't be fast because too strict/specific standard requirements, not because they don't try hard enough. Having said that I think using abseil's containers is reasonable, even as a default, if you can afford the dependency. > std::unordered_map AF…
what's wrong with unordered_map? it's at least more useful than map.
From what I understand its API is overspecified to the point that it basically forces a "traditional" array-of-linked-buckets implementation, which can be horribly slow on modern processors due to the need to chase pointers. This means a lot of the potential performance improvements of allowing map elements to be unordered are lost.
Re: You can't make C++ not ugly, but you can't not try (2010)
#157Earlier quoted context omitted.
Making a language so big and complex that you can't expect to understand it all isn't a good idea. You might be able to get away with using 50% of the language but if some project you depend on uses a different 50% then you have a problem.
OK but if you're a competent, adult software engineer it should be fairly easy to overcome that problem.
> OK but if you're a competent, adult software engineer
"No true Scotsman" and all, please refrain from posting messages that add nothing of value besides petty insults thrown in broad brush strokes.
Re: You can't make C++ not ugly, but you can't not try (2010)
#158Re: You can't make C++ not ugly, but you can't not try (2010)
#159Earlier quoted context omitted.
What's so awful about pointer to member? I've used it a couple of times, and didn't think it was particularly weird. I mean, yes, I had to look up the syntax, but it was rather straightforward.
there is nothing wrong with them, but pointers to member do not close over this, so you still need some form of binding to use them as callbacks.
Well, when you invoke a pointer to member, you need an actual object (a this) to invoke it on. So when the member runs, it has a this.
But it sounds like what you want is a "handle" or some such term, by which you can invoke a member function on an object, and all you need to do so is the handle. That's a different problem than pointers to members are trying to solve, but you can do that quite easily with a function object. That's essentially a roll-your-own closure, and since you can define whatever data members you want, you can close over anything.
One thing you have to watch out for, though, is lifetimes. C++ is not garbage-collected, and so it will not preserve an object just because another object has a pointer or reference to it. If you create a function object that captures a pointer to member, and a "this" to invoke it on, and the "this" gets destroyed, and then you use the function object, you're going to get chaos.
Re: You can't make C++ not ugly, but you can't not try (2010)
#160Earlier quoted context omitted.
> Because STL is part of the compiler, guaranteed to work on every platform supported by the compiler No it isn't and no it's not. There are even platforms where an STL isn't even provided out of the box, you have to pick one. And there's quite a few at that - libc++, libstdc++, stlport, etc... But clang, g++, etc... they don't care. To them it's just another library you're linking against, no different from any othe…
> No it isn't and no it's not. Your assertion is so patently wrong that you either are entirely clueless or you're just trolling.
Uh, what? Here's a simple example, clang supports windows. Clang's "bundled" standard library, libc++, doesn't support windows. Clang also not only allows but is commonly used with libstd++ instead.
Mixing and matching compilers and standard libraries is not only possible it's common. Especially when cross-compiling enters the picture.
There is no bundling of any kind in any concept of that word, practically or technically, between C++ compilers and standard libraries. This is also a good thing, it makes porting C++ to new platforms far more easier than it otherwise would be.
They even have independent feature compliance sections. Clang & G++ both support new C++ features independently of whether or not their "bundled" standard library does yet.