C++ 0x

[Michael E.]

terraner schrieb:

Ja, denn ios::binary ist
- nicht portabel (CPU- und OS-abhängig, z.t. gar nicht unterstützt)
- nicht zwischen mehreren versionen des selben programms nutzbar, wenn sich zuviel ändert
- nur schwer für tiefe objekt-hierarchien nutzbar
- leider nicht in der lage irgendetwas anderes als char zu speichern

und leichter zu komprimieren sind text-dateien auf jeden fall (wer lust und spaß dran hat )

Mal davon abgesehen, dass ich otzes Meinung hab, braucht man ios::binary wirklich. Wenn du es einfach wegwerfen willst, musst du auch für Ersatz sorgen.

[Gast]

kingruedi schrieb:

Aber der Punkt ist ja, dass man die Standard Library in zwei Teile aufteilen sollte, einmal einen "Erwarteten" und einmal einen "Optionalen".

Ich weiß nicht. Genau in dem Moment reicht dann dein standardkonformer Code schon wieder nicht aus und du brauchst nen gutmütigen Compiler. Dieser gutmütige Compiler hat dann für Win und Mac OS und Solaris (weil er von Sun ist ) die Implementierung und für Linux nicht.

Nene, dieses Minimum an stdlib ist IMHO einfach nicht mehr das, was die Leute wollen. Ich will keinen eigenen URL-Encoder schreiben, der aus "Hoi Alter ?" "Hoi+Alter%22" macht und ich will auch nicht danach suchen und ich will auch keine Sockets erst suchen und erst die dritte gefundene lib mögen, etc. Ich denke aber auch, dass sich C++ in dieser Hinsicht nicht mehr prinzipiell ändern wird und sehe deshalb die Zukunft der Sprache für die Anwendungsentwicklung als gefährdet.
Es gibt außerdem noch so viele feine Sachen, die man in pure C++ schreiben könnte, ohne dass die Compilerbauer mehr Aufwand hätten, wie z.B. ne Klasse für große Zahlen, nen URL-Encoder, anständige Collections, ... und sowas liegt der stdlib einfach nicht bei. Das verstehe ich nicht.

[rüdiger]

terraner schrieb:

Ja, denn ios::binary ist
- nicht portabel (CPU- und OS-abhängig, z.t. gar nicht unterstützt)

Unterstützt wird es immer, nur bringt es auf Betriebssystemen, für die Text- und Binärmodus gleich ist keinen unterschied. Aber trotzdem kein Grund das nicht einzubinden, da ein populäres OS noch diese Unterscheidung hat.

- nicht zwischen mehreren versionen des selben programms nutzbar, wenn sich zuviel ändert

was du meinst ist was anderes, aber das hat nichts mit ios::binary zu tun

- nur schwer für tiefe objekt-hierarchien nutzbar

- leider nicht in der lage irgendetwas anderes als char zu speichern

äh

und leichter zu komprimieren sind text-dateien auf jeden fall (wer lust und spaß dran hat )

äh? Die Zahl 0xFFFF nimmt Binär nur 2 Byte ein, im Textmodus 4 bzw. 6 mit führendem 0x...

Tut mir leid, dass ich dir das sagen muss, aber es Hört sich an, als hättest du nicht so viel Ahnung davon.

@Optimizer
Ein URL-Encoder ist vielleicht zu konkret, da er ja ein bestimmtes Protokoll/Format umsetzt. Aber allgemeinere Dinge fehlen definitiv. Die Klasse für große Zahlen hast du ja bereits angesprochen. Solche Dinge werden ja auch in C++0x aufgenommen.

[terraner]

kingruedi schrieb:

Tut mir leid, dass ich dir das sagen muss, aber es Hört sich an, als hättest du nicht so viel Ahnung davon.

da es nicht portabel ist und ich auf zwei systemen programmiere, benutze ich es nicht. es ist schon wahr das ich nicht viel ahnung von ios::binary habe. ich bin vor einiger zeit auf einen artikel gestoßen, indem das so ähnlich drinstand. und deshalb habe ich mich jetzt an dem artikel orientiert.
sry, wenn es falsch ist.

