Diverse Style-Fragen

RHBaum

Typedefs bei simplen Typen sind manchmal nutzlich und retten dir den A... Besonders wenn man mit ned ganz so entschlussfreudigen mitprogrammierern arbeitet, die so in ihren Schnittstellen haeufig zwischen den typen umherswitchen (sind die im eigenen Project, sollte man denen eh auf die finger haun !), und man ned staendig mit neuen Compilerwarnings ueberflutet wird (ja, gibt auch noch leute die achten drauf, das ihr project ohne warnings compiliert wird )
Ich hab mir prinzipiell angewoehnt, fuer datentypen mit spezieller Aufgabe, typedefs zu nehmen und zur verfuegung zu stellen. Beispiele Timestamps, Flag-Typen, etc.
Nichts ist ekliger, als wenn der Projektleiter bestimmt, dass timestamps nimmer 32 bittig, sondern aus kompatiblitaetsgruenden 64 bittig sein muessen, und man sucht dann tagelang alle code nach temp variablen durch :p
Ausserdem findet man die stellen besser, wenn die typen nen eindeutigen namen haben.

Prinzipiell:
Temporaere Variablen usw aufn stack legen, wenn sie ned die groesse sprengen ...
Klassen fast immer so programmieren, das man sie aufn stack verwenden kann (schnelle CCtoren, Zuweisungsops etc), solange sie ned zu gross werden.
Werden die Klassen zu gross, dann wirst um den heap ned drumherumkommen. Auch wenn du viele klassen einer Sorte anlegen willst. Aber Wrapper und container helfen dir dann weiter, wo die wrapper / containerklasse normal aufm Stack umherkopierst, die eigentlichen Daten aber aufn heapspeicher bleiben ...
SmartPointer verwenden !!!
Lokale Instantiierung und wertuebergabe (bei temporaeren objecten) / uebergabe per referenz (bei langlebigen objecten) ist Imho besserer C++ Stil als das zeiger geroedele
Wenn der Code aussieht wie der Sternenhimmel bei Nacht ( *******) dann sieht das ned wirklich nach C++ aus

5. weiss ned genau was du meinst ?
Templates sind nuetzlich. Aber templates sind auch ne philosophie ! Container Templates sind nur der Anfang. So richtig intressant wirds erst mit Policies / traits.
Diese Technicken helfen dir, deinen Code sehr modular zu halten, und gleichzeitig sehr universell (Baukasten prinzip), und unnötige Polymorphie zu vermeiden.
Aber ned uberall machen Templates gleich sinn
Auf alle faelle isses Wert sich da tiefer reinzuknien, und es hilft sehr viel das design zu verbessern.

Ciao ...

Bashar

RHBaum schrieb:

Temporaere Variablen usw aufn stack legen, wenn sie ned die groesse sprengen ...
Klassen fast immer so programmieren, das man sie aufn stack verwenden kann (schnelle CCtoren, Zuweisungsops etc), solange sie ned zu gross werden.
Werden die Klassen zu gross, dann wirst um den heap ned drumherumkommen.

Prinzipielle Zustimmung, aber was ist denn "zu groß"? Ein paar hundert Bytes machen den Kohl nicht fett, und das ist IMHO schon sehr groß, es sei denn, deine Klasse sehen so aus:

class Foo {
  Bar b[10000];
};

In diesem Fall greift wieder die Regel, dass man große Arrays möglicherweise auf dem Heap anlegen sollte.

Auch wenn du viele klassen einer Sorte anlegen willst.

Also ein Array? Die Regel hatten wir schon.

normal aufm Stack umherkopierst, die eigentlichen Daten aber aufn heapspeicher bleiben ...
SmartPointer verwenden !!!

Jepp!

Wenn der Code aussieht wie der Sternenhimmel bei Nacht ( *******) dann sieht das ned wirklich nach C++ aus

Wie romantisch

wat sind denn smartpointer?

RHBaum

@Bashar

aber was ist denn "zu groß"?

Naja, genau da wuerd ich mich eben ned mit zahlen festlegen wollen.
meist tritt die frage eh in zusammenhang mit containern / arrays auf ...
Variable aufm stack halten, und der container sammelt die aufn Heap.
Da kann man eine zusaetzliche kopie nicht wirklich durch referenzen umgehen.
in einigen faellen (wenns wirklich schnell gehen muss) sind paar 100byte schon zu viel. In einigen faellen ists aber auch wirklich schnurz.
In allen faellen eben, wenns ned notwendig ist, schnell zu sein, lieber den Sichereren weg ueber die kopie.

@---
google eben mal, denk schon das das nen gebraeuchlicher begriff ist ....
fuers verstaendiss.
Klassen, die dir nen Zeiger wrappen, und sich selber (nur fast, weil viel mehr funktionalitaet) benehmen wie Zeiger ...

Ciao ...

Bashar

RHBaum schrieb:

@Bashar

aber was ist denn "zu groß"?

Naja, genau da wuerd ich mich eben ned mit zahlen festlegen wollen.
meist tritt die frage eh in zusammenhang mit containern / arrays auf ...
Variable aufm stack halten, und der container sammelt die aufn Heap.
Da kann man eine zusaetzliche kopie nicht wirklich durch referenzen umgehen.
in einigen faellen (wenns wirklich schnell gehen muss) sind paar 100byte schon zu viel. In einigen faellen ists aber auch wirklich schnurz.
In allen faellen eben, wenns ned notwendig ist, schnell zu sein, lieber den Sichereren weg ueber die kopie.

