Criticism of C++

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

  • No modules

Someone hasn't seen the C++17 draft tongue.png

Last I heard, modules are now in a separate TS that'll be released around the time C++17 is released, but not in C++17 itself. This means we'll be able to start using it in C++17, and it'll be mostly locked in place, but it won't be officially standard until C++20.

If they changed it back to C++17 itself, I'd be delighted, but even if it's still a TS, that's still great news.

Advertisement

MSVC is starting supporting modules

"Recursion is the first step towards madness." - "Skegg?ld, Skálm?ld, Skildir ro Klofnir!"
Direct3D 12 quick reference: https://github.com/alessiot89/D3D12QuickRef/

There is nothing wrong with C++.

C++ is love, C++ is life.

Did c++ sneak into your room last night and leave you soiled and ruined laying on your bed, your father ashamed, then fly away out the window?

C++ is love, C++ is life.

Dark

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?

Wouldn't a macro suffice then?

Yea, probably. I try to not overuse macroes, but this might be an appropriate* place for it.

*as appropriate as macroes can ever be, anyway.

Yea, probably. I try to not overuse macroes, but this might be an appropriate* place for it.

*as appropriate as macroes can ever be, anyway.

I have a nice macro for strongly typed enums that adds all the bit-wise operators. So I can do this:


enum class SomeFlags : uint16_t {
   a = 1,
   b = 2,
   c = 4,
   };
ENUM_CLASS_OPERATORS(SomeFlags)

and it creates all the usual operators and saves me from a zillion static_cast's : ) If used sparingly macros have their place IMHO.

This topic is closed to new replies.

Advertisement