mfg

[lalalala]

bis das rauskommt proggt eh die halbe Welt in Java und .NET

[simon.phoenix]

lalalala schrieb:

bis das rauskommt proggt eh die halbe Welt in Java und .NET

Muss auch sagen, dass die zeitliche Planung imho etwas, hmm naja, erschreckend ist

Wenn da dann keine Sockets und Threads reinkommen, werde ich jeden verstehen, der über C++ lacht. Aber erst dann

[rüdiger]

terraner schrieb:

da es nicht portabel ist und ich auf zwei systemen programmiere, benutze ich es nicht. es ist schon wahr das ich nicht viel ahnung von ios::binary habe. ich bin vor einiger zeit auf einen artikel gestoßen, indem das so ähnlich drinstand. und deshalb habe ich mich jetzt an dem artikel orientiert.
sry, wenn es falsch ist.

Der Artikel hatte wahrscheinlich schon recht. Nur so hast du gefährliches Halbwissen weiter vermittelt. Das Problem ist das Alignmend und die unterschiedliche Typgröße. Also wenn man Structs binär schreiben und lesen will, dann muss man da aufpassen, weil Compiler aus Geschwindigkeitsgründen die Strukturen mit Füllbytes alignen. Aber ios::binary ganz zu verdammen ist nicht gut.

[Irgendwer]

lalalala schrieb:

bis das rauskommt proggt eh die halbe Welt in Java und .NET

Du hast da schon recht aber is seh nicht was das ":D" da zu suchen hat? Ein ":(" finde ich passender ;).

Und ich sehe eigentlich nicht wieso man keine GUIs in den Standard packen könnte. Als erstes würde ich 2 main Funktionen vorschlagen, die eine wird aufgerufen wenn das Program per GUI arbeiten soll die andere wenn es per commandline sein soll. Eine Platform die dann keine GUI ünterstützt kann dann einfach die GUI main rauswerfen. Das was das Program macht ist meistens ja weitgehend unabhängig davon ob es jetzt per Commandline oder per GUI arbeitet deswegen können beide main Funktionen ja auf die gleichen Funktionen zurückgreifen und somit wird auch kein Code unnötig dubliziert.

Dann muss die GUI ja auch nicht konkret sein. Das heist man gibt nur an welche Eingaben man dem User ermöglichen will. Also es ist zu Beispiel der Implementirung überlassen ob sie nun eine Listbox oder Combobox nimmt. Man gibt nur an in welcher Verbindung die einzeln Controls zueinander stehen. Also zum Beispiel ein Textfeld für Vor- und Nachname sollen möglichst nahe beieinander stehen. Vielleicht auch eine Reihenfolge der Controls.

Man kann natürlich nie die Detaileinstellungen einer nativ Schnittstelle zur Verfügung stellen aber das ist ja auch nicht das Ziel. Das Ziel ist es eine platformunabhängige GUI Library zu erschaffen die auch auf jeder Platform irgendwie normal drein schaut. Dies kann man dadurch erreichen, dass man der Implementirung viel Spielraum in der Darstellung lässt.

Dennoch bleibt es viel arbeit.

[lügner]

Gott könnte die Rettung für C++ sein.

[Gast]

Du brauchst doch keine andere main - Funktion, weil du mit GUIs arbeitest? GUI-Programme können auch Parameter fressen.

[Artchi]

Selbst Windows-Programme brauchen keine WinMain mehr, da ab Win2000Pro auch die main() ausreicht. :p

[Irgendwer]

Optimizer schrieb:

Du brauchst doch keine andere main - Funktion, weil du mit GUIs arbeitest?

