C++ 0x

Gibts in DOS Threads? hmmmmmm?

Artchi

Kann man in DOS problemlos implementieren. "Threads" konnte selbst mein C64, wurde nur halt mit Interrupts der CPU gelöst. Aber hat funktioniert! Alle Spiele und Scenedemos konnten gleichzeitig im Background Musik und Gfx-Effekte ablaufen lassen. Nur der Begriff hieß halt Interrupts, unter DOS und x86-CPUs gibts bestimmt auch sowas. Wobei bei den x86-CPUs glaub ich ein Interrupt was anderes als auf dem C64 ist.

maximAL

gibts nicht genug multi-plattform GUI libraries?...

Kann diese Argumentation was Plattformunabhängigkeit bzgl. GUI betrifft nicht nachvollziehen. Der Standard kann doch Schnittstelle und Semantik für eine GUI vorschreiben und der Code wäre letztlich wieder auf den gängigen Systemen verwendbar.

Oder noch besser direkt zweigleisig fahren. D.h. einmal mit einer GUI, Socket, Thread, Boost und weiterem Luxus ausgestatteten Version mit der Zeit gehen und zum anderen einen abgespeckten Standard für eine Version im embedded Bereich anbieten.

Die Zeiten ändern sich. Vielleicht sollte diese angestaubte, minimalistische C++ Philosopie es auch tun.

rüdiger

naaa? schrieb:

Gibts in DOS Threads? hmmmmmm?

Nicht nur, dass man es emulieren könnte. Aber der Punkt ist ja, dass man die Standard Library in zwei Teile aufteilen sollte, einmal einen "Erwarteten" und einmal einen "Optionalen".

gibts nicht genug multi-plattform GUI libraries?...

Aber mit keinem zufrieden stellenden Resultat, vorallem nicht im C++ Bereich. Außerdem wäre eine GUI Library zu umfangreich für den C++ Standard. Da könnte man wenn eher einen eigenen Standard für machen. Da gibt es ja von IEEE Motif als Standard. Aber das ist ja auch nicht mehr Zeitgemäß. Der GUI Bereich ist einfach zu unsicher und ändert sich extrem schnell.

terraner

Michael E. schrieb:

terraner schrieb:

Außer der option ios::binary würde mir da gerade nix einfallen. Auf die sollte man aber auch verzichten.

Was? Du willst auf ios::binary verzichten

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 )

mfg

otze

Ja, denn ios::binary ist
- nicht portabel (CPU- und OS-abhängig, z.t. gar nicht unterstützt
stimmt, portabel ist es nicht unbedingt
- nicht zwischen mehreren versionen des selben programms nutzbar, wenn sich zuviel ändert
und wieso? hatte in der hinsicht noch nie probleme
- nur schwer für tiefe objekt-hierarchien nutzbar
was haben denn objekte damit zu tun?
- leider nicht in der lage irgendetwas anderes als char zu speichern
unterscheidet sich damit aber auch nicht von den andren modi

und leichter zu komprimieren sind text-dateien auf jeden fall (wer lust und spaß dran hat )
halt ich fürn gerücht, da man bei binaries wohl genau die gleichen komprimierungsmethoden verwenden kann(mal davon abgesehen, dass man nicht aufpassen muss, dass man kein \0 reinschreibt...)

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.

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

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.

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.

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

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

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.