VAC++ Typumwandlung

(DE) Anwendungen für Office, Multimedia und Spiele, Werkzeuge, Hilfsprogramme, etc
(EN) Applications for Office, Multimedia or Games, Tools, Utilities, e.g.
Antworten
MKH
Beiträge: 119
Registriert: So 1. Jul 2018, 08:18

VAC++ Typumwandlung

Beitrag von MKH »

Hallo zusammen,

ich spiele gerade ein wenig mit VAC++ herum. Es fängt schön langsam auch an, richtig Spaß zu machen. Danke nochmals an Mike für das C++ Paket!
Das Problem ist natürlich, dass heutige Bücher einen weitaus moderneren C++ Standard voraussetzen und sich dadurch die eine oder andere Hürde herauskristallisieren wird.

So stellt sich mir z.B. aktuell die Frage, wie man einen Typ korrekt in einen anderen umwandeln kann.

Die althergebrachte Methode wäre wahrscheinlich die folgende:

float fval = 123.123;
int ival = int(fval);

Gibt es unter VAC++ vielleicht auch eine generische Methode zur Typumwandlung? Borland C++ 2.0 scheint soetwas zu besitzen:

static_cast< T > (arg)

Für einen kurzen Ratschlag wäre ich sehr dankbar.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Mehr allgemein:

Ich suche meistens nach "C <engl. Ausdruck>" und gehe dann zu dem, was mir angeboten wird, bevorzugt zu stackoverflow.com und vieleicht noch geeksforgeeks.org.

Ein Beispiel zu Deinem Fall: "c cast conversion float" Die Inhalte sind natürlich linuxlastig. Man sieht dabei wie alt die IBM-Portierung der stdlib ist. Was man noch findet, ist Windows-Zeugs, dass immer CPP und Visual Studio voraussetzt. Das C-Zeugs von stackoverflow.com (und anderen) ist schon relativ hochwertig und häufig auch so unter VAC verwendbar.
Andreas Schnellbacher
MKH
Beiträge: 119
Registriert: So 1. Jul 2018, 08:18

Beitrag von MKH »

Danke für den Tipp mit stackoverflow.com!

Je weiter ich in meinem Buch voranschreite umso weniger sind die Beispiele direkt umsetzbar. Aber damit war ja zu rechnen und tut der Sache keinen Abbruch. Hat jemand vielleicht einen Tipp für ein C++ Nachschlagewerk aus jener Zeit? Dank Internet ist ja vieles noch gebraucht zu bekommen. Und ich lese einfach viel lieber in Büchern ;)
_diver
Beiträge: 306
Registriert: Fr 27. Jun 2014, 10:57

Beitrag von _diver »

Was ist eigentlich der Grund das du vac++ nimmst und nicht gcc?
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

Entschuldigung, dass ich mich einmische,

ich benutze gcc generell nur ungern weil:
1) ich zu makefile Zeiten großgeworden bin und mich nie mit dem "configure" Zeug anfreunden konnte. Ich weiss bis heute nicht genau, wie das funktioniert und was damit erreicht werden soll (was über eine nackte makefile hinausgeht). Und deshalb weiss ich eben auch nicht, wie man selbst ein "Build Projekt" anfängt (also angibt, welche Dateien zu kompilieren sind, welche Dependencies bestehen und welcher Output zu erzeugen ist).
Aber Silvan, ich bin froh, dass du mir da bei dem einen oder anderen Projekt schon in die Steigbügel geholfen hast !

2) weil ggw. der gcc debug output nicht mit dem IBM VAC debugger gedebugged werden kann, obwohl das eigentlich gehen sollte. Aber lokale/Stack Variablen können nicht gedebugged werden und damit ist Sourcecode Debugging quasi unmöglich. Dieses Problem ist ja schon bekannt:
https://github.com/bitwiseworks/gcc-os2/issues/34
Ich würde sehr gerne helfen, das Problem zu beheben aber mein Kenntnisstand reicht diesbezüglich (.stab info) sicher nicht aus. Genau dieses Problem ist für mich ggw. das NoGo.

3) weil die Dokumentation zum gcc Compiler Stückwerk ist. Natürlich findet man Dokumentation im Internet, aber die sagt einem nicht, welche Compiler switches von der OS/2 Version unterstützt werden und insbesondere nicht, welche zusätzlichen Switches die OS/2 Version kennt. Auch ist unklar, welche neuen keywords von der OS/2 Version unterstützt werden. Ich hatte z.B. schon das "_Thread_local" keyword in einem Programm (das wurde mit dem C11 Standard eingeführt). Das wurde zwar vom OS/2 gcc akzeptiert, führte dann aber zum Absturz des übersetzten Programms bei dessen Ausführung.

4) weil ich nie weiß, was von der POSIX API, PTHREAD, etc. nun unterstützt wird und was nicht. Es gibt da so viel und manches gibt es und manches nicht. Deshalb neige ich oft dazu, einfach die plain OS/2 API zu benutzen. Aber mit LIBUSB habe ich mich nun an die PTHREADS API gewagt und das was ich davon gebraucht habe, hat schon mal funktioniert :-)
Aber z.B. "pipe" wird nicht unterstützt und auch nicht "sem".

Mir ist klar, dass der gcc alleine schon ein Mammut Projekt ist. Mir ist auch klar, dass man die Probleme nicht an einem Nachmittag löst und dass man dafür detaillierte Kenntnis von Debugging Formaten etc. besitzen muss.


Gruß,
Lars
_diver
Beiträge: 306
Registriert: Fr 27. Jun 2014, 10:57

Beitrag von _diver »

