Wie heißt diese Datenstruktur?

[J. W. Smith (Gast)]

Geehrte Fachwelt,

beim C++ programmieren ist mir eine Datenstruktur enststanden, die ich 
nicht ganz zuverlässig benennen kann. Sie sieht wie folgt aus:

L_0|L_1 |L_2 |…|L_n
---+----+----+-+----
K_1|V_11|V_12|…|V_1n
---+----+----+-+----
K_2|V_21|V_22|…|V_2n
---+----+----+-+----
…  |…   |…   |…|…
---+----+----+-+----
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.

template <typename LABEL = std::string
        , typename KEY = boost::gregorian::date
        , typename VALUE = double>
using Rapunzel = 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

[Niklas G. (erlkoenig)]

Mehrdimensionale Map? Oder einfach std::map<std::pair<LABEL, KEY>, 
VALUE>?

[Ergo70 (Gast)]

Relation? L sind die Spalten, K der Primärschlüssel und V die Werte.

[MaWin (Gast)]

Warum tut man sich templates an? Ein compiler darf code übersetzen, aber 
nie code generieren! ;-)

Einfach Klassenhierarchie entwerfen und den Überblick behalten. ;-)

[yet another MaWin (Gast)]

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

[Niklas G. (erlkoenig)]

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?

[MaWin (Gast)]

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. ?

[Niklas G. (erlkoenig)]

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?

[Rudolph R. (rudolph)]

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. (erlkoenig)]

Rudolph R. schrieb:
> Veganer != Vegetarier

Sag bloß.

[Rudolph R. (rudolph)]

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.

[Niklas G. (erlkoenig)]

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 (Gast)]

Also wie man jetzt von Datenstrukturen zu

Niklas G. schrieb:
> Käse/Sahne/Butter-Alternativen

kommt, wir vielen ein Rätsel bleiben :-)

[Niklas G. (erlkoenig)]

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".

[Hotte (Gast)]

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.

[MaWin (Gast)]

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?

[Niklas G. (erlkoenig)]

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...

[yet another MaWin (Gast)]

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.

[Niklas G. (erlkoenig)]

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.

[yet another MaWin (Gast)]

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...

[yet another MaWin (Gast)]

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.