Du wirst dann aber immer einen if Abfrage in der main Funktion haben, GUI ja/nein. Was faktisch eine Funktion wäre die zwei Sachen tut also man eh in 2 Funktionen auslagern soll. Also wieso dies nicht von vorn herein so tun? Dann spart man sich die if Abfrage. Desweitern wird dadurch die Portabilität erheut. Es gibt Betriebssysteme welche leicht andere Binär Dateien verwenden wenn es sich um GUI Programme handelt als wenn es sich um Consolenprogramme handelt. Wenn man 2 main Funktionen kann der Compiler ohne Probleme 2 binar Dateien erschaffen. Wenn man nun aber eine if Abfrage hat dann wird es schon etwas schieriger (nicht unmöglich aber wieso den Compilerbauern das Leben unnütz schwer machen?).

Optimizer schrieb:

GUI-Programme können auch Parameter fressen.

Hier sehe ich ehrlich gesagt nicht dein Problem

[Gast]

Irgendwer schrieb:

Du wirst dann aber immer einen if Abfrage in der main Funktion haben, GUI ja/nein.

Wieso denn bitte?! Weißt du selber nicht, ob du ne GUI codest oder nicht?

Es gibt Betriebssysteme welche leicht andere Binär Dateien verwenden wenn es sich um GUI Programme handelt als wenn es sich um Consolenprogramme handelt.

Das darfst jetzt mal genauer erklären. Was sind das für geheimnisvolle "binäre Daten"? Und selbst wenn es für das Betriebssystem einen Unterschied machen würde, müsste der Compiler halt nen anderen Header in die .exe schreiben. Kein Grund, eine andere main-Funktion zu nehmen.

Ich glaube, du hast ein bisschen zu viel WinMain() gesehen...
Schau dir lieber mal was anständiges an, wie Java-Swing oder .Net-WinForms.

In .Net setzt man per Linker-Einstellung, ob ein Konsolenfenster angezeigt wird, in Java wählt man ne andere VM aus. Man kann jedoch durchaus sein GUI-Programm als Konsolenprogramm linken/ausführen lassen, die Option ist nur da, damit man kein Konsolenfenster hat. Mit der main - Methode hat das gar nichts zu tun.

[Artchi]

Optimizer schrieb:

Ich glaube, du hast ein bisschen zu viel WinMain() gesehen...
Schau dir lieber mal was anständiges an, wie Java-Swing oder .Net-WinForms.

Wie von mir bereits geschrieben, ist selbst ab Win2000Pro (NT5.0) keine WinMain() mehr nötig! WNDCLASSEX und CreateWindowEx brauchen kein HINSTANCE mehr, wird ab NT5.0 einfach nicht mehr beachtet. Es reicht eine gaaaanz normale main(), und die anderen alten WinMain()-Parameter (wie nCmdShow) kann man sich nachträglich zur Laufzeit besorgen. Also selbst Java und .NET sind nicht mehr "besser", was das Thema angeht!

WinMain() und über die anderen Unanehmlichkeiten braucht man heute nun wirklich nicht mehr diskutieren.

[otze]

was meint ihr, wird es vielleicht irgendwann möglich sein, templates+virtual zusammen verwenden zu können?

die argumentation ist ja bislang,dass templates zur compilezeit erstellt werden, während die virtuellen funktionen über eine vtable ausgeführt werden.

foo->bar(5.0);
foo->bar(5.0f);

nehmen wir mal an, dass bar eine virtuelle template funktion ist:
der compiler sieht, dass einmal die float, und einmal die double version aufgerufen wird. dh er hat zur compilezeit alle informationen darüber, wie die templates verwendet werden, und kann dafür dann in den klassen ganz normal die funktionen erstellen. da diese funktionen nun existieren, kann der compiler für sie nun auch einen vtable eintrag erstellen, und somit bei der ausführung dann die richtige version raussuchen. Es ist also möglich.

klar, man kann so ein feature schlecht in dlls benutzen, aber objekte und dlls passen eh nicht gut zusammen

[***]

Infos?

Gibt es irgendwo schon Infos zu C++0x? Ich mein irgendjemand von den ISO-Hoschies wird doch sicherlich schon ein Paper veröffentlicht haben zum kommenden Standard was kommen wird und wobei noch spekuliert wird?

Wir brauchen papers

[hehejo]

Irgendwer schrieb:

