Konkret geht es mir darum eine Tabelle mit Informationen über Dateien zu erstellen. Würde so aussehen:

map<wxString,vector<IrgendEinTyp>> DateiTabelle;

Ich würde es dann halt schon gerne dynamisch halten, sodass ich da alles drin speichern kann; von Dateinamen über Icons bis hin zu Dateigrößen. Im Moment habe ich das so gelöst:

map<wxString,vector<void*>> DateiTabelle;

was aber nicht so schön ist, weil man dann zum Beispiel in der Klasse, die die Dateitabelle und die Funktionen dazu bereitstellt, keine Sortierfunktion implementieren kann, weil man ja nicht weiß, auf welche Daten die void Pointer zeigen. Irgendwo anders habe ich gelesen, dass man da was mit Polymorphie was machen kann- was mir bei Klassen einleuchten würde, aber nicht bei "Grundtypen", wie wxString, int oder ähnliches.....

Hast du auch überlegt, wie du die unterschiedlichen Elemente ansprechen willst, wenn du deren Typ nicht kennst? Selbst wenn du es schaffst, so etwas hinzufrickeln, läuft das auf hässliche Fallunterscheidungen aus.

Wieso erstellst du für unterschiedliche Objekte nicht unterschiedliche Container? Dann könntest du innerhalb eines Containers alle Objekte gleich behandeln.

...In letzter Zeit kommen irgendwie viele, die eine Variable für alle möglichen Typen nutzen wollen....

War das nicht schon immer so?
Ist doch eigetnlich ein typisches Kennzeichen für Anfänger und/oder Java-Umsteiger... einer der typischen "sieht-erstmal-einfacher-aus-und-erst-später-merkt-die Schmerzen"-Phänomen (oder anders ausgedrückt: "Ohne Beine ist man natürlich leichter ... und trotzdem langsamer" ).

Gruß,

Simon2.

Wieso erstellst du für unterschiedliche Objekte nicht unterschiedliche Container? Dann könntest du innerhalb eines Containers alle Objekte gleich behandeln.

Also wahrscheinlich werde ich es dann auch so machen...irgendwas anderes als string,int,datum und vielleicht noch sowatt wie ein Icon braucht man ja bei Dateien auch sowieso nicht speichern, weil die meisten Eigenschaften meistens sowieso strings sind...
@BorisDieKlinge: Hast du vielleicht ein kurzes Beispiel zu dem was du sagst?? Ansonsten versuche ich das selber herauszufinden...

naja void* ist da bischen schlecht... wenn man aber ne Basisklasse als Default typ nimmt, und die entsprechenen Typen ableitet und schön polymorphy benutzt, muss man den typ nich unbeding kennen...

Wobei Polymorphie auch nicht die Lösung aller Probleme ist. Der Sinnvolle Einsatz von Polymorphie ist nur gegeben, wenn die Typen untereinander soviele Gemeinsamkeiten haben, das man in der Regel mit dieser Basisschnittstelle arbeiten kann, und nur selten auf Konvertierungen wie dynamic_cast oder ähnliches zurückgreifen muss.

In vielen Fällen ist dies nicht gegeben, und manche versuchen dann eine Basisklasse einzufügen, die nichts anderes macht als dafür zu sorgen das es eine Basisklasse gibt. Ohne irgendwelche Zusammenhänge und gemeinsame Schnittstellen (Wieso kommen mir hier nur die Typischen xyzObjekt-Hierachien in den Sinn... sei es nun TObject oder wie sie alle heißen).

cu André

naja ich weis ja nich was für typen du da speichern willst

Technohead schrieb:

Irgendwo anders habe ich gelesen, dass man da was mit Polymorphie was machen kann- was mir bei Klassen einleuchten würde, aber nicht bei "Grundtypen", wie wxString, int oder ähnliches.....

Zumindestens nach seinem ersten Angaben denke ich, das es sich nicht um geeignete Elemente für Polymorphie halten wird.

