Criticism of C++

Started by
143 comments, last by Ryan_001 8 years, 3 months ago

Unless I'm writing a low level class or a wrapper class, I don't need to do rule-of-three/rule-of-five.

Well, you always need to follow the rule of thee (unless deliberately doing something smelly) -- using the language properly so that you don't need to implement your own destructors/copy/assignment functions is the easiest way to follow the rule.

That's what I mean. Unless I'm writing a low level class or a wrapper class, I don't need to manually write the rule-of-three, because C++ default-constructs them (and the move constructor and assignment function) properly for me, so it's not a nuisance. Thanks for making me clarify what I meant.

(By 'wrapper class' I mean wrapping a C-like API in a RAII interface, or similar)

Advertisement

From what I gather he's saying that it's a generalized solution and that there should be more specific solutions for handling memory as it's the most commonly used resource.


I couldn't disagree more with that line of argument. A very common weakness of GC'd languages is a lack of robust facilities for managing resources other than memory. In my opinion, RAII is the gold standard for resources management.

I wish C++ generated more default operators (like I don't get why I need to define both += and +, < and > and >= and <= and so on). I wish I could just go operator+=(const SameClass&) = default; if I write the related classes.


[...]


I'm not sure I feel confident with that. That's a potentially very large number of automatically generated functions which you would have to '= delete' or specify directly if they are not doing what you want them to. Very easy to miss one of them too. I'd much rather have something like boost::operators as part of the standard instead of something automatic.

Personally I'm hardly ever giving anything a full set of operators. Sometimes things get an operator < if they need to be part of an ordered container but that's usually it.

From what I gather he's saying that it's a generalized solution and that there should be more specific solutions for handling memory as it's the most commonly used resource.


I couldn't disagree more with that line of argument. A very common weakness of GC'd languages is a lack of robust facilities for managing resources other than memory. In my opinion, RAII is the gold standard for resources management.


Could you fix your quote? I certainly didn't say it and I agree with you tongue.png
Well, Mussi said that and I he did not actively advocate that point either. Instead he was just trying to home in on the core points made in that video...

I wish C++ generated more default operators (like I don't get why I need to define both += and +, < and > and >= and <= and so on). I wish I could just go operator+=(const SameClass&) = default; if I write the related classes.


I'm not sure I feel confident with that. That's a potentially very large number of automatically generated functions which you would have to '= delete' or specify directly if they are not doing what you want them to. Very easy to miss one of them too. I'd much rather have something like boost::operators as part of the standard instead of something automatic.


I agree they shouldn't be auto-generated without explicit permission. I was suggesting the use of = default; to tell the compiler you *want* the compiler to generate the operator, but by default, they are automatically = delete;
(Bah, I keep on using 'default' when I mean compiler-generated upon request)

Perhaps "default" wouldn't be a good keyword. Maybe = auto; keyword could be repurposed for this.
class MyClass
{
    public:
    MyClass operator+(const MyClass &other); //Manually specified.
    MyClass &operator=(const MyClass &other);

    //Explicitely tell the compiler to generate an optimized function based off of combing the + and = operators' logic,
    //but with optimized instructions.
    //Compiler generates: { return this->operator=(this->operator+(other)); }, But optimized to remove the unnecessary copy.
    MyClass &operator+=(const MyClass &other) = auto;
    
    //Can work with other types also, ofcourse, and also in reverse direction.
    MyClass &operator+=(int value); /Manually specified.

    //Compiler generates: { return MyClass(*this).operator+(value); }, But optimized.
    MyClass operator+(int value) = auto;
};
And ditto for comparison operators, logic operators, binary operators, etc... but only for each function that you explicitly say = auto;

Does that make more sense?
Honestly, as long as we can agree it's a bad idea for the compiler to just sneak them in I don't have strong feelings either way. I need something like that once in a blue moon, I could live with doing it by hand or falling back on the Boost way. Maybe one could even add a [[generate_operators]] attribute to the class, we have these nice shiny attributes for C++ and barely anything to do with so far.

I would however point out that in general it's a better idea to define operator += explicitly and generate operator + from that, otherwise you waste at least an extra copy.

Has anyone mentioned properties yet? I want automatic-ish properties.

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.


but this is criticized as being ugly, having hard to read compiler errors and increasing compile times

Which may have been true at the time he made that criticism, but certainly isn't at this point.

Largely since Clang hit the mainstream, all of the major compilers have made massive strides in compilation speed and template error reporting. I don't think I've ever seen an error stemming from misusing std::unique_ptr that didn't immediately identify the root cause.

I use std::unique_ptr all the time, but I honestly have no idea how much it impacts compile times (but very interested in knowing), do you have some numbers at hand that could serve as some sort of indication?

... except you don't.

Most of the times you don't, that's correct. That's not what he was arguing though.


From what I gather he's saying that it's a generalized solution and that there should be more specific solutions for handling memory as it's the most commonly used resource.

I couldn't disagree more with that line of argument. A very common weakness of GC'd languages is a lack of robust facilities for managing resources other than memory. In my opinion, RAII is the gold standard for resources management.

I wouldn't call a GC a more specific solution than RAII and that's most likely not what Jonathan Blow meant in his video as he explicitly mentions that GC based languages aren't viable alternatives for big/complex (can't recall what terminology he used) games.

This talk by Bjarne Stroustrup has some great insights into solutions specific for managing memory:

It's all based on having a static code analyser so that it can be used right away, but it would be nice to see some compiler support for this soon.

  • No modules

Someone hasn't seen the C++17 draft :P

This topic is closed to new replies.

Advertisement