default Typ bei Vektoren?
-
BorisDieKlinge schrieb:
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
-
BorisDieKlinge schrieb:
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é
-
asc schrieb:
@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!!
-
Technohead schrieb:
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.
-
Aber da sollte ich doch lieber ne Union nehmen, damit nicht immer auch Speicherplatz für das Icon benötigt wird, wenn ich nur einen Dateinamen speichern will- oder??
-
Ne, lass hier die Finger von unions. Vielleicht hab ich dich auch falsch verstanden, du willst doch auf jeweils einen Dateinamen ein paar Datei-Attribute abbilden, oder nicht? Wenn du Platzmangel hast, ist die struct aber der falsche Weg, das stimmt.
-
scheiß Browser.....ich hab das gleich dreimal gepostet...sry
-
Na ich würde es so machen:
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.
-
s.o.

-
Man kann unions schon nicht benutzen, wenn Klassen drin verwendet werden. Ist ja auch logisch, weil man sich sonst alleine schon mit Konstruktoren und Desktruktoren in die Haare bekommt

-
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?
-
Technohead schrieb:
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
unions 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 dassunions nicht mit Klassen funktionieren.Technohead, kannst du mir sagen, was dich so sehr an mehreren Containern (für jeden Typ einen) stört?
-
Eigentlich nichts..habe es jetzt auch so gelöst:
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

-
Von der folgenden Benennung möchte ich dir abraten:
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
-
asc schrieb:
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*

-
drakon schrieb:
*Hust* DirectX *Hust*

Gesundheit, ja von dieser Krankheit habe ich gehört (und tatsächlich verdrängt).
-
Technohead schrieb:
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.

-
Also wenn jetzt hier schon meine Schreibweise so groß niedergemacht wird
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?? Wenn nicht, dann wäre das ja vielleicht auch mal eine schöne Sache für das FAQ am Besten geschrieben von den Leuten, die gerade am Lautesten kritisiert haben

Ach und wegen der Großschreibung: ich finde das sieht halt blöd aus, wenn man zum Beispiel iinteger schreibt. Und sonst ist das ja bei Variablennamen auch immer so, dass man da die einzelnen Wörter groß anfangen lässt, weil das gut aussieht...int iIchBeendeJetztDiesenPost = 1;
-
Technohead schrieb:
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;