@Technohead: In meinen etwa 10 Jahren C++ Erfahrung kam ich zwar auch ab und zu in die Überlegung alles in einen Container stopfen zu wollen, aber immer habe ich dann eine andere (bessere) Lösung gefunden. Varianttypen etc. verwende ich nur wenn es die Schnittstelle erzwingt, ansonsten gibt es immer Alternativen.

cu André

@Technohead: In meinen etwa 10 Jahren C++ Erfahrung kam ich zwar auch ab und zu in die Überlegung alles in einen Container stopfen zu wollen, aber immer habe ich dann eine andere (bessere) Lösung gefunden. Varianttypen etc. verwende ich nur wenn es die Schnittstelle erzwingt, ansonsten gibt es immer Alternativen.

cu André

Na gut....dann werde ich das wohl so machen, wie ich schon in meinem anderen Post angedeutet habe. Bin nur zum ersten Mal in meinem Leben irgendwie so richtig über Templates gestoßen weil ich davor irgendwie immer zu faul war das zu lernen und dachte da gäbe es vielleicht eine besonders elegante Lösung für mein Problem. Aber ich denke mal an dein Statement werde ich mich dann in Zukunft wohl auch halten und mir andere Lösungen überlegen. Vielen Dank
@Boris: Lass mal gut sein mit Beispiel und so...werde da mit Sicherheit was online finden. Danke!!

irgendwas anderes als string,int,datum und vielleicht noch sowatt wie ein Icon braucht man ja bei Dateien auch sowieso nicht speichern, weil die meisten Eigenschaften meistens sowieso strings sind...

Wäre evtl sowas eine Lösung für dich?:

struct FileProperties
{
    Time creation, last_access, last_write;
    int  size;
    Icon icon;
    ...
};

map<wxString,FileProperties> DateiTabelle;

Geht natürlich nur, wenn im vorhinein alle Eigenschaften der Datei feststehen.

union FileProperties
{
    Time creation, last_access, last_write;
    int  size;
    Icon icon;
    ...
};

map<wxString,vector<FileProperties>> DateiTabelle;

Die Reihen der Tabelle sollen indiziert sein, damit es leicht ist zu sortieren- man muss nur in einem Vektor die Sortierung abspeichern- also die jeweiligen Indizes und muss nicht die gesamte Struktur ändern, oder irgendein Gedöns mit Pointern machen.

aber abgesehen davon würde es nur mit falschem Auslesen Probleme geben- oder gibt es da noch mehr Sachen, wo man sich Fehler einfangen kann?

Ich denke, das sollte als Begründung reichen.

Aber sonst könnte man noch gegen union s sagen, dass sie Speicherplatz verschwenden (Uniongrösse entspricht Grösse des grössten Members), dass man separat speichern muss, welcher Typ gerade benutzt wird, dass man sowohl falsch lesen als auch falsch schreiben kann, und dass union s nicht mit Klassen funktionieren.

Technohead, kannst du mir sagen, was dich so sehr an mehreren Containern (für jeden Typ einen) stört?

struct ATTRIBUTE{
    int iInteger;
    [...]
};

map<wxString,vector<ATTRIBUTE>>;

und habe dann halt die ganzen Typen in die Struktur geschrieben, die ich so brauche. Hab halt nur gedacht es würde vielleicht irgendeine super elegante Lösung geben Die Lösung ist aber schon gut genug und wie ich gerade auch sehe völlig ausreichend!!

MfG Jonas

Technohead schrieb:

struct ATTRIBUTE{
    int iInteger;
    [...]
};

In der Regel werden Makros in Großbuchstaben gesetzt, deine Namenskonfention ist zumindestens allen mir bekannten Richtlinien zuwider, undabhängig wie die einzelnen Strukturen benennen.

P.S: Das ich von der UN wie bei iInteger auch nichts halte ist Geschmackssache, nur das mit der Großschreibung kenne ich nirgends

P.S: Das ich von der UN wie bei iInteger auch nichts halte ist Geschmackssache, nur das mit der Großschreibung kenne ich nirgends

*Hust* DirectX *Hust*

*Hust* DirectX *Hust*

Gesundheit, ja von dieser Krankheit habe ich gehört (und tatsächlich verdrängt).

int iInteger;