Einiges was du schreibst ist wirklich so. Aber dass man für gcc configure braucht ist natürlich komplett falsch. Ein makefile reicht da auch aus oder sogar ein einzeiler wen es nur ein .c file ist. Configure wird von großen Projekten genommen um ein makefile zu erstellen. Dann ist immer make zuständig um es abzuarbeiten.
Dass wir nicht ganz alle Features unterstützen stimmt auch. Jedoch wirklich die meisten. Und die os2 spezifischen sind irgendwo dokumentiert so viel ich weiss.

Und man kann/darf ja os2 apis direkt nutzen. Man muss keine posix Sachen nehmen. Gcc ist ja nur ein compiler im Endeffekt. Har hat viele dinge die neu sind mit drin und vac kennt halt nur noch altes Zeugs. Das war ja auch einer der Gründe warum damals gcc portiert wurde.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

Ich nehme, dass einer der Gründe war, dass man eben Linux Projekte ( z.B. aus GitHub) problemlos bauen kann. Und die benutzen eben die Posix API und das andere Linux spezifische Zeug. Und das ist dann eben auch die Lösung. Aber ich hab eben von Linux und Unix keine Ahnung.
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Hoffentlich liest Silvan hier noch mit. Ich hab gerade nach den OS/2 spezifischen gcc Options gesucht. Leider finde ich die hier -
https://github.com/bitwiseworks/gcc-os2
https://github.com/bitwiseworks/gcc-os2/wiki
https://github.com/bitwiseworks/gcc-os2 ... /README.md
nicht. Ich meine aber, diese schon mal irgendwo gesehen zu haben.

Auch diese Aussage auf der obigen Seite verwundert mich ein bißchen - "Then simply type the following on the command line prompt to install GCC (together with WLINK used for linking object files generated by GCC into OS/2 executables)". Also gcc zum kompilieren und wlink zum linken.

In der gerade laufenden Diskussion auf os2world (https://www.os2world.com/forum/index.ph ... 978.0.html) meint Dave aber, wlink war nur früher fürs linken von Mozilla (xul) nötig. Jetzt nimmt er emxomfld. Für kleinere Programme scheint gcc fürs compilieren und linken die bessere, einfacher Wahl zu sein.

Irgendwie fehlt mir die Dummy Anleitung für "modernes Programmierung" unter OS/2. Also aktueller Compiler ohne die Beschränkungen des icc (einschließlich icc4) --> gcc. Und die nötigen Options.

Aktuell hab ich fürs kompilieren -
gcc -c -lcx -O0 -Wall -Wextra -Zomf -g main.c -o main.obj
Fürs linken -
gcc -lcx -Zexe -Zomf -Zmap -g main.obj

Ein .dbg file kann ich aber noch nicht erzeugen. Oder wäre da eh nicht mehr Info drinnen als in dem vom .map file erzeugten .xqs?
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

So wie ich Silvan verstanden habe benutzt du separat "emxomfstrip" um die debug Info aus dem Executable rauszuziehen und sie in eine Datei (die .DBG) Datei zu schreiben. Das kann man ja gut als Postprocessing Step in einer makefile unterbringen.
Da ist definitiv mehr Info drinnen als in einer .SYM oder .XQS Datei: letzteres enthalten nur "Public" Symbole mit ihren Addressen während ersteres auch Information über den Offset von Stackvariablen enthält sowie Line number info (also welche Sourcecode Zeile in welcher Sourcedatei).
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Danke. Die ganzen emx.... Programme kenne ich nicht. Ich dachte immer alles EMX ist veraltet. Man lernt nie aus ;-)

Ich schließe daraus, während der Programmentwicklung kann man mit .dbg Files Traps besser im exceptq Report analysieren. Ist vielleicht sinnvoll, weil wir ja gcc Programme nicht perfekt debuggen können. Für Release Builds kann man nur .xqs Files mitliefern, wenn man ohne -g kompiliert/linkt. Irgendwie eh logisch, wenn keine Debug Infos im optimierten (-O3) .exe drinnen sind, kann man kaum mehr auf Sourcezeilen verweisen.
_diver
Beiträge: 306
Registriert: Fr 27. Jun 2014, 10:57

Beitrag von _diver »

Andi B. hat geschrieben: Di 25. Jan 2022, 09:13 Danke. Die ganzen emx.... Programme kenne ich nicht. Ich dachte immer alles EMX ist veraltet. Man lernt nie aus ;-)

Ich schließe daraus, während der Programmentwicklung kann man mit .dbg Files Traps besser im exceptq Report analysieren. Ist vielleicht sinnvoll, weil wir ja gcc Programme nicht perfekt debuggen können. Für Release Builds kann man nur .xqs Files mitliefern, wenn man ohne -g kompiliert/linkt. Irgendwie eh logisch, wenn keine Debug Infos im optimierten (-O3) .exe drinnen sind, kann man kaum mehr auf Sourcezeilen verweisen.
man braucht keine .dbg files solange der debug teil nicht entfernt wurde im exe. wir liefern die dbg files nur aus in speziellen rpm, damit die exe kleiner werden. und -O2 hat auch nix mit debug info zu tun. wir erstellen alle rpm mit -O2 -g. Und anschliessend wir es mittels emxomfstrip der debug teil entfernt
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

Es ist mir tatsächlich neu, dass man unter gcc gleichzeitig optimiert und trotzdem mit Debuginfo (-O2 -g) übersetzen kann. Beim ICC geht das nicht, entweder optimiert (-O) oder mit Debuginfo (-Ti), aber nicht beides gleichzeitig. Wieder was gelernt...
Antworten