Infos über neuen C++-Standard? Thread Nr.2
-
der alte thread müsste wegen überlänge geschlossen werden
hier gehts dan weiter
-
Marc++us:
GUIs sind was reichlich Überflüssiges, das im Endeffekt nur Zeit kostet und viel zu viele Entwickler verschwenden ihre Zeit damit heraus zu finden, wie man eine Liste gleich alphabetisch sortiert füllt und wie man einen 3D-Schatten hinbekommt.
Ja! Da sind wir uns sicher alle einig und das fast alle C(++) GUI Librarys dafür sorgen, dass das GUI Konzept 10 mal so hässlich und aufwendig wird, sollte uns auch klar sein. Das wird auch kein Standard ändern
Ok, natürlich ist es nicht nur Verschwendung, die Kunden wollen das so haben, ist also wichtig für die Akzeptanz. Aber es ist aus Sicht der Softwareentwicklung keine sinnvolle Beschäftigung.
Ja, alle wollen hier ein klick, da ein klick und schon soll alles laufen. Da kann man leider nichts machen (also ich glaub nicht, dass man lange lebt als Firma, wenn man nur Konsolen Programme Herstellt ;))
Vor allem die zweite Forderung bricht fast jeder Klassenbibliothek das Genick, weil dazu eben auch Designtools und Editoren gehören. Und das auch noch portabel... mir fällt im Moment nur CLX ein.
Wieso gehören da auch noch Editoren zu? Eigentlich ist es doch Okay, wenn du die Tools in deine lieblings IDE XYZ reinpacken kannst, dann sparst du dir auch noch das umziehen von deiner IDE zu einer anderen und die CLX läuft doch AFAIK nur unter Windows und Linux, nicht wirklich portabel (ja, es gibt irgend wo noch Leute auf der Welt, die mit Mac oder anderen Unix Derivaten arbeiten und ja, die wollen auch mit tollen Klick-Bunt Programmen arbeiten ;)).
Das ist wesentlich für eine Auswahl eines Tools - Oberfläche 4 Wochen oder 2 Wochen? Das ist ein Unterschied von rund 9000 EUR.
Deswegen würde ich Backends in C++ schreiben und die GUI mit irgend etwas portablen draufpacken, wie Java oder Python und was es da alles gibt, hauptsache man hat schnell eine GUI zusammen geklickt und kann halbwegs sein Backend ansteuern.
die gut anwendbaren GUI-Libs bringen regelmäßig auch eigene Klassen für Threads und Filezugriffe mit, [...] Dadurch weichen die Entwickler in der Praxis selbst für solche noch leichter standardisierbaren Dinge wie Multithreading auf nicht portable Libs aus.
Ja, dass ist wirklich ein Problem. Die meisten GUI Librarys erzwingen, dass man kaum noch die Std Library benutzt oder andere zuverlässige Librarys, GTK(+/mm) ist da wohl der einzige Ausweg, den ich kenne, da weiß ich aber nicht was die an Tools zum GUI erstellen haben, was für das normale entwickeln diese Librarys wieder disqualifiziert
Ich sehe daher die Purifikation des Standards von C++ als das größte Hindernis einer Weiterentwicklung.
Ja! Ich finde, man sollte den Weg gehen. Es gibt ein Low Level C++, mit dem was man erwarten sollte von einem Compiler und ein Höheren Teil, der ist dann eben nicht auf allen Systemen verfügbar, wer diesen Teil benutzt wird sich aber im klaren sein (und auch gar nicht als Ziel haben), dass sein Programm auf einem Toaster läuft oder er damit eine Straßenbahn oder indische Mondrakete steuern kann. Im neuen C Standard hat man ja auch so einen Weg eingeschlagen und ich sehe da keine Probleme.
Seien wir realistisch, es gibt doch zur Zeit kaum eine Sprache, mit der reale Applikationen (hey, man kann nicht mal die Cursorposition in der Konsole ändern) auf verschiedenen Entwicklungssystemen inkompatibler zueinander werden als mit C++.
C, Fortran ...
Aber du hast natürlich recht.Auf dem Thema GUI, Threads und Sockets sehe ich für C++ den Zug abgefahren - diese Zersplitterung in Libs, kommerzielle wie freie, fängt niemals jemand wieder auf.
Ja
Lars:
Deswegen finde ich auch sollten Sockets, Files, Threads, Hashcontainer und und und viel mehr zu der STL gehöhren. Umso mehr um so besser, denn um so niedrieger der Anreiz an kommerziele Libs diese neu zu programmieren.
Naja es gibt viele Librarys, die trotzdem noch für jeden scheiß eine eigene Klasse haben, siehe QT und MFC und die VCL/CLX werden so etwas auch haben.
Umso mehr um so besser, denn um so niedrieger der Anreiz an kommerziele Libs diese neu zu programmieren.
Das glaube ich nicht, da die Librarys ihre eigenen Dinge implementieren um bessere Kontrolle über die Implementierung zu haben. Wenn man sich allein anschaut, was der MSVC mit Templates und der StdLibC++ für Probleme hat, kann einem schlecht werden, da ist es verständlich, dass die QT eigene Klassen mitbringt (die MFC bringt solche Dinge sicher nicht aus portabilitäts Gründen mit, dass ist aber ein anderes Thema ;)).
Dimah:
aber ich denke wir bekommen bald ne gute gui lib, das was in Modern C++ und co. gelehert wird muss auch mal bald früchte tragen
Ich glaub GTKmm ist da schon auf dem richtigen Weg.
-
irgendwie nutzen die ganzen GUI Libs net mal das Prinzip der Iteratoren. Dabei ist das genial.
-
Ich glaub GTKmm ist da schon auf dem richtigen Weg.
unter http://gtkmm.sourceforge.net/features.shtml
Cross-platform: Linux, Solaris, Win32, others
aber für win32 finde ich da nix
-
[OT]Ich lese jetzt schon lange sehr interessiert mit, ich finde die zwei Threads sollten ins Archiv der besonders interessanten Diskussionen![/OT]
-
Original erstellt von Lars:
irgendwie nutzen die ganzen GUI Libs net mal das Prinzip der Iteratoren. Dabei ist das genial.Ich halte die Umsetzung von Iteratoren in C++ (der 'STL') nicht gelungen. Iteratoren haben dort zu viele (2) Aufgaben: Das Navigieren durch Container und das Auslesen/Setzten von Werten.
<ot>Edit: 1000 Postings! *freu* :)</ot>
[ Dieser Beitrag wurde am 17.01.2003 um 21:27 Uhr von Daniel E. editiert. ]
-
Original erstellt von kingruedi:
Deswegen würde ich Backends in C++ schreiben und die GUI mit irgend etwas portablen draufpacken, wie Java oder Python und was es da alles gibt, hauptsache man hat schnell eine GUI zusammen geklickt und kann halbwegs sein Backend ansteuern.jo!
wenn man erstmal 3 sprachen (der algol-gruppe) kann, dan kosten einen die nächsten 6 sprachen (der algol-gruppe) jeweils ein langes wochenende.und es ist saugeil, zu jeder anwendung eine geignete sprache zu nehmen. gerade hab ein perl-script laufen, das ne dos-batch laufen läßt, die zwei c-pogs, ein c++-prog, und dann wieder ein c-prog laufen läßt. das perl-script überwacht, ob änderungen der dateidaten da waren. wenn ja, wird einfach alles neu compiliert und ausgeführt und ich krieg die ausgabe. ähnlich locker gehe ich mit java und c# um. ich werde diese sprachen niemals lieben, wie ich mal c++ liebte, aber als werkzeug stets benutzen, wenn sie sich anbieten.
und mit der großen diskrepanz zwischen "ich mag c++ benutzen, weil es die einzige sprache ist, die mir erlaubt, echt OO zu schreiben" und "ich hasse c++, weil ich nichtmal nen cursor bewegen kann und alle großen libs zum kotzen sind" muß man offen für weitere sprachen sein.
-
Original erstellt von Daniel E.:
**Ich halte die Umsetzung von Iteratoren in C++ (der 'STL') nicht gelungen. Iteratoren haben dort zu viele (2) Aufgaben: Das Navigieren durch Container und das Auslesen/Setzten von Werten.<ot>Edit: 1000 Postings! *freu* :)</ot>
[ Dieser Beitrag wurde am 17.01.2003 um 21:27 Uhr von [qb]Daniel E.** editiert. ][/QB]
und warum lassen die sich nicht vereinen? Wie würdest du deine listenklasse implementieren?
-
Original erstellt von Lars:
[QB]und warum lassen die sich nicht vereinen?[qb]Weil sie nicht das gleiche machen ...?
Die Konzepte können/sollen miteinander interagieren, aber sie sollen nicht identisch sein. Sie tun schließlich nicht das Gleiche.
[Und man sollte zwischen Lese- und Schreibzugriffen explizit unterscheiden können - dann geht gleich der Mist mit const_iterator, iterator usw. über Bord. Iteratoren liefern beim 'dereferenzieren' eben eine eindeutige 'Kennung des Objekts', mit dem der Iterator 'verknüpft' ist. Diese Kennung kann im einfachsten Fall eine Referenz sein.]
-
Also übers typeof sind wir uns dann ja inzwischen einig.
Was mich aber eigentlich besonders stört am std::for_each ist noch nicht mal, dass man die Schleife in eine extra funktion auslagern muss (meine Schleifen sind normalerweise eh größer als eine Zeile), sondern dass man ja noch nicht mal jede Funktion aufrufen kann! Bei Methoden muss man mit nem Funktionsadapter rumtun, und die Binder sind ja wohl die allerletzte Krücke und wenn man mehr als zwei Parameter hat, müsste man auch noch anfangen selber das Teil zu basteln...
Deswegen möcht ich noch ein neues Schlüsselwort einwerfen
Beim CBuilder gibts das __closure. Damit kann man Memberfunktionen wie normale behandelnvoid __closure(*DoSomething)(int);
is ein Funktionszeiger für jede Methode, die ein int bekommt. Man spart sich das ganze mem_fun und mem_fun_ref getue (und regelmäßige im Forum gestellte Fragen).
Ach ja*
The ISO C++ standard is now about two and a half years
old. In about another two and a half years it could be
revised, amended, or - of course - left alone.*hm, wann wurde der Standard verabschiedet? 97? Welches Jahr haben wir jetzt?
aus http://www.research.att.com/~bs/kbh-C++0x.pdf
[ Dieser Beitrag wurde am 18.01.2003 um 05:18 Uhr von kartoffelsack editiert. ]
-
97 veröffentlicht und 98 festgelegt.
@Dimah
http://cvs.gnome.org/lxr/source/gtkmm-root/base/README.win32ist wahrscheinlich ein bissel kompliziert, da GTKmm ein Wrapper eines Wrappers ist
wenn man erstmal 3 sprachen (der algol-gruppe) kann, dan kosten einen die nächsten 6 sprachen (der algol-gruppe) jeweils ein langes wochenende.
bei dir bin ich mir manchmal nicht sicher, ob du gerade ironisch bist oder das wirklich ernst meinst
void __closure(*DoSomething)(int);
is ein Funktionszeiger für jede Methode, die ein int bekommt.
Ich verstehe nicht ganz wie das funktionieren soll, hast du vielleicht ein Beispiel dafür?
@DanielE.
<ot>Edit: 1000 Postings! *freu* :)</ot>
herzlichen Glückwunsch
-
Original erstellt von kingruedi:
[QB]@volkard
wenn man erstmal 3 sprachen (der algol-gruppe) kann, dan kosten einen die nächsten 6 sprachen (der algol-gruppe) jeweils ein langes wochenende.
bei dir bin ich mir manchmal nicht sicher, ob du gerade ironisch bist oder das wirklich ernst meinst[QB]Wohl kaum ironisch.
Etwas ähnliches hat mal ein Dozent bei uns gesagt: lernen Sie eine Programmiersprache gründlich. Wenn Sie dann mal jemand freitags fragt, ob Sie montags ein Programm in einer Sprache programmieren können, dann sagen Sie ruhig ja.
-
Naja das hörte sich ein wenig übertrieben an.
-
Original erstellt von kingruedi:
**@Dimah
http://cvs.gnome.org/lxr/source/gtkmm-root/base/README.win32ist wahrscheinlich ein bissel kompliziert, da GTKmm ein Wrapper eines Wrappers ist
**kenne ich schon, bissel kompliziert ist gut
-
Original erstellt von Marc++us:
**
Etwas ähnliches hat mal ein Dozent bei uns gesagt: lernen Sie eine Programmiersprache gründlich. Wenn Sie dann mal jemand freitags fragt, ob Sie montags ein Programm in einer Sprache programmieren können, dann sagen Sie ruhig ja.**Das einzige was dabei nervt sind die fehlenden Vokabeln der Sprache....
-
Marc++us:
Typische Embedded-C++-Dialekte lassen ohnehin gleich die Masse der Stdlib weg, und in der Sprache sterben als erstes die Templates. Da gibt's sogar einen Industriestandard zu Embedded-C++, ohne Templates, demnach ohne STL. Da blutet dem ISOisten doch das Herz.
-
was ich mir noch wünche ist das nan die grösse eines dynamischen arrays rausbekommen kann, die grösse wird ja jetzt schon irgend wo gespeicher (wie sonst könnte delete[] arbeiten)
und immer die ausrede, ne das können wir nicht weil ein toster das nich so gut kann
-
was ich mir noch wünche ist das nan die grösse eines dynamischen arrays rausbekommen kann
Und wozu soll das gut sein? Erstens habe ich die größe sowieso, da ich sie ja angeben muss. Und zweitens gibt's da ja auch noch sowas schönes wie Container.
Außerdem müsste der C++ Standard sich dazu in die technische Details der Implementation einmischen.
-
Original erstellt von HumeSikkins:
Und wozu soll das gut sein? Erstens habe ich die größe sowieso, da ich sie ja angeben muss. Und zweitens gibt's da ja auch noch sowas schönes wie Container.aber die grösse verlierst du schnell wenn du das array an eine funktion übergibst,
container machen ihre arbeit gut, aber was ist dagen zu sagen sich eine möglichkeit offen zu haltenaußerdem tut es mir weh, jedesmal wenn ein newbie kommt und fragt wie man die grösse eines dynamischen arrays bekommt und ich muss ihn sagen das er es extra speicher muss,
z.b. java oder c# können das auch, ok sie haben ein gc und bei denen ist es nicht so gefährlich mir dynamischen arrays zu arbeiten, aber verspert uns der standard möglichkeiten damit neulinge zu container gezwungen werden?Original erstellt von HumeSikkins:
Außerdem müsste der C++ Standard sich dazu in die technische Details der Implementation einmischen.bei delete[] haben die aber schon, wenn nicht hätten wir jetzt ein delete[size_t n]
-
Und gib mal ein Beispiel, wie du das implementieren würdest, dimah