in C++ hat man ja die möglichkeit (im gegensatz zu C89) Variablen sozusagen überall zu deklarieren. Man sollte also denken dass es guter Stil ist alle Variablen in einem möglichst kleinen Gültigkeitsbereich zu deklarieren. Allerdings wird hier ja auch immer wieder der Konstruktor neu aufgerufen.
zB.:

class MyTest
{
public:
  MyTest()
  {
    std::cout << "Konstruktor!" << std::endl;
  }
};

int main()
{
  for (std::size_t i = 0; i < 10; ++i)
  {
    MyTest instance;
  }
  return 0;
}

Wenn man jetzt davon ausgeht dass die Schleife ziemlich oft durchlaufen wird kann das schon peformance einbrüche geben oder? Und was jetzt? Variable ausserhalb des "for-scopes" deklarieren? Oder lieber eine statische Variable?

Die Frage ist sinnfrei. Wo man die Variable deklariert, ergibt sich doch daraus wie man die Variable verwendet. Und dann stellt sich die Frage garnicht mehr.

hä?

int main()
{
  MyClass instance;
  for (std::size_t i = 0; i < 10; ++i)
  {
    // do some cool stuff with instance
  }
}

int main()
{
  for (std::size_t i = 0; i < 10; ++i)
  {
    MyClass instance;
    // do some cool stuff with instance
  }
}

Und natürlich muss man Objekte entsprechend einer gescheiten Verwendung deklarieren/initialisieren. In deinem Fall könnte es außerhalb sinnvoller sein, aber am besten einfach mal testen mit Profiler.

Ja haengt davon ab was du beabsichtigst ... das ist von Fall zu Fall unterschiedlich. Deswegen kann es keine bevorzugte Loesung geben. Ob a) oder b) benutzt wird, ist keine Stilfrage!

nobaadi schrieb:

Die Frage ist sinnfrei. Wo man die Variable deklariert, ergibt sich doch daraus wie man die Variable verwendet. Und dann stellt sich die Frage garnicht mehr.

hä?

int main()
{
  MyClass instance;
  for (std::size_t i = 0; i < 10; ++i)
  {
    // do some cool stuff with instance
  }
}

int main()
{
  for (std::size_t i = 0; i < 10; ++i)
  {
    MyClass instance;
    // do some cool stuff with instance
  }
}

Du verwendest die Variable nicht. "do some cool stuff with instance" ist kein realistisches Problem. Bei realistischen Problemen wird die Frage eigentlich immer vom Problem beantwortet. Das hat wenig mit Stil oder RAII zu tun.

Du hast nach Stil gefragt. Ein solcher Stil wäre z.B class HUND (....); und daraus klar erkennbar gebildete Instanzen wie HUND Dackel; HUND Mops; HUND Pudel; etc.

Zur Vorbeugung: Das wäre C mit Klassen. Die C++ Puristen mögen sich weiter austoben, wenn es uns denn etwas lernt!

Du hast nach Stil gefragt. Ein solcher Stil wäre z.B class HUND (....); und daraus klar erkennbar gebildete Instanzen wie HUND Dackel; HUND Mops; HUND Pudel; etc.

Zur Vorbeugung: Das wäre C mit Klassen. Die C++ Puristen mögen sich weiter austoben, wenn es uns denn etwas lernt!

Versteht das einer?

int main()
{
  MyClass instance;
  for (std::size_t i = 0; i < 10; ++i)
  {
    // do some cool stuff with instance
          ....
    // do some cool stuff with instance
    instance.putBackIntoFreshlyConstructedState();
  }
}

Andererseits hängt das davon ab wie komplex das putBackIntoFreshlyConstructedState(); ist ... ich würde mich aber erst um sowas kümmern wenn da ein Performance bottleneck identifiziert wurde. Und wenn, dann eher so:

int main()
{
  {
    MyClass instance;
    for (std::size_t i = 0; i < 10; ++i)
    {
      // do some cool stuff with instance
            ....
      // do some cool stuff with instance
      instance.putBackIntoFreshlyConstructedState();
    }
  }
}

