3. Häufig benutzte Variablen in Schleifen innen / außen deklarieren?

Häufig benutzte Variablen in Schleifen innen / außen deklarieren?

  • C

    Blöde Frage: Ist es schlechter Stil wenn man eine Variable ständig neu definiert in einem Schleifendurchgang?

    // Variante 1
for (int i=0; i<10; ++i)
{
    std::string str = Foo.getString();
    std::cout << str << std::endl;
}

    oder ist dies besser:

    // Variante 2
std::string str;
for (int i=0; i<10; ++i)
{
    str = Foo.getString();
    std::cout << str << std::endl;
}

    Ich finde Variante 1 leserlicher, bin mir nicht sicher, vielleicht optimiert der Compiler Variante 1 ohnehin zu Variante 2...

    0
  • P

    man muss das auf grund des einsatzes entscheiden. brauchst du den string NUR in der schleife, dann bleibt der auch da drin, also wird dort initalisiert und beim verlassen der schleife autmatisch gelöscht. das ist das gleiche wie mit der laufvariable i

    for(unsigned int i = 0; i != 10; ++i)
  foo.bar();

    wenn i soll nach der beendigung der schleife wieder aus dem speicher entfernt werden. und wenn du deinen string nun danach nicht mehr brauchst... dann schaut das so aus:

    for(unsigned int i = 0; i != 10; ++i){
  std::string str(Foo.getString()); // bei initalisierung den c'tor verwenden und nicht die zuweisung :)
  std::cout << str << std::endl;
}
    0
  • T

    Die Variante 2 ist besser, da bei der ersten Variante bei jedem Durchlauf Objekte auf dem Stack konstruiert und wieder zerstört werden müssen.

    Mal davon abgesehen wird sowohl bei

    std::string str(Foo.getString());

    als auch bei

    std::string str = Foo.getString();

    der Copy-Ctor von std::string aufgerufen. Beide Varianten sind äquivalent.

    0
  • C

    Ja, danke, das ist mir klar mit dem scope.

    Meine Frage ist aber ob die str Variable bei jeder Iteration neu auf dem Stack angelegt wird, oder ob der Compiler das auf Variante 2 optimiert?

    0
  • S

    Das kommt wohl auf den Compiler an 😉

    MfG SideWinder

    0
  • T

    SideWinder schrieb:

    Das kommt wohl auf den Compiler an 😉

    MfG SideWinder

    Eigentlich nicht, da Scopes zu den garantierten Verhaltensweisen gehören.

    0
  • E
     

    #include <conio.h>
#include <iostream>
using namespace std;

class xINT //Testklasse
{
private:
  int num;
  static int countCtor;
  static int countDtor;
  static int countCopycon;
  static int countOpAssign;

public:
  xINT()
  {
      std::cout << this << ": " << "ctor" << std::endl;
      ++countCtor;
  }

 ~xINT()
  {
      std::cout << this << ": " << "dtor" << std::endl;
      ++countDtor;
  }

  xINT(const xINT& x)
  {
      std::cout << this << ": " << "copycon von " << std::dec << &x << std::endl;
      num = x.getNum();
      ++countCopycon;
  }

  xINT& operator=(const xINT& x)
  {
      if (&x == this)
      {
          std::cout << "Selbstzuweisung mit op=" << std::endl;
      }
      std::cout << this << ": " << "op= von " << std::dec << &x << std::endl;
      num = x.getNum();
      ++countOpAssign;
      return *this;
  }

  xINT& operator=(const int i)
  {
      num = i;
      return *this;
  }

  int getNum() const {return num;}
  void setNum(int val) {num = val;}
  static void statistik(std::ostream&);
  static void reset();
};

int xINT::countCtor     = 0;
int xINT::countDtor     = 0;
int xINT::countCopycon  = 0;
int xINT::countOpAssign = 0;

void xINT::statistik(std::ostream& os)
{
  os   << "Ctor:    " << countCtor    << std::endl
       << "Dtor:    " << countDtor    << std::endl
       << "Copycon: " << countCopycon << std::endl
       << "op=:     " << countOpAssign;
}

void xINT::reset()
{
    countCtor     = 0;
    countDtor     = 0;
    countCopycon  = 0;
    countOpAssign = 0;
}

std::ostream& operator<< (std::ostream& os, const xINT& x)
{
  os << x.getNum();
  return os;
}

std::istream& operator>> (std::istream& is, xINT& x)
{
  int i;
  is >> i;
  x.setNum(i);
  return is;
}

bool operator<  (const xINT& a, const xINT& b){return a.getNum() <  b.getNum();}
bool operator>  (const xINT& a, const xINT& b){return a.getNum() >  b.getNum();}
bool operator== (const xINT& a, const xINT& b){return a.getNum() == b.getNum();}
bool operator!= (const xINT& a, const xINT& b){return a.getNum() != b.getNum();}

//----------------------------------------------------

