Kleine Stilfrage

berniebutt schrieb:

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?

padreigh

Jenachdem wie komplex die Klassen sind, könnte sowas schneller sein:

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!

Nexus

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.

hustbaer

Ich würde sagen: grundsätzlich in der Schleife.

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

Nexus schrieb:

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 -

Nexus

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

Shade Of Mine

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...

hustbaer

Shade Of Mine schrieb:

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.

Nexus

Wenn man allerdings ein "Reset" mit operator= durchführt, kann es schnell einmal langsamer sein als Destruktion/Neukonstruktion. Alleine schon weil Copy-and-Swap-Implementierungen Letzteres immer tun.

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

padreigh

Nexus schrieb:

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
}