PureBoard

Hallo jacdelad,

ich würde mir gerne die Paramater des gcc-Aufrufs den pbcompilerc macht ansehen und beeinflussen.
Es gibt da so einen Parameter -S und Du hast Dein ASM-Backend zurück.
Kennst Du ein Programm, dass die aufgerufen Parameter ausgibt und, oder beeinflussen kann?

@jacdelad , gerne Antworte ich dir. Ich sehe das ja auch nicht als bösartige Kritik.

Woher kommt meine Einschätzung? PB und seine Libs sind teilweise noch echte Baustellen. Ich arbeite seit der ersten Version mit PB. Ich habe also die Entwicklung mitverfolgt. Ausserdem schwingt ein bissel Egoismus mit. Mir wäre es halt lieber wenn PB endlich 3D mal auf ein ..... Aktuelleres Niveou bringen würde. Nicht das ich das jemals ausnutzen könnte. Mir erschliesst sich einfach nicht der Sinn, eines C Backend. C ansich ist doch auch schon veraltet. Und eine Umsetzung als OOP ...... genau um das zu vermeiden benutze ich PB. Wenn PB den Spagat hinbekommt wäre das sicher für einige toll. Wenn die Compiler Zeiten und die Exe Grösse ohne Runtime Lib funktioniert ....... aber das wird es wohl eher nicht. Aber wir werden ja sehen. Und solange das ASM Backend weiterhin versorgt ist. Sehe ich ja auch kein Problem. Und überhaupt. Ist es kein Problem sondern nur Persönliche befindlichkeiten.

Gruss TFT

@tft
Für Kompilate aus dem C Backend heraus werden auch keine Runtimes benötigt. Und eine Programmiersprache ist nur dann wirklich veraltet, wenn sie keinen tiefergehenden Zweck mehr erfüllt. Ich denke wir können uns da einig sein, das C nun wirklich noch eine Rolle spielt. Zudem ist Purebasic dem klassischen C doch sehr ähnlich, was Sprachfeatures angeht, weswegen eine Nutzung eines C Backends auch nahe liegt.

Was die 3D Engine angeht, ist PureBasic auf den Entwicklungsstand der zu Grunde liegenden OGRE-Engine angewiesen. Wenn diese keine größeren Schritte macht, macht auch Purebasic diese nicht. Die einzig sinnvolle Möglichkeit, dies zu modernisieren, ist auf eine andere Engine zu wechseln. Und das kostet immens Zeit und Aufwand. Desweiteren sind die meisten modernen Engines an Toolsets gekoppelt, wodurch die Spieleentwicklung um weitere Tools fragmentiert wird. Kaum einer programmiert/entwickelt noch Videospiele auf diese Art und Weise. Selbst mit einer Engine wie Unreal wird nicht so rudimentär gearbeitet, wie es bei PB der Fall ist. Und aus diesem Grund sehe ich einen starken Fokus in diese Richtung deutlich problematischer für die Entwicklung von Purebasic. Auf Grund der Teamgröße ist zwangsläufig mit Vernachlässigung anderer Bereiche in der Entwicklung zu rechnen. Und so langsam muss Purebasic das ARM Thema fokussiert angehen. Dem Apple M1 sei es geschuldet. Das muss und sollte Priorität haben.

Sowohl c als auch c++ werden weiterentwickelt, für c++ ist der aktuelle Standard nicht mal ein Jahr alt.
Bei OGRE ist es leider so, das die Engine in PB veraltet ist, es gibt da neuere. Das große Problem dürfte aber hier sein: OGRE ist OOP und PB eben nicht. Das was wir bekommen ist eine eigene API, die imo auch ein paar Bugs mit einführt.
Der große Sinn ist, das man so leichter auf andere Plattformen portieren kann. C-Compiler gibts wie Sand an Meer auf jeder Plattform ohne das man sehr viel neues lernen muss. PB kann damit halt auf Rasphery Pie rauskommen - und vielleicht wichtiger - auf Macs aktuell bleiben, die Intel-Plattform ist da "veraltet" und es ist abzusehen, das bald kein Intel-Code mehr auf den aktuellen OS laufen wird. Da ist Apple sehr radikal.
Dazu gibt es einige andere Vorteile: Der Assemblercode von PB ist alles, nur nicht effizient. Die C-Compiler sind einfach ein ganzes Stück besser - besonders die Optimierungen danach hauen wohl richtig rein.
OOP ist übrigens in C-Backend - wenns wirklich nur C ist - völlig unmöglich, dafür brauchts C++.
Weitere Vorteile wären, das man deutlich leichter C-Bibliotheken einbinden könnte. Um ehrlich zu sein, ich seh keine Vorteile in Assembler-Backend. Außer das es langsamer ist und auf lange sicht nicht so flexibel.

edit: der aktuelle C-Standard ist übrigens von Juni 2018...

GPI hat geschrieben: ↑09.06.2021 22:36OOP ist übrigens in C-Backend - wenns wirklich nur C ist - völlig unmöglich, dafür brauchts C++.

Alles richtig, bis auf dieses hier.
Ich mein prinzipiell stimmts schon, keine Frage - aber man kann aus allem was lowlevel ist etwas höherleveliges machen.
Es ist zwar recht sinnlos, aber machbar. Frei nach dem Motto: Auch mit einem Hammer kann man eine Schraube in ein Brett klopfen.

klar kann man, aber nicht mit den Komfor wie es in C++ drin ist. In Prinzip kannst du als ersten Parameter einfach immer das "Handle" des OOP-Objects übergeben und schon haste das.
Aber Sachen wie Operatoren überladen etc. geht dann halt doch nicht. Bin davon kein großer Fan, aber bei Sachen wie Matrizen und Vektoren ist sowas schon sehr praktisch.

Hallo Leute,
PureBasic 6.00 Alpha 3 is verfügbar.
https://www.purebasic.fr/english/viewto ... 14&t=77272

verstehe ich das denn richtig, dass man dann quasi für alle möglichen Plattformen Programme mit PB compalieren kann?

Nein,

Es sind immer noch die Plattformen Window, Linux und macOS. Es wird ja auch ein Betriebssystem und Libraries für PB benötigt.
Aber es werden in Zukunft auch andere Prozessoren unterstützt, wie ARM und M1 (Apple)

ich schiele da auch so mehr so auf ältere Plattformen, da schon seit Jahren ein wieder wachsender Markt an neuer Software, sprich Spiele herausgebracht werden. Amiga, C64, Atari etc. Halt für ältere CPUs wie 6502, z80... Dafür gibt es auch schon passende C Umgebungen, so wie ich das mitbekommen habe. Diese könnte man doch mit ins PB einbinden... ist mir auch klar, dass ältere Systeme gewisse Restriktionen haben. Aber das muss dann halt beim coden mit in Betracht ziehen.
Es gibt eben ein Projekt, da wo man mit Unity c64er Software/Spiele coden kann... wenn das mit PB gehen würde, dann zieht das garantiert den ein oder anderen neue Entwickler an.