Namen für typedefs

asc

Roger Wilco schrieb:

Wobei ich diese Beispiel wohl über die Indexe des Datenpunkt-Vectors als über Objektzeiger realisieren sollte:

Wenn ich dich richtig verstehe sind in deinem Fall die Zeiger ohnehin sehr gefährlich, da die Speicherbereiche von vectoren bei einer Größenänderung umkopiert werden (Das ist der gleiche grund warum Iteratoren ungültig werden können). Wobei ich auch bei den Indexen vorsichtig wäre, wenn nicht sichergestellt ist, das du immer nur hinten einfügst.

Roger Wilco

volkard schrieb:

Über die Objektnamen würde ich sinnieren. Aber typedeffen von Containern, da bin ich am Zweifeln.

Oh, du hast Dein Beitrag editiert. Also würdest Du auch sagen, dass man Container eher nicht typedeffen sollte, richtig? Gut, habe ich auch überlegt.

volkard schrieb:

Wozu?

Schreibarbeit? Lesbarkeit? Container lässt sich einfacher austauschen?

class Foo
{
    ...
    DataPoints GetDataPoints(...);
};

volkard schrieb:

Zur Not kommt man mit decltype oder Template-Tricks oder auto (insbesondere mit den neuen for-Schleifen) gut genug dran.

Oh, das sagt mir so auf Anhieb nichts.

Roger Wilco

asc schrieb:

Wenn ich dich richtig verstehe sind in deinem Fall die Zeiger ohnehin sehr gefährlich, da die Speicherbereiche von vectoren bei einer Größenänderung umkopiert werden (Das ist der gleiche grund warum Iteratoren ungültig werden können). Wobei ich auch bei den Indexen vorsichtig wäre, wenn nicht sichergestellt ist, das du immer nur hinten einfügst.

Ok, ich wollte eigentlich nicht so explizit auf mein aktuelles Beispiel eingehen, sondern allgemein das Thema typedefs klären. Aber das ist mir halt auch gerade aufgefallen, dass ich hier lieber über den Index auf die Datenpunkte verweisen/zugreifen sollte. In diesem Beispiel verwende ich den std::vector<DataPoint> für das "Speichermanagement". Der vector wird einmalig gefüllt und bleibt dann konstant.

volkard

Roger Wilco schrieb:

volkard schrieb:

Wozu?

Schreibarbeit? Lesbarkeit? Container lässt sich einfacher austauschen?

Schreibarbeit?

Man schreibt ja nicht mehr

for(std::vector<DataPoint*>::iterator i=DataPointPtrs.begin(),e=DataPointPtrs.end();i!=e;++i)

sondern

for(auto i:DataPointPtrs)

Das nachträgliche Austauschen halte ich für überbewertet. Also mir passiert es recht selten. Zu selten, um mich explizit darum zu kümmern.

Roger Wilco schrieb:

class Foo
{
    ...
    DataPoints GetDataPoints(...);
};

Naja, klar spart es hier Tipparbeit, die haste aber woanders hinverlagert.

Roger Wilco schrieb:

volkard schrieb:

Zur Not kommt man mit decltype oder Template-Tricks oder auto (insbesondere mit den neuen for-Schleifen) gut genug dran.

Oh, das sagt mir so auf Anhieb nichts.

Mit decltype kannste grob gesagt Typen wieder besorgen aus Objekten.

for(decltype(DataPointPtrs)::iterator i=DataPointPtrs.begin(),e=DataPointPtrs.end();i!=e;++i)

Roger Wilco

Ich sehe gerade, dass das Neuerungen in C++11 sind. Ich habe hier leider nur TR1 (VS2008) zur Verfügung.

Also: Keine typdefs für Container? Ist das der Regelfall in der (prof.) C++-Programmierung?

volkard

Roger Wilco schrieb:

Also: Keine typdefs für Container? Ist das der Regelfall in der (prof.) C++-Programmierung?

So halte ich es. Aber ich hab's auch nicht selten professionell mit Typedefs gesehen. Das ist ja nur eine leichte Umschreibung, die nichtmal im entstehenden Compilat die kleinste Auswirkung hat.

Roger Wilco schrieb:

Ich sehe gerade, dass das Neuerungen in C++11 sind. Ich habe hier leider nur TR1 (VS2008) zur Verfügung.

Der hat stattdessen typeof (oder war's __typeof?). Das kann einem manchmal aus der Patsche helfen.
edit: Nee, anscheinend hat er's nicht, sondern man kann es sich aus boost holen. Schade.

pyhax

for(decltype(DataPointPtrs)::iterator i=DataPointPtrs.begin(),e=DataPointPtrs.end();i!=e;++i)

Warum nicht einfach

for(DataPointPtrs::iterator i=DataPointPtrs.begin(),e=DataPointPtrs.end();i!=e;++i)

????

hustbaer

pyhax schrieb:

for(decltype(DataPointPtrs)::iterator i=DataPointPtrs.begin(),e=DataPointPtrs.end();i!=e;++i)

Warum nicht einfach

for(DataPointPtrs::iterator i=DataPointPtrs.begin(),e=DataPointPtrs.end();i!=e;++i)

????

Weil DataPointPtrs hier ne Variable ist und kein Typ.
Genau darum gehts ja u.A. in dieser Frage: wenn man dem genauen Typ einen Alias-Namen verpasst (typedef eben), dann kann man

for(AliasName::iterator i=DataPointPtrs.begin(),e=DataPointPtrs.end();i!=e;++i)

schreiben.
Wenn man es nicht macht muss man

for(Namespace::ContainerTyp<ElementTyp, Nochwas, Blubb>::iterator i=DataPointPtrs.begin(),e=DataPointPtrs.end();i!=e;++i)

schreiben, was oft mal etwas länger werden kann. Und lästig ist, wenn man den Container-Typ ändert.

@Roger Wilco
Ich persönlich verwende kaum typedefs.
Vor allem deswegen, weil es mMn. die Einarbeitungszeit erhöht einen Haufen "unnötiger" Namen einzuführen. (Ist ein "Additional Level of Indirection" den man durchwandern muss um an die gewünschte Information zu kommen - nämlich "was ist das für ein Typ?")

Ich kenne aber auch (professionelle) Projekte wo das genau andersrum gehalten wird, wo für alles gleich ein Typedef gemacht wird. Wenn's da Foo gibt gibt's auch ein typedef shared_ptr<Foo> FooPtr und ggf. gleich noch ein paar weitere ( FooVector , FooPtrVector - was auch immer).

Normalerweise kapselt man die Datenstrukturen wie vector und map in einer eigenen Klasse und bietet nur die Operationen nach aussen hin die wirklich gebraucht werden

Roger Wilco

hustbaer schrieb:

Ich kenne aber auch (professionelle) Projekte wo das genau andersrum gehalten wird, wo für alles gleich ein Typedef gemacht wird. Wenn's da Foo gibt gibt's auch ein typedef shared_ptr<Foo> FooPtr und ggf. gleich noch ein paar weitere ( FooVector , FooPtrVector - was auch immer).

Darauf (viele typedefs) hatte ich mich auch eingeschossen. Ich denke, ich werde das jetzt auch auf ein Minimum reduzieren.

Ich danke Euch für Meinungen!