C++ 0x
-
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
-
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.
-
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.
-
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
-
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.
-
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
-
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^^
-
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.
-
Das Problem mit den GUIs sehe ich auch nicht. Schließlich gibt es ein paar portable C++-GUI-Libs (WxWidgets, Fltck). Warum also kein Standard für GUIs? Java hat schließlich auch nen Standard. Java-Programme haben halt ein Java-Look and Feel. Warum kein c++-Look and Feel. Oder verschiedene wie bei Swing.
Außerdem muss es ja auch keine vollstängie GUI-API sein. Es genügen für den Standard doch die Grundfunktionalitäten zum Zeichnen der Controls, Mouse-Events ... . Damit können dann Bibliotheken mit verschiedenen Konzepten implementiert werden. Und diese sind dann per se plattformunabhängig sein. Die Bibliothekenentwickler könnten sich dann auf ihre jeweilige Funktionalität konzentrieren und müssten nicht die Hälfte der Zeit darauf verschwenden, sich mit den verschiedenen Plattform-Eigenschaften auseinanderzusetzen.
Das es das nicht auf allen Systemen ne graphische Ausgabe gibt, ist Augenwischerei. Es gibt auch Systeme, auf denen man keine Dateien speicher kann und es gibt bestimmt auch solche wo man nicht dynamisch Speicher reservieren kann.
In den Standard gehörte noch viel mehr high-Level rein rein: XML-Parser, SOAP und CORBA, Sound-API, Application-Frameworks und keine Ahnung was alles.
Das ist doch der große Vorteil von Java:
C++ als Sprache is ja viel geiler, aber in Java gibts für alles ne Standard-Bibliothek.
Klaro gibts für das in C++ immer gute Bibliotheken. Aber blos wenn ich jetzt mal nen farbigen Text auf der Console ausgeben will, muss ich mich ins Internet begeben, nach verschiedenen Implementierungen suchen, mich bei mehreren reinlesen, ob die denn gut ist, schauen, ob da ne aktive Community dahintersteht, damit mir jemand helfen kann, muss ewig rumtun, bis es bei mir compiliert und linkt etc..
Es sollte für alles gebräuchliche etwas im Standard geben, auf das ich mich verlassen kann. Etwas das gut ist. Es kann ja immer noch für diesen und jenen Zweck dritt-Implementierungen geben, die besser sind. Aber ich will was für den Otto-Normal-Fall. Die Entwickler alternativer Bibliotheken hätten dann ne Vorgabe, an der sie sich zu messen haben.
In der c++-Community gehn so viel Resourcen drauf, weil zig Bibliotheken zig DOM-Parser implementieren.An low-Level-Sachen wünsch ich (außer an den Sachen die eh schon erwähnt worden sind) type_of (das wird wohl was) und reflexions (das wird wohl nix).