Loops, Constructors and Performance

[Konstantin Tokarev]

@beecksche said in Loops, Constructors and Performance:

But I think that I read something about, that you should create a object outside of a loop.

In this case it doesn't matter, because you overwrite all vector elements on each iteration, and constructor of QVector3D doesn't make any dynamic allocations (QVector3D is actually float[3] with fancy API around)

[Konstantin Tokarev]

@VRonin said in Loops, Constructors and Performance:

Minor note auto o = Object(a,b,c) is also acceptable

Why do this when just QVector3D p(a, b, c) can work?

[J.Hilk]

@Konstantin-Tokarev said in Loops, Constructors and Performance:

@VRonin said in Loops, Constructors and Performance:

Minor note auto o = Object(a,b,c) is also acceptable

Why do this when just QVector3D p(a, b, c) can work?

Why use auto at all... It looks more modern and fancy.

I'm with Bjarne Stroustrup and wish auto would have never been added to the standard.

[VRonin]

@Konstantin-Tokarev said in Loops, Constructors and Performance:

Why do this when just QVector3D p(a, b, c) can work?

Linking ≠ Endorsement
https://www.youtube.com/watch?v=xnqTKD8uD64&t=40m00s

[Kent-Dorfman]

@J.Hilk said in Loops, Constructors and Performance:

@Konstantin-Tokarev said in Loops, Constructors and Performance:

@VRonin said in Loops, Constructors and Performance:

Minor note auto o = Object(a,b,c) is also acceptable

Why do this when just QVector3D p(a, b, c) can work?

Why use auto at all... It looks more modern and fancy.

I'm with Bjarne Stroustrup and wish auto would have never been added to the standard.

Actually I think Bjarne was misrepresented on that one. When I read his review of c++11, he seemed to at least be "politicially positive" about the new features...and really, auto is comes into its own when using long winded iterator declarations.

for(auto i: container) {} is so much more elegant than manually declaring the iterator type

but many of these arguements are just esoteric/philosophical rants to exercise and justify our OCD. Programmers with OCD?...yeah, right!

[kshegunov]

@VRonin
How is

auto o = Object(a, b, c);

different from:

Object o = Object(a, b, c);

for the generated code?

@Kent-Dorfman
In my mind auto was invented for the template junkies out there. The only real reason to actually "need" it in non-(heavily-)templated code is when doing ranged loops with arrays of anonymous structures. Something like this:

static struct  {
   int member1;
   // ....
} anonymousGlobal[] =  {
  { 0, /* ... */ }
};

for (auto x : anonymousGlobal)
    // ...

And even then I'd put some question on the clarity of such code.

[Kent-Dorfman]

@Kent-Dorfman

In my mind auto was invented for the template junkies out there. The only real reason to actually "need" it in non-(heavily-)templated code is when doing ranged loops with arrays of anonymous structures. Something like this:

static struct  {
   int member1;
   // ....
} anonymousGlobal[] =  {
  { 0, /* ... */ }
};

for (auto x : anonymousGlobal)
    // ...

And even then I'd put some question on the clarity of such code.

fair enough...too often features become peoples religion and they go out of their way to overuse or justify their use. I personally think auto is a good idea, for specifically the reasons specified...it is a good shorthand for complex type declarations and I hate being long-winded, although you usually couldn't tell that from my written correspondence. I've been in python land for a while now and am less than anxious to see all the overuse of lambdas that have undoubtedly sprung up now that they are in the c++ spec. lambdas are my soap-box rant.

[VRonin]

@kshegunov said in Loops, Constructors and Performance:

How is
auto o = Object(a, b, c);
different from:
Object o = Object(a, b, c);

Actually all 3 forms are the same, the compiler (MSVC2015 and GCC 4.9 at least) takes care of doing the right thing:

#include <QDebug>
class Object{
public:
    Object(int){qDebug("Constructor");}
    Object(const Object&){qDebug("Copy Constructor");}
    Object(Object&&){qDebug("Move Constructor");}
};

int main(int argc, char ** argv)
{
   Object a(6);
   qDebug("############");
   Object b = Object(6);
   qDebug("############");
   auto c = Object(6);
   qDebug("############");
   return 0;
}

Outputs

Constructor
############
Constructor
############
Constructor
############

So we are worrying about a non-problem

[Christian Ehrlicher]

@Kent-Dorfman said in Loops, Constructors and Performance:

Object o(a,b,c) This syntax has the advantage that it is explicitly running the constructor only. The previous syntaxt may do both: construct the object into a temporary and then assign it to the destination object: 2 operations!

I would accept this answer 10 years ago but not nowadays and with c++14 it's wrong at all:
https://en.wikipedia.org/wiki/Copy_elision and https://en.cppreference.com/w/cpp/language/copy_elision

[kshegunov]

@Christian-Ehrlicher said in Loops, Constructors and Performance:

I would accept this answer 10 years ago but not nowadays and with c++14 it's wrong at all

Maybe in a perfect world. The compiler I use on the cluster has c++11 and partial c++14 support. Old, but it's out of my hands. Considerations to such contexts apply.

[Christian Ehrlicher]

gcc has '-fno-elide-constructors' since 4.0 so what ancient compiler do you use? ;)

[kshegunov]

This disables eliding - the optimization you're after. So the expression:

Object a = Object(x, y, z);

is going to always invoke the copy constructor with that flag. On the other hand -felide-constructors may or may not generate a constructor call depending on the specific version and optimizations the compiler does.