Hacker News Reader

Comment by jstimpfle | Hacker News Reader

>> Move it, so simple, pointer invalidation.

> It works for everyone else, I'm not sure why this is controversial.

Show the evidence. It does not. It introduces vast amounts of complexity. So much that they were thinking they had to extend the syntax. Great, from rule of 3 to 7, from 41 ways to blow your leg off to 118 ways.

I'm betting it means you can easily google LOTS of memory bugs stemming from this complexity. It "just works" for everyone else, until it does not, and then nobody understands what's wrong because they created a complexity monster.

And what do you think how many intended "moves" get silently converted into copies because some failure to properly forward rvalue references and similar?

View on HN

Show the evidence. It does not. It introduces vast amounts of complexity.

The evidence is that everyone could do what you showed and they don't, they do this instead. In my experience memory ownership bugs are almost non-existent, an entire class of problems is wiped out.

It's clear that since you're asking about this stuff you haven't actually gone down this road yourself, which means that you're railing against something you don't understand out of fear of something different.

  #include <vector>

  using namespace std;

  vector<int> makeVec() {
    vector<int> v{1,2,3};
    return move(v);
  }

  int main() {
    auto  a = makeVec();
    return 0;
  }

Not difficult or complex. In this case you have something that isn't a constructor returning a data structure that contains heap allocation. You don't have to guess at ownership or dig through documentation (if it exists).

Keep an open mind, there's a reason people consider old C style archaic.

I was not asking, and certainly not for a toy example, are you STILL under the impression you need to explain beginner level C++ to me? You can btw remove the move() from the return statement in this example. It's normal to omit it as it is implicit and specifying it does not make a difference. Did I mention that move semantics introduce a ton of complexity and make it non obvious what is happening?

> Keep an open mind, there's a reason people consider old C style archaic.

It is superficially a little bit archaic but it's not as bad or cumbersome as people make it, like baking a good bread from old grains in a modern oven. The point is if you focus on superficialities and micro optimize everything, you will make a mess and get what you deserve (i.e. modern C++).

The result from baking with simple ingredients is better tasting and healthier than a modern factory bread.

What people consider archaic or in particular insufficient is a function of their knowledge and experience. Check out the raddebugger code and the many excellent explanatory videos about the design of the codebase. You will learn a lot and you might change your mind about many of your mainstream positions.

are you STILL under the impression you need to explain beginner level C++ to me?

Yes

you can btw remove the move() from the return statement in this example.

First you say you have a problem with not knowing if something will copy or move, now you have a problem with an explicit move to rely on copy elision.

Seems like you just want to complain about problems that don't exist.

This is why I think it's necessary to explain the basics.

function of their knowledge and experience

Now we are to the "get good" part of the C true believe argument. People have been trying to get good for 50 years and all the same bugs still happen.

You will learn a lot and you might change your mind about many of your mainstream positions.

I've already been on both sides of this argument. I like data structures, value semantics and avoiding double indirection.

Check out the raddebugger code

Check out the code to every other piece of software you use.

Reply on news.ycombinator.com