Von Übergabe des Objekts (per Kopie oder per Referenz) hat keiner was gesagt. Nochmal ein Beispiel:

void foo() {
  Bar b;
  // bla bla
}

Wann ist Bar zu groß, um b auf den Stack zu packen? IMHO nie.

John Doe

Also unter MSVC 6 ist der Stack per default 1MB gross. Den Speicherplatz kann man ganz schnell verbraten wenn mann nicht aufpasst.

long Spielfeld[100][100][100]; // und schluss

Also mit "nie zu gross" wäre ich vorsichtig.

mfg JJ

otze

dein spielfeld würde ich auch eher in den heap packen

John Doe

Ich ja auch wollte nur zeigen wie leicht man den Stack dicht kriegt.

otze

100³*4 is ja nich viel :p

Bashar

John Doe: Der Fall, dass Bar ein Array ist, wurde schon ausgeschlossen bzw. anders behandelt. Lies einfach den Thread von vorne.

John Doe

Hi Bashar,

Um ne Variable mit nem Speicherbedarf von mehr als x KB zu erzeugen gibts auch andere Möglichkeiten als ein Array. Ich bin, wie du, auch der Meinung das der Stack die erste Adresse für Variablen ist. Aber ich hoffe es ist nicht so schlimm das ich darauf hingewiesen hab das der Platz nicht unbegrenzt ist, und man hin und wieder überlegen sollte ob der Stack wirklich der richtige Platz ist.
Deswegen halte ich den Hinweis auf

grosse Klassen...

für durchaus sinnvoll.

mfg JJ

Bashar

John Doe schrieb:

Um ne Variable mit nem Speicherbedarf von mehr als x KB zu erzeugen gibts auch andere Möglichkeiten als ein Array.

Aber auch realistische Möglichkeiten? Wenn du in jeder Klasse immer alle Arrays auf dem Heap hast, dann beinhalten Klasse immer nur primitive Typen (Größe 1 bis 10 Byte) oder andere Klassen, du musst also verdammt viel tippen um auf solche Größen zu kommen ... Ich bezweifle dass solche Monsterklassen von einem durchdachten Design zeugen.

rüdiger

RHBaum schrieb:

Beispiele Timestamps, Flag-Typen, etc.

für Timestamps würde ich sogar eine Klasse nehmen

RHBaum schrieb:

Ausserdem findet man die stellen besser, wenn die typen nen eindeutigen namen haben.

jo

RHBaum schrieb:

SmartPointer verwenden !!!
Lokale Instantiierung und wertuebergabe (bei temporaeren objecten) / uebergabe per referenz (bei langlebigen objecten) ist Imho besserer C++ Stil als das zeiger geroedele
Wenn der Code aussieht wie der Sternenhimmel bei Nacht ( *******) dann sieht das ned wirklich nach C++ aus

full-ACK

John Doe schrieb:

Also mit "nie zu gross" wäre ich vorsichtig.

Ja, aber wenn die Klasse zu groß ist um auf den Stack gelegt zu werden, dann muss sie intern eben den Heap benutzen

RHBaum

@Bashar

mit "zu gross" meint ich ned, das es zu gross fuer den Stack wird, sondern dass die klasse (sprich die Member Variablen) so viel und gross werden, dass es eben unperformant wird.

ne simple 3D punkt klasse mit 3 doubles ist noch kein Problem, wenn man die bei jeder uebergabe kopiert.
Nen Konstrukt aus paar Namen (strings, zur einfachheit halber vielleicht statisch als array mit fester Groesse) und noch zigdutzend statusvariablen, dann wirds schon kritischer. In vielen faellen immer noch schnurz, in manchen aber schon relevant fuer die performance.

Dort lieber nen Wrapper (oder smartpointer) schreiben, der das teim aufn heap construiert und nur den verweis aufn stack umherschiebt ...

Ciao ...

Shade Of Mine

RHBaum schrieb:

Dort lieber nen Wrapper (oder smartpointer) schreiben, der das teim aufn heap construiert und nur den verweis aufn stack umherschiebt ...

verstehe ich nicht.
einfach referenzen nehmen und nicht immer rumkopieren.

ein new dauert doch unendlich länger als ein allokation auf dem stack...

RHBaum

@Shade

einfach referenzen nehmen und nicht immer rumkopieren.

wenn mans kann .... logo.

nur wie machst du das in verbindung mit STL containern ?
Besipielsweise du willst members deiner klasse in nen set schreiben.

das einfuegen einer instanz ist schon mal ... erzuegung aufn stack,
Kopieren aufn heap, durch das set selber ....

was das set intern noch umherkopiert, mag ich lieber ned wissen :p

wuerdest es mit zeiger machen, wurdest gleich auf dem heap bauen, die kopien wuerden sich nur auf den Zeiger beziehen .... aber zeiger sind poese !

Ciao ...

otze

RHBaum schrieb:

@Shade
was das set intern noch umherkopiert, mag ich lieber ned wissen :p

wird nix umkopiert, nurn paar zeiger umgesetzt :p

Bashar

--- 8< 8< 8< 8< --- *scha-nipp* ---- 8< 8< 8< 8< ----
EDIT: Man sollte sich beim Schreiben nicht zuviel Zeit lassen.