Geehrte Fachwelt,
beim C++ programmieren ist mir eine Datenstruktur enststanden, die ich
nicht ganz zuverlässig benennen kann. Sie sieht wie folgt aus:
1
L_0|L_1 |L_2 |…|L_n
2
---+----+----+-+----
3
K_1|V_11|V_12|…|V_1n
4
---+----+----+-+----
5
K_2|V_21|V_22|…|V_2n
6
---+----+----+-+----
7
… |… |… |…|…
8
---+----+----+-+----
9
K_m|V_m1|V_m2|…|V_mn
Alle L sind vom Typ LABEL, alle K vom Typ Key und alle V vom Typ Value.
Daraus sollen dann Key-Value-Paare sammt einem zugehörigen Label
entnommen werden.
1
template<typenameLABEL=std::string
2
,typenameKEY=boost::gregorian::date
3
,typenameVALUE=double>
4
usingRapunzel=map<LABEL,map<KEY,VALUE>>
Wie würden Sie nun Rapunzel nennen, bzw. können Sie mir ein
Nachschlagewerk für derartige Fragen empfehlen?
Vielen Dank
Warum tut man sich templates an? Ein compiler darf code übersetzen, aber
nie code generieren! ;-)
Einfach Klassenhierarchie entwerfen und den Überblick behalten. ;-)
MaWin schrieb:> Warum tut man sich templates an? Ein compiler darf code übersetzen, aber> nie code generieren! ;-)>> Einfach Klassenhierarchie entwerfen und den Überblick behalten. ;-)veganer ist ein altes indianisches Schimpfwort für "erfolgloser
Jäger".
[X] du magst weder yacc noch bison
MaWin schrieb:> Warum tut man sich templates an? Ein compiler darf code übersetzen, aber> nie code generieren! ;-)
Und wie soll er dann Maschinencode generieren?
yet another MaWin schrieb:> veganer ist ein altes indianisches Schimpfwort für "erfolgloser> Jäger".
Und ein Veganer-Hasser ist ein getroffener Hund, der jault. Manche
Menschen müssen sich übrigens aus gesundheitlichen Gründen vegan (oder
Milch-Frei) ernähren, muss man die auch so runter machen?
Niklas G. schrieb:> Und wie soll er dann Maschinencode generieren?
Das ist doch übersetzen! Aber alles so auch Datentypen ist vorgegeben.
Bei Templates sieht es ganz anders aus. Da kommen auch so Sachen wie
überladene Operatoren zu spannenden Ergebnissen.
Schreib mal SW im Team und gib die Nutzung von Templates frei. Der Spaß
ist gesichert. ?
MaWin schrieb:> Bei Templates sieht es ganz anders aus.
Da stehen die Datentypen auch während des Kompilierens fest. Sie stehen
nur an einer anderen Stelle.
MaWin schrieb:> Da kommen auch so Sachen wie> überladene Operatoren zu spannenden Ergebnissen.
Darum geht's.
MaWin schrieb:> Schreib mal SW im Team und gib die Nutzung von Templates frei. Der Spaß> ist gesichert. ?
Klar, wer würde sich schon eine list_MeinObjekt1 und eine
list_MeinObjekt2 und einen vector_MeinObjekt3 implementieren wollen,
wenn er auch einfach list<MeinObjekt1> und list<MeinObjekt2> und
vector<MeinObjekt3> verwenden könnte?
Niklas G. schrieb:> Manche> Menschen müssen sich übrigens aus gesundheitlichen Gründen vegan (oder> Milch-Frei) ernähren, muss man die auch so runter machen?
Veganer != Vegetarier
Niklas G. schrieb:> Rudolph R. schrieb:>> Veganer != Vegetarier>> Sag bloß.
Naja, hast Du ja selber nicht verstanden, Menschen die sich aus
gesundheitlichen Gründen anders ernähren sind vielleicht Vegetarier,
aber noch lange keine Veganer.
Und eine Milch-freie Ernährung ist nicht mal vegetarisch.
Rudolph R. schrieb:> Menschen die sich aus> gesundheitlichen Gründen anders ernähren sind vielleicht Vegetarier,> aber noch lange keine Veganer.
Muss nicht, kann aber. Ich schrieb über Menschen, die sich aus
gesundheitlichen Gründen vegan ernähren müssen. Oder meinst du, die gibt
es nicht?
Rudolph R. schrieb:> Und eine Milch-freie Ernährung ist nicht mal vegetarisch.
Richtig. Aber Es ist oft einfacher, vegane Varianten zu ordern, als
lange herum zu diskutieren welches Nicht-Vegane Gericht jetzt milchfrei
ist. Außerdem gibt es extra für Veganer milchfreie
Käse/Sahne/Butter-Alternativen auf pflanzlicher Basis; die sind sehr
praktisch für Menschen mit Milch-Unverträglichkeit. Auch als
Nicht-100%-Veganer kann man hier also vegane Produkte nutzen; quasi
Halb-Vegan.
Hotte schrieb:> kommt, wir vielen ein Rätsel bleiben :-)
Frag doch:
yet another MaWin schrieb:> veganer ist ein altes indianisches Schimpfwort für "erfolgloser> Jäger".
Niklas G. schrieb:> Hotte schrieb:>> kommt, wir vielen ein Rätsel bleiben :-)>> Frag doch:>> yet another MaWin schrieb:>> veganer ist ein altes indianisches Schimpfwort für "erfolgloser>> Jäger".
Das ganze passiert nur, wenn man auf so eine Pfeife reagiert.
Niklas G. schrieb:> Da stehen die Datentypen auch während des Kompilierens fest.
Aber nicht im eingetippten Source file! Das ist genauso bescheuert, wie
manche jedes C Konstrukt in eigene Makros stecken.
Der Code sollte auch für aussenstehende Programmierer gut lesbar sein.
Und dazu gehören auch z. B. Datentypen.
Ist nicht schon eine Rakete abgestürzt, weil die Datentypen falsch
eingeschätzt wurden?
MaWin schrieb:> Aber nicht im eingetippten Source file! Das ist genauso bescheuert, wie> manche jedes C Konstrukt in eigene Makros stecken.
Du würdest std::list also auch nicht benutzen, weil im "list" Header
nicht der eigentliche Datentyp steht? Und stattdessen für jeden
Element-Typ eine eigene Liste implementieren? Und du bist sicher, so
weniger Fehler zu machen als in der etablierten Standard-Klasse der
C++-Standardbibliothek vorhanden sind?
MaWin schrieb:> Ist nicht schon eine Rakete abgestürzt, weil die Datentypen falsch> eingeschätzt wurden?
Ja, aber nicht wegen templates oder weil der Datentyp in der "falschen
Datei" gestanden hätte.
Template-Programmierung ist natürlich nicht besonders einfach,
ermöglicht aber die Kapselung von Komplexität in einfach zu verwendende
Klassen und Funktionen. Unerfahrenere Programmierer können damit also
auch profitieren, indem sie eben z.B. die Standard-Container nutzen, die
intern einige raffinierte Optimierungen enthalten und z.B. auch
exception-sicher sind - das ist gar nicht mal so einfach in
Eigen-Implementierungen umzusetzen.
Ganz nebenbei sind dynamische Sprachen auch weit verbreitet, und da
sieht man nur ganz wenige explizite Datentypen...
Kognitive Transferleistung fällt eben flach wenn man sich bloss auf
'vorgegebene' Datentypen einschänkt, zusammengesetzte und abstrakte
Datenstrukturen ablehnt.
Kognitive Transferleistung fällt eben flach wenn man statt auf den
Kernpunkt:
> [X] du magst weder yacc noch /bison/
fokussiert, anstatt aufs Nebenrauschen.
Raketen stürzen ab wegen "Datentypen falsch eingeSCHÄTZT" wo eben
schätzen in engineering nix verloren hat.
Ich durfte 10J BE sammeln in R&D eines Flugfunkkommunikationssystems und
auch TelCo-Equipment (carrier-grade). Zwar keine "Raketentechnik", aber
so seriös dass auch ESA aus eigenem Antrieb Kunde wurde.
Datentypenprobleme hatten wir extrem selten, nicht zuletzt weil da IMMER
(schon bevor ich dazustiess) und INSBESONDERE für
Protokolldatenstrukturen, welche über Programmiersprachen hinweg
ausgetauscht wurden, Code-Converter (aka Compiler) im Buildsystem
eingebunden waren.
Das war bei diesem AG ein hauseigenes, internes Produkt; muss ja nicht
immer ASN.1 sein...
1 Einzige Quelle handeditiert, alles andere über erfasste Abhängigkeiten
(make) in andere Programmiersprachen maschinengeneriert.
Die ausnahmsweise doch mal auftretenden Datentypenprobleme flogen
jeweils sehr früh auf und zwar gleich in VORtests. Meines Wissens hat
sowas nie weder Factory Acceptance Tests erreicht und schon gar nie
einen unseren Kunden.
Keine Ahnung was du genau sagen möchtest, aber für so etwas
yet another MaWin schrieb:> weil da IMMER> (schon bevor ich dazustiess) und INSBESONDERE für> Protokolldatenstrukturen, welche über Programmiersprachen hinweg> ausgetauscht wurden, Code-Converter (aka Compiler) im Buildsystem> eingebunden waren.
kann man templates auch sehr gut gebrauchen:
https://github.com/Erlkoenig90/uSer
Spart die Fummelei mit externen Code-Generatoren und Integration ins
Build-System.
U.a. in Python, aber nicht nur, heissen solche Datenstrukturen Tuple
und Dictionary
Ach wie bequem: diese kommen mit der Hochsprache mit.
Genauso wie z.B. Listen, welche in vermeintlichen Hochsprachen wie C/C++
by Design (or lack thereof) nicht Teil der Sprache sind...
Niklas G. schrieb:> Keine Ahnung
nur schön weiter so.
> yet another MaWin schrieb:>> weil da IMMER>> (schon bevor ich dazustiess) und INSBESONDERE für>> Protokolldatenstrukturen, welche über Programmiersprachen hinweg>> ausgetauscht wurden, Code-Converter (aka Compiler) im Buildsystem>> eingebunden waren.>> kann man templates auch sehr gut gebrauchen:> https://github.com/Erlkoenig90/uSer> Spart die Fummelei mit externen Code-Generatoren und Integration ins> Build-System.
Tja, mittlerweile schon - da liegst Du schon richtig, heutzutage.
Jedoch wenn man den Markt beliefern wollte bevor Elfenbeinturmprodukte
wie eben Templates in C++Compilern reif verfügbar wurden, war eben
Selbsthilfe angesagt.
Selbst bei aktuellen reifen C++Compilern: ein Compiler ist zwar ein
wesentlicher Teil, aber noch lange nicht der einzuge Teil eines
Buildsystems.
Und nur weil ab Tag X ein neues, nützliches Sprachfeature im Compiler
verfügbar wird, ist es noch lange nicht (technisch wie ökonomisch)
sinnvoll allen bis dahin faktisch bewährten Code wegzuschmeissen und
umzuschreiben.
V.a. die Qualifikationstest (genauer: der Preis in Zeit und Währung
dieser) haben da viel mitzubestimmen.