Dann muss die GUI ja auch nicht konkret sein. Das heist man gibt nur an welche Eingaben man dem User ermöglichen will. Also es ist zu Beispiel der Implementirung überlassen ob sie nun eine Listbox oder Combobox nimmt. Man gibt nur an in welcher Verbindung die einzeln Controls zueinander stehen. Also zum Beispiel ein Textfeld für Vor- und Nachname sollen möglichst nahe beieinander stehen. Vielleicht auch eine Reihenfolge der Controls.

Ich kann mir beim besten Willen nicht vorstellen, dass damit jemand glücklich werden kann.
Wenn ich schon GUI programmiere, dann will ich auch bestimmen wo und wie etwas erscheinen soll.

Stell dir mal vor, du bist ein Entwickler und bekommt GUI-Vorgaben vom Produktmanager.
Wie willst du dem erklären, dass du seine GUI-Wünsche von der Anordnung nur "wahrscheinlich" umsetzen kannst?
Um bei deinem Beispiel zu bleiben:
Die Editfelder sollen nebeneinander sein und nicht nur in der Nähe voneinander.

[Tankian]

otze schrieb:

die argumentation ist ja bislang,dass templates zur compilezeit erstellt werden, während die virtuellen funktionen über eine vtable ausgeführt werden.

Das ist glaub ich kaum der Grund warum es dieses Feature
nicht gibt und meiner Meinung nach auch nicht geben wird.

Problem 1:

Nehmen wir mal an du rufst eine virtuelle Template Funktion in der Art
base->f<T>() auf. Erst zur Laufzeit steht fest welche Version von f<T> dann
wirklich aufgerufen wird, Derived-Klassen können die Funktion ja überschreiben.
Damit es also sicher eine Definition für die Funktion gibt, müssten alle Versionen von f<T> instanziiert werden.

Was macht der Compiler aber, wenn er nicht alle Definitionen der Derived-Klassen
zur Verfügung hat, weil sie eventuell in einer anderen Übersetzungseinheit sind ?
(Ist also im Prinzip das selbe Problem wie mit export).

-> Der Compiler ist nicht dazu in der Lage
virtuelle Template Funktionen zu instanziieren.

Problem 2:

Theoretisch müsste man ja für jede Instanziierung der Template Funktion einen
neuen Methodenzeiger in die vtable einfügen. Es sind aber unendlich viele
Versionen von einer Template Funktion möglich, überschreitet auf jeden Fall
meine Kapazitäten.

Natürlich könnte man jetzt argumentieren, dass der Compiler einfach beobachten
soll welche Versionen denn nun wirklich benötigt werden und hat halt je nachdem
ne größere/kleinere vtable.

Wiedermal ergeben sich dann mit verschiedenen Übersetzungseinheiten Probleme.
Nehmen wir an wir rufen in unserer ÜE1 base->f<T>() auf und in ÜE2 base->f<U>().
Der Compiler müsste dann also zwei unterschiedliche vtables anlegen ? Er kennt
ja den Aufruf der anderen Übersetzungseinheit nicht.

-> Der Compiler ist nicht dazu in der Lage
eine vtable für solche Funktionen anzulegen.

Theoretisch wär es denk ich sehr wohl möglich, wenn dann halt einfach der
Linker die Drecksarbeit macht. Wenn das aber so ohne weiteres möglich wär,
hätt ich längst nen Compiler der export unterstützt .
Wird also wohl kaum aufgenommen werden, da es ne ziemliche
Anforderung an Compiler-/Linker-Hersteller wäre ..

Tankian

[otze]

zu problem 1:

falls du meinst, dass es für jedes mögliche T in f<T> eine instanziierung geben muss(dh für jede klasse und jeden standard typ), dann stimmt das nicht. der compiler sieht ja schon zur compilezeit, welche versionen der methode aufgerufen werden, und dann muss er halt nur für diese instanziierungen vornehmen. wozu sollte der compiler eine methode für ein T generieren, welches in diesem kontext nicht vorkommt?

womit du aber recht hast ist, dass der compiler für jeden Derived alle f<T> generieren muss, die irgendwo im programm vorkommen, egal ob Derived im kontext vorkommt oder nicht.