damit die MyClass dann auch aufgeräumt ist wenn ich sie sonst nur in der Schleife brauchen würde ... sonst hängt die da im Programm rum obwohl ich sie nimmer brauche!

Andererseits hängt das davon ab wie komplex das putBackIntoFreshlyConstructedState(); ist ...

Genau. Meist ist das nämlich gerade die Aufgabe des Konstruktors.

padreigh schrieb:

int main()
{
  {
    // ...
  }
}

Die inneren geschweiften Klammern sind unnötig. Der Scope wird dadurch nicht eingeschränkt.

In bestimmten Fällen macht die "putBackIntoFreshlyConstructedState" Variante allerdings schon Sinn. Oft muss sich das Objekt zu Beginn eines Schleifendurchlaufs auch nicht in exakt dem selben Zustand befinden wie ein frisch konstruiertes.

Angenommen man braucht innerhalb der Schleife einen std::vector. Den jedes mal zu zerstören und neu anzulegen ist bloss Performance-Verschwendung. clear() aufzurufen um den Vektor in einen "ausreichend frischen" Zustand zu bringen, kann da schon Sinn machen.

padreigh schrieb:

Andererseits hängt das davon ab wie komplex das putBackIntoFreshlyConstructedState(); ist ...

Genau. Meist ist das nämlich gerade die Aufgabe des Konstruktors.

padreigh schrieb:

int main()
{
  {
    // ...
  }
}

Die inneren geschweiften Klammern sind unnötig. Der Scope wird dadurch nicht eingeschränkt.

Bitte was? Dann kompilier das mal und lass es laufen ....

int main(void)
{
    int i;
    {
        for (i=0;i< 10; ++i) std::cout << " hallo";
    }
    std::cout << i << std::endl;

    {
        int j;
        {
            for (j=0;j< 10; ++j) std::cout << " hallo";
        }
    }
    std::cout << j << std::endl;
}

j ist da definitiv nicht mehr vorhanden ... und wenn j ein so dickes Ding ist, das es sich lohnt es VOR der Schleife bekannt zu machen und IN der Schleife wieder auf Startzustand zu stellen, dann würde ich meinen das es sich auch lohnt dieses NACH der Schleife nicht mehr rungeistern zu haben -

Angenommen man braucht innerhalb der Schleife einen std::vector. Den jedes mal zu zerstören und neu anzulegen ist bloss Performance-Verschwendung. clear() aufzurufen um den Vektor in einen "ausreichend frischen" Zustand zu bringen, kann da schon Sinn machen.

Wichtig dabei das KANN.
Denn es kann mit clear ja auch langsamer sein...

hustbaer schrieb:

Angenommen man braucht innerhalb der Schleife einen std::vector. Den jedes mal zu zerstören und neu anzulegen ist bloss Performance-Verschwendung. clear() aufzurufen um den Vektor in einen "ausreichend frischen" Zustand zu bringen, kann da schon Sinn machen.

Wichtig dabei das KANN.
Denn es kann mit clear ja auch langsamer sein...

Theoretisch: ja. Praktisch: kaum.

Das nur als Ergänzung, weil ich auch schon gesehen habe, dass ein Objekt aus Performancegründen mit operator= wiederverwendet wird

Schau dir nochmals den Codeteil an, den ich zitiert habe. Die doppelten geschweiften Klammern um alles sind sinnlos.

Wir reden wohl aneinander vorbei. Ich hätte es wohl so formulieren sollen:

int main()
{
  // do something here
  {
    MyClass instance;
    for (std::size_t i = 0; i < 10; ++i)
    {
      // do some cool stuff with instance
            ....
      // do some cool stuff with instance
      instance.putBackIntoFreshlyConstructedState();
    }
  }
  // do more here
}

vs.

int main()
{
  // do something here
  MyClass instance;
  for (std::size_t i = 0; i < 10; ++i)
  {
    // do some cool stuff with instance
          ....
    // do some cool stuff with instance
    instance.putBackIntoFreshlyConstructedState();
  }
  // do more here
}