int main()
{
    cout << "Variante 1" << endl;
    for (int i=0; i<5; ++i)
    {
        xINT x;
        x = i;
        cout << x << endl;
    }
    cout << endl;

    cout << "Variante 2" << endl;
    xINT x;
    for (int i=0; i<5; ++i)
    {
        x = i;
        cout << x << endl;
    }

   getch();
}

    Variante 1
0x22ff40: ctor
0
0x22ff40: dtor
0x22ff40: ctor
1
0x22ff40: dtor
0x22ff40: ctor
2
0x22ff40: dtor
0x22ff40: ctor
3
0x22ff40: dtor
0x22ff40: ctor
4
0x22ff40: dtor

Variante 2
0x22ff40: ctor
0
1
2
3
4
0x22ff40: dtor
    0
  • W

    Tachyon schrieb:

    Die Variante 2 ist besser, da bei der ersten Variante bei jedem Durchlauf Objekte auf dem Stack konstruiert und wieder zerstört werden müssen.

    Dies ist ein weit verbreiteter Irrtum, dass dies zu langsameren Code führen muss!

    Die Variante 1 (innen) ist nicht nur besser lesbar sondern ist auch der schnellere Code. Fülle ich den String mit 1000 Zeichen und erhöhe die Anzahl der Durchläufe von 10 auf 10000, so braucht die Variante 1 (innen) nur 14msec - die Variante 2 (außen) aber 17msec.
    Meiner Meinung nach liegt das daran, das in Variante 1 eben weniger (!) Kopien des Strings gemacht werden - wegen der 'Return Value Optimization'. Die ist genau dann möglich, wenn der String nach der Rückgabe aus 'getString()' erst angelegt wird.

    Gruß
    Werner

    0
  • ?

    Tachyon schrieb:

    Die Variante 2 ist besser, da bei der ersten Variante bei jedem Durchlauf Objekte auf dem Stack konstruiert und wieder zerstört werden müssen.

    ist aber nur blöd bei c++ objekten, die konstruktoren/destruktoren aufrufen. bei einfachen typen wie int/long/char usw. macht das nix.
    🙂

    0
  • E

    http://fara.cs.uni-potsdam.de/~kaufmann/?page=GenCppFaqs&faq=Optimize#Answ

    0
  • T

    Werner Salomon schrieb:

    Tachyon schrieb:

    Die Variante 2 ist besser, da bei der ersten Variante bei jedem Durchlauf Objekte auf dem Stack konstruiert und wieder zerstört werden müssen.

    Dies ist ein weit verbreiteter Irrtum, dass dies zu langsameren Code führen muss!

    Die Variante 1 (innen) ist nicht nur besser lesbar sondern ist auch der schnellere Code. Fülle ich den String mit 1000 Zeichen und erhöhe die Anzahl der Durchläufe von 10 auf 10000, so braucht die Variante 1 (innen) nur 14msec - die Variante 2 (außen) aber 17msec.
    Meiner Meinung nach liegt das daran, das in Variante 1 eben weniger (!) Kopien des Strings gemacht werden - wegen der 'Return Value Optimization'. Die ist genau dann möglich, wenn der String nach der Rückgabe aus 'getString()' erst angelegt wird.

    Gruß
    Werner

    Hmm, sowohl mit gcc als auch mit msvc ist bei mir die Innen-Variante deutlich langsamer. Ca. Faktor 4 mit MSVC und ca. Faktor 5 bei g++.

    0
  • L

    Du hast selbstverständlich den Releasemodus mit allen Optimierungen ausprobiert, oder? 😉

    0
  • W

    Hallo Erhard,

    in Zeile 48 fehlt noch die Ausgabe, dass hier ein 'int' zugewiesen wird, und in Zeile 105 und 115 darf es nicht

    xINT x;
        x = i;

    heißen sondern

    xINT x = getXInt();

    mit

    xINT getXInt() { return xINT(); }

    dann sieht der Output zwichen den Varianten etwas ausgeglichener aus.

    Nämlich:

    Variante 1
0012FF60: ctor
1245120
0012FF60: dtor
0012FF60: ctor
1245120
0012FF60: dtor
0012FF60: ctor
1245120
0012FF60: dtor
0012FF60: ctor
1245120
0012FF60: dtor
0012FF60: ctor
1245120
0012FF60: dtor

Variante 2
0012FF5C: ctor
0012FF64: ctor
0012FF5C: op= von 0012FF64
0012FF64: dtor
4200151
0012FF64: ctor
0012FF5C: op= von 0012FF64
0012FF64: dtor
4200151
0012FF64: ctor
0012FF5C: op= von 0012FF64
0012FF64: dtor
4200151
0012FF64: ctor
0012FF5C: op= von 0012FF64
0012FF64: dtor
4200151
0012FF64: ctor
0012FF5C: op= von 0012FF64
0012FF64: dtor
4200151

    .. und plötzlich ist viel mehr Aktion bei Variante 2 !

    Gruß
    Werner

    0
  • T

    LordJaxom schrieb:

    Du hast selbstverständlich den Releasemodus mit allen Optimierungen ausprobiert, oder? 😉

    Nein, ahbe ich nicht. Um an sowas zu denken, bin ich zu dämlich. 😉

    0
  • E

    @Werner Salomon: Right Sir! 🙂
    Jetzt wird es endlich praktisch. 😉

    0
  • T

    Es gibt einen Fall, in dem beide Varianten gleich schnell sind, und zwar dann, wenn ich beide Varianten zusammen in ein Executable packe. Erstelle ich aber für beide Varianten getrennte Executables, ist die "Innen"-Variante immer langsamer als die "Außen"-Variante.

    0
  • L

    Tachyon schrieb:

    LordJaxom schrieb:

    Du hast selbstverständlich den Releasemodus mit allen Optimierungen ausprobiert, oder? 😉

    Nein, ahbe ich nicht. Um an sowas zu denken, bin ich zu dämlich.

    Entschuldige, das wusste ich natürlich nicht. Kannst Du das in Deine Signatur schreiben? Dann sieht man es gleich und muss nicht fragen...

    (Muss ich noch einen Smiley anbringen, um den humoristischen Charakter dieses Statements zu entschärfen? 😃 🤡 )

    Spaß beiseite: Nicht nur Neulinge, auch erfahrene Forenbesucher dürfen gerne jegliche potentiell hilfreichen Angaben machen, um ein Problem oder eine Lösung nachzuvollziehen. Mich interessiert das Thema und natürlich auch Dein Test, sonst hätte ich nicht nachgefragt. Allerdings komme ich bei meinen lokalen Tests nur auf Faktor 1,5 - 2 (MSVC++ 8.0), da wäre es schon schön die Unterschiede zu kennen.

    0
  • T

    LordJaxom schrieb:

    Tachyon schrieb:

    LordJaxom schrieb:

    Du hast selbstverständlich den Releasemodus mit allen Optimierungen ausprobiert, oder? 😉

    Nein, ahbe ich nicht. Um an sowas zu denken, bin ich zu dämlich.

    Entschuldige, das wusste ich natürlich nicht. Kannst Du das in Deine Signatur schreiben? Dann sieht man es gleich und muss nicht fragen...

    (Muss ich noch einen Smiley anbringen, um den humoristischen Charakter dieses Statements zu entschärfen? 😃 🤡 )

    Sorry, ich habe meinerseits den Smily unterschlagen. 😞

    Immerhin scheinst Du auch einen Unterschied feststellen zu können. Ich habe hier einen relativ lahmen Firmenrechner mit einem P4. Vielleicht erklären sich daraus irgendwelche Unterschiede.

    0
  • W

    LordJaxom schrieb:

    Spaß beiseite: Nicht nur Neulinge, auch erfahrene Forenbesucher dürfen gerne jegliche potentiell hilfreichen Angaben machen, um ein Problem oder eine Lösung nachzuvollziehen. Mich interessiert das Thema und natürlich auch Dein Test, sonst hätte ich nicht nachgefragt. Allerdings komme ich bei meinen lokalen Tests nur auf Faktor 1,5 - 2 (MSVC++ 8.0), da wäre es schon schön die Unterschiede zu kennen.

    Hallo LordJaxom,

    mein Code sieht so aus:

    // includes ..
struct S
{
    std::string getString() const
    {
        return std::string( 1024, 'x' );
    }
};

int main()
{
    S Foo;
    sam::Watch uhr;
    std::cout.setstate( std::ios_base::failbit );
    {
        sam::Watch::Stopper stopper(  uhr );
        // std::string str;
        for (int i=0; i<10000; ++i)
        {
            std::string str = Foo.getString();
            std::cout << str << std::endl;
        }
    }
    std::cout.clear();
    std::cout << "benötigte Zeit. " << uhr << std::endl;
    return 0;
}

    damit erreiche ich das Verhältnis 17msec für Variante 1 und 20msec für Variante 2 (MS-VC8). Die zuerst genannten Werte (14msec zu 17msec) erreiche ich mit einem leeren std::ostream.

    Die Zeitmessung geschieht mit dem 'QueryPerformanceCounter' aus der WinAPI (Code nicht gepostet).

    Ich denke, es hängt viel davon ab, wie die Funktion aussieht, die den String liefert.

    Gruß
    Werner

    0
  • S

    Tachyon schrieb:

    Es gibt einen Fall, in dem beide Varianten gleich schnell sind, und zwar dann, wenn ich beide Varianten zusammen in ein Executable packe. Erstelle ich aber für beide Varianten getrennte Executables, ist die "Innen"-Variante immer langsamer als die "Außen"-Variante.

    Was hat das mit der Executable zu tun?
    Die innenvariante ist die schnellere wenn man sie nicht explizit aushebelt wie es erhard getan hat.

    0
Anmelden zum Antworten