Was macht der Compiler aber, wenn er nicht alle Definitionen der Derived-Klassen
zur Verfügung hat, weil sie eventuell in einer anderen Übersetzungseinheit sind ?
(Ist also im Prinzip das selbe Problem wie mit export).

-> Der Compiler ist nicht dazu in der Lage
virtuelle Template Funktionen zu instanziieren.

wenn sich das zeug nicht in fremden übersetzungseinheiten befindet, hat man damit keine probleme. Sind halt die gleichen einschränkungen wie für templates. Natürlich ist das für unsre Fabrikfanatisten nicht so toll, da man die Derived nichtmehr sogut verbergen kann, aber ich denke, da kann man sich auch ne lösung für einfallen lassen.

Wiedermal ergeben sich dann mit verschiedenen Übersetzungseinheiten Probleme.
Nehmen wir an wir rufen in unserer ÜE1 base->f<T>() auf und in ÜE2 base->f<U>().
Der Compiler müsste dann also zwei unterschiedliche vtables anlegen ? Er kennt
ja den Aufruf der anderen Übersetzungseinheit nicht.

da ich nicht weis, wie der compiler das bei normalen templates handelt, kann ich dazu erstmal nichts sagen, vielleicht kann sich ja jemand melden, der en bissl ahnung von compilern hat...

aber so wies aussieht, wird der linker richtig arbeit bekommen^^

[Tankian]

otze schrieb:

zu problem 1:
falls du meinst, dass es für jedes mögliche T in f<T> eine instanziierung geben muss(dh für jede klasse und jeden standard typ), dann stimmt das nicht. der compiler sieht ja schon zur compilezeit, welche versionen der methode aufgerufen werden, und dann muss er halt nur für diese instanziierungen vornehmen. wozu sollte der compiler eine methode für ein T generieren, welches in diesem kontext nicht vorkommt?

Mit alle Versionen meinte ich nicht base->f<T>(), base->f<int>(), base->f<U>() ..
sondern eben Base::f<T>, Derived1::f<T>, Derived2::f<T>, also alle überschriebenen Funktionen in Derived Klassen.

Das was du meinst bespreche ich ja in Problem 2.

wenn sich das zeug nicht in fremden übersetzungseinheiten befindet, hat man damit keine probleme. Sind halt die gleichen einschränkungen wie für templates. Natürlich ist das für unsre Fabrikfanatisten nicht so toll, da man die Derived nichtmehr sogut verbergen kann, aber ich denke, da kann man sich auch ne lösung für einfallen lassen.

Und was machst du wenn die Derived Klasse sehr wohl in einer andren
Übersetzungseinheit ist ? Undefined Behavior, nur deswegen ? Oder eventuell
die Hierachie versiegeln, was meiner Meinung nach irgendwie gegen Polymorphie
spricht ?

Entweder es funktioniert in unterschiedlichen Einheiten auch
oder gar nicht. Neue potentielle Fehlerquellen brauch ich nicht
im neuen Standard ..

da ich nicht weis, wie der compiler das bei normalen templates handelt, kann ich dazu erstmal nichts sagen, vielleicht kann sich ja jemand melden, der en bissl ahnung von compilern hat...

Muss man auch gar nicht verstehen. Normale virtuelle Funktionen werden in einer
Übersetzungseinheit definiert und der Compiler kann bereits die vtable erstellen
da er weiß wie groß sie sein wird (für jede virtuelle Funktion ein Eintrag).
Bei virtuellen Template Funktionen kann er das aber nicht bei der Definition
machen, aus dem Grund, dass man eben nicht unendlich Speicher für die vtable zur
Verfügung hat. Also müsste er warten und anhand der Aufrufe bestimmen für welche
Typen die Funktion benötigt wird. Das ist aber aus bereits genanntem Grund vom
Compiler nicht möglich.

Weiß ja über vtables selbst auch nicht recht viel, drum kanns leicht sein,
dass das ein oder andre ne etwas naive Darstellung des Konzepts ist. Man möge
mir solche Fehler bitte verzeihen.