Das ist ja mal kreativ. Keinen aussagekräftigen Namen für eine Variable wählen, und dann noch ein redundantes ungarisches Präfix anfügen.

asc schrieb:

nur das mit der Großschreibung kenne ich nirgend

Finde ich ehrlich gesagt auch ziemlich übel, aber ist halt Geschmackssache.

int iIchBeendeJetztDiesenPost = 1;

hättet ihr vielleicht einen Link zu einem anständigen C++ Style guide?? Ich glaube da gab es irgendwann mal sowas für Delphi..wisst ihr ob es irgendwas in der Art für C++ gibt??

Nein, weil es mehrere (auch verschiedene gibt). Ich habe mich inzwischen weitgehend den offiziellen C# Style angepasst (Typen mit "CamelCase", Variablen mit "pascalCase", Makros "GROSS_MIT_TRENNUNG_UEBER_UNTERSTRICH"), verwende sprechende Namen und setze keine Zusatzzeichen für Typen (die sich eh mal ändern können, und die Moderne IDE's ohnehin z.B. über Tooltip etc. nennen).

cu André

P.S:

bool istPostZuende = true;

Also wenn jetzt hier schon meine Schreibweise so groß niedergemacht wird hättet ihr vielleicht einen Link zu einem anständigen C++ Style guide??

Sowas gibt es sicher, aber das finde ich eine schlechte Idee. Sogenannten Style-Guides, die sich anmassen, den Programmierstil anderer vorschreiben zu können, würde ich jetzt nicht vertrauen.

Programmierstil im Sinn von richtig einrücken, eine Anweisung pro Zeile, gut kommentieren etc. ist schon sinnvoll, da dadurch das Verständnis erleichtert wird. Aber Dinge wie Bezeichnernamen, besonders Gross-/Kleinschreibung, ist wohl eher Geschmackssache. Wichtig ist einfach, dass du konsistent bleibst.

Technohead schrieb:

Ach und wegen der Großschreibung: ich finde das sieht halt blöd aus, wenn man zum Beispiel iinteger schreibt.

Du sollst auch nicht iinteger schreiben.

Es ging eher darum, dass iInteger kein guter Variablenname ist. Dass die Variable vom Typ int ist, sieht man bei ihrer Deklaration (bei moderneneren IDEs wie MSVC++ auch beim Darüberfahren der Maus). Diese Information musst du also nicht noch zusätzlich im Bezeichner ausdrücken, schon gar nicht doppelt. Sag lieber, wofür die Variable steht. Size ? Counter ? ID ?

Was die Ungarische Notation (das kleine i am Anfang) betrifft: Davon rate ich persönlich ab. Erstens aus oben genanntem Grund, dass es redundante Information beinhaltet. Zweitens wirst du das sowieso nicht konsequent durchziehen können.

Stell dir mal so etwas vor:

std::vector<std::list<int*> >& refveclstpi_var; // ref=Referenz, vec=vector, lst=list, p=Pointer, i=int

Du magst das jetzt als weit hergeholt sehen, aber auf so etwas wird es bei komplexeren Typen hinauslaufen. Deshalb würde ich von Anfang an von solchen Präfixen wegkommen. Das gilt auch für das "C" bei Klassen, wie CShip , CDocument etc. Was am ehesten noch legitim ist, ist ein vorgestelltes "m_" oder "my" für Member.

Um vielleicht trotzdem einige Anregungen zu Variablennamen, insbesondere Gross-/Kleinschreibung zu geben:
Die Standardbibliothek schreibt ja fast alles klein und trennt Wörter mit Unterstrichen ( push_back ).
Ich selber mach verwende häufig CamelCase ( MyVariableName ), weil ich es ästhetisch finde.

Was aber die meisten gleich handhaben, sind Makros. Diese werden fast immer vollständig grossgeschrieben und mit Unterstrichen getrennt ( ANY_MACRO ).

Du solltest vielleicht ein bisschen herumexperimentieren; du wirst dann sehen, was dir am besten gefällt und am übersichtlichsten für dich ist. Hauptsache, du kommst von der Ungarischen Notation weg.