211–220 of 231 posts
Know what I like about Stroustrup's code? "using namespace std;". The typical convention of sticking std:: in front of std::every std::last std::bloody std::thing drives me std::insane.
Earlier quoted context omitted.
You said You won't get "extreme performance" from C++ because it is buried under the weight of decades of compatibility hacks. Now your whole comment is about vector behavior. You haven't talked about what 'decades of compatibility hacks' are holding back performance. Whatever behavior you want from a vector is not a language limitation. You could write your own vector and be done with it, although I'm still not sure…
Actually first my comment explicitly talks about move, but you just decided you don't care that C++ move has a perf leak and claimed that you didn't notice so therefore it doesn't count, which I guess could equally apply to somebody who wants to claim Python has extreme performance, or Visual Basic. I deliberately picked two examples from ends of the spectrum, a core language feature and then a pure library type. Bot…
Are you seriously implying copying a pointer makes C++ like python or visual basic in speed? Where did you even get these ideas? Show me any program anywhere, any github ticket any performance profile where a C++ move is somehow a performance problem.
I looked at your link and I still have no idea how doubling the size of std::vector "destroys" amortization. The std link you had before wasn't even about this, it was about memcpy.
Please link the origins of where you are getting this stuff. It doesn't sounds like there is some niche rust forum where people are looking for anything, no matter how far fetched to pretend C++ has a performance problem.
Meanwhile literally everything that needs performance is being written in C++. Why aren't codecs and browsers and games written in something else?
Earlier quoted context omitted.
It depends ... You should NEVER have "using namespace" (for any namespace) in a header file, since that is how you create name clashes, which is what the namespaces are there to avoid. I don't personally like "using namespace std;" even in implementations, since I think it makes code less readable, and the contents of std:: is so large, and growing, that I'd again prefer to just avoid the possibility of name clashes.…
>We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice. I think it's fascinating how different people can interpret this so differently. I feel like it's precisely because we read code so much more than we write it that we should prefer using names that get to the point, instead of having so much noise and repetitive boilerplate. Reading a soup of std::thi…
Sneaking using namespace directives in interface headers is a well known source of problems, as it inadvertently introduces names to lookup which can and often clash. I mean, think for a second: why are namespaces used? What problem do they solve? And why do people think it's a good idea to add all names to a custom namespace?
Well, adding those names to interface headers negates all that.
That's why some people interpret things differently: they are oblivious to this problem as their negligible experience means they never experienced any of the problems they cause.
Earlier quoted context omitted.
> This to me seems like a cargo cult justification, where you've heard the argument ... Well, no, I've been a professional programmer since 1982, and a hobbyist one both before then and to this day. I might be wrong, but these are the lessons I've learnt over the decades working on a variety of projects of different size and durations ... Of course consise code is nice, and while you're in the heat of development it'…
I am not saying you are cargo cult programming, but being a cargo cult programmer has nothing to do with seniority. There are plenty of people who have been programming for decades who blindly follow rules because that's how they learned things, that's what they were taught is good practice, and they never bothered to question it, reflect on it, and they go along with it because of cultural reasons rather than becaus…
One thing that is a clear tell that you are not senior is this belief that just because you are oblivious to problems it somehow means they don't exist.
Between someone who "blindly follows rules" and someone who doesn't think there's any problem in tearing down any example of a Chesterton's fence that comes across them, I'd take the cautious developer who understands tradeoffs.
In this case, mindlessly peppering include headers with using namespace directives leads to name conflicts in your code and in code that consumes your code. You need to understand what is the whole point of namespaces and what you are doing by essentially removing them. Think about it for a second.
Earlier quoted context omitted.
> But what lesson did you learn? That long names are better than short names, which is what I called cargo cult programming and an instance of mixing up the metric for the principle? Or did you instead learn that descriptive names are better than non-descriptive names? Do you always suppose that the people you are talking to are morons and cargo-cultists? Rhetorical question - have fun.
I like to present questions to people to justify their position so that others reading the advice can better evaluate it, understand the reasons and make a more informed judgement on it. I am also principled in critiquing an argument and never critiquing a person. I said that the advice you gave is a form of cargo culting, but I also said in the very first sentence that "I am not saying you are cargo cult programming…
Frankly, this is puerile and pointless. You're doing nothing of the sort. You're just being needlessly contrarian while framing issues from a place of arrogant ignorance, and not having others bite your troll bate doesn't mean you made any point or anyone was enlightened by the engagement.
Earlier quoted context omitted.
>We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice. I think it's fascinating how different people can interpret this so differently. I feel like it's precisely because we read code so much more than we write it that we should prefer using names that get to the point, instead of having so much noise and repetitive boilerplate. Reading a soup of std::thi…
I'd like to bring some perspective as someone who comes from a non-programmer background (mainly academic data science with Python and R) and just starting to learn C++. Bjarne's book seemed to be a comprehensive introduction and I'm currently going through it. I found that adding "using namespace std" at the beginning of the file reduced some of C++'s syntactic overhead that a beginner such as myself has to account…
That's a false dichotomy. You are free to add using namespace directives in scopes that aren't propagated to other components, such as private headers, source files, functions definitions, etc. including using namespace directives in interfaces is a notorious source of problems.
The problem with Stroustrup's pedagogical style is that it conveys to newbies that this approach is the right way to write code although this is a known source of nontrivial problems that will leave any newbie stumped.
Earlier quoted context omitted.
Actually first my comment explicitly talks about move, but you just decided you don't care that C++ move has a perf leak and claimed that you didn't notice so therefore it doesn't count, which I guess could equally apply to somebody who wants to claim Python has extreme performance, or Visual Basic. I deliberately picked two examples from ends of the spectrum, a core language feature and then a pure library type. Bot…
you just decided you don't care that C++ move has a perf leak and claimed that you didn't notice so therefore it doesn't count, which I guess could equally apply to somebody who wants to claim Python has extreme performance, or Visual Basic. Are you seriously implying copying a pointer makes C++ like python or visual basic in speed? Where did you even get these ideas? Show me any program anywhere, any github ticket a…
No, but I get the feeling you really do think that "copying a pointer" is somehow what's at stake here which suggests you've badly misunderstood how move works on C++ in general.
> Show me any program anywhere, any github ticket any performance profile where a C++ move is somehow a performance problem.
There's a CppNow talk from 2018 or so in which Arthur demonstrates a 3x perf difference. That's obviously an extreme case, you're not magically going to save most of your runtime by fixing this in most software, but it shows this is a real issue.
Since you're the one who believes in "extreme performance" you're probably surprised fixing this wasn't a priority. But P2137 gives a better indication of the status quo, or rather, what happened to the paper does rather than what's inside it. You can read the paper if you want (if you don't recognise at least most of the authors that means you're way past your depth for whatever that's worth) https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p21... -- WG21 gave a firm "No" to that paper, which is what it was for. C++ is not a language for "extreme performance". It's a language which prizes backwards compatibility. The authors, or rather their employers, needed to be explicitly told that. No, if you want perf you are in the wrong place just as surely as if you want safety, use a different language. C++ is for backwards compatibility with yet more C++.
> It doesn't sounds like there is some niche rust forum where people are looking for anything, no matter how far fetched to pretend C++ has a performance problem.
Indeed, this isn't the product of a "niche rust forum". It's WG21, the C++ Standards Committee.
I think the problem is on your end, C++ demands a very high price in terms of safety, ergonomics, learning curve - and to some people that means it ought to be really good. Otherwise why such a high cost? Those are the same people who figure if they paid $500 for a T-shirt that must mean it's a good T-shirt. Nah, it just means you're a sucker.
> Why aren't codecs [...] written in something else?
This is especially frustrating because C++ is an incredibly bad choice for this work, as you'll have seen with the incidents at Apple. Nobody should be choosing the unsafe language with less than stellar performance to write codecs in 2024, and yet here we are.
And yet, most of the time when somebody even realises they shouldn't write codecs (and file compression and various other similar technologies) in C++ their next guess is Rust which while obviously an improvement over C++ is hardly a good choice for this work either.
The sad truth is that often it's inertia. We used this crap C++ code in 2008, and we re-used it when we refreshed this product in 2018, so it's still C++ today because nobody changed that.
Earlier quoted context omitted.
Not only that, but you have no idea what's going to be put into the standard tomorrow. If code I write today has a class called bubble_sorter, and then one day, the C++ standard library decides to add std::bubble_sorter, then: 1. If I had "using namespace std;" then all of my code is suddenly broken. 2. If I didn't have it, I'm fine. Also, and this is just personal preference, but I simply like to be able to clearly…
>If I had "using namespace std;" then all of my code is suddenly broken. If this happened and if you included that specific header, you would get a simple compiler error due to ambiguous methods. Then you can simply add a namespace somewhere and move on. I know sometimes this can involve a lot of changes (if we're talking about other `using namespace ...` usage) but in general you're not gonna have problems. If you'r…
...or, hear me out, you can not make the mistake of mindlessly adding using namespace directives and therefore ensure neither you nor any consumer of your code will risk.having to handle perfectly avoidabld name clashes.
And by the way, name clashes will also happen if you include code from two or more dependencies which introduce ambiguous symbols. This is code outside of your control.
Earlier quoted context omitted.
It depends ... You should NEVER have "using namespace" (for any namespace) in a header file, since that is how you create name clashes, which is what the namespaces are there to avoid. I don't personally like "using namespace std;" even in implementations, since I think it makes code less readable, and the contents of std:: is so large, and growing, that I'd again prefer to just avoid the possibility of name clashes.…
Conversely, We write code once, but read it many times, so longer names seems like a poor efficiency choice.
How can you tell what's the type of an ambiguous name if you have no indication of which namespaces are within scope?
I mean, think about it. If your concern is readability, doesn't this mean it's important to know what code you're looking at?
Earlier quoted context omitted.
The MOC is just a code generation tool, it's about as objectionable as bison. A far greater sin, especially in the eyes of Stroustrup, is disabling exceptions
> The MOC is just a code generation tool, it's about as objectionable as bison. I think you've missed the whole point. No one cares about implementation details. The critical aspect is that Qt imposes the use of a superset of C++ which includes keywords such as signals and slots. Technically it's not even C++, but a language which has its own unique keywords, concurrency model, object ownership and life cycle, etc.
The concurrency model, object ownership and life cycle you are mentioning are not part of C++, those are just conventions in specific C++ user groups - Qt code compiles plain and simple with pretty much every conformant C++ compiler and that makes it as much C++ as anything else.