Lohnt sich der Einstieg in XBase?

[Ryko]

Hallo XBase Community,
Ich beschäftige mich schon seit einiger Zeit mit Programmieren und schreibe in VB.net.Als ich dann neulich nach ein paar Basic Dialekten gesucht habe binn ich dann mal auf XBasic++ gestoßen und muss sagen das mir die Syntax gut gefällt.Nun habe ich diesbezüglich ein paar Fragen:
1.Ist das OOP Konzept in XBase gut umgesetzt?
2.Wird der Quellcode direkt in Maschinensprache übersetzt oder erst zur Runtime wie z.B. java oder .Net Sprachen.
3.Inwieweit ist die Sprache ausgebaut,kann sie gut mit anderen Sprachen konkurieren?
4.Wie ist XBase Geschwindigkeits Technisch?
5.Wie sieht es mit Multi Threading aus?
6.Kann XBase sprach übergreifend Angewendet werden?
Z.Was gefällt euch noch so an XBase?

Ich denke das sind für den Anfang genug Fragen.

Mit Freundlichen Grüßen Ryko/Rico

[brandelh]

Hallo Ryko,

da hast du aber eine Menge Fragen

... schreibe in VB.net.Als ich dann neulich nach ein paar Basic Dialekten gesucht habe binn ich dann mal auf XBasic++ gestoßen

Xbase++ baut von der Syntax auf Clipper 5.2e auf, der auf dBase zurückgeht, daher Xbase++ ...

und muss sagen das mir die Syntax gut gefällt.

Die Clipper Syntax ähnelt der von Basic, wobei die Dateneingabe ( @ GET ) sehr genau festgelegt werden kann
und die Datenhaltung in DBF mit Indexdateien perfekt umgesetzt wurde ... damals.
Xbase++ nutzt beides, kann aber mit OOP, Win32 API, Drucken, SQL Zugriff (ODBC aktuell, Rest ab Xbase 2.0) deutlich mehr.

Nun habe ich diesbezüglich ein paar Fragen:

nur zu ...

1.Ist das OOP Konzept in XBase gut umgesetzt?

Ich denke schon
Es ist nicht so zwingend wie bei reinen OOP Sprachen (da gab es doch welche ...), man kann Klassen nutzen und auch selbst erstellen.
Mit der Syntax komme ich wesentlich besser zurecht, als mit der von PowerBasic (meinem zweiten Compiler, mit dem Vorläufer TurboBasic habe ich richtig angefangen.)

2.Wird der Quellcode direkt in Maschinensprache übersetzt oder erst zur Runtime wie z.B. java oder .Net Sprachen.

Maschinencode generiert er nicht. Der Vorteil ist, dass man z.B. code in text oder DBF Dateien speichern und zur Laufzeit kompilieren kann.
Der Nachteil ist, dass Xbase++ bei Schleifen etc. nicht so schnell ist wie native Sprachen.
Allerdings hat es sehr mächtige Befehle, die ihrerseits in C/C++ geschrieben sind.
Ich hatte z.B. mit PowerBasic (DOS) einen Texteditor geschrieben. Die normalen Befehle sind wesentlich schneller in PowerBasic,
aber der fertige Texteditor (memoedit()) in Clipper/Xbase war und ist schneller als der selbst geschriebene.
ActiveX Aufrufe sind wohl langsamer als mit nativen Sprachen, bei den DLLs selbst merkt man nichts davon.
Für Geschäftsannwendungen (GUI oder alte DOS Optik) ist es auf jeden Fall schnell genug.

3.Inwieweit ist die Sprache ausgebaut,kann sie gut mit anderen Sprachen konkurieren?

Da man alle Windows API und C/C++ Bibliotheken aufrufen kann, sollte eigentlich nichts fehlen (außer einer IDE wenn man sie braucht),
aber so ganz verstehe ich die Frage nicht.

4.Wie ist XBase Geschwindigkeits Technisch?

das hängt von der Aufgabe ab. C/C++ und PowerBasic Programme sind im eigenen Code schneller.

5.Wie sieht es mit Multi Threading aus?

es ist sehr leicht einen Thread für z.B. Hintergrundaufgaben zu erstellen und so die Oberfläche reaktiv zu halten, auch wenn gerade 1 Million Textzeilen eingelesen werden. Sowas mache ich ab und zu.

6.Kann XBase sprach übergreifend Angewendet werden?

Man kann auf C/C++, Delphi, PowerBasic und wohl auch auf .NET DLLs bzw. ActiveX Komponenten zugreifen.
Wegen der Datentypen muss man ab und zu eine freie Hilfs-DLL (OT4XB) nutzen ...

Z.Was gefällt euch noch so an XBase?

Die Klarheit der Sprache, mit IDE habe ich es nicht so, ich komme von der Clipper / DOS Schiene.
Wer eine GUI-IDE erwartet, wird wohl hier eher falsch sein, da diese erst rudimentär vorhanden ist.
Das wichtigste aber ist dieses Forum hier, wo man kompetente Hilfe erhält.

Ich denke das sind für den Anfang genug Fragen.

uff. ich bin durch, aber auch ich habe eine Frage ...

Wenn du von VB.NET kommst, was erwartest du mehr ?

VB.NET, C# sind doch der Standard mit Rundumversorgung

[AUGE_OHR]

hi,

Nun habe ich diesbezüglich ein paar Fragen:

Hubert hat dir ja schon eine Menge Antworten gegeben ... die Frage ist doch "was" willst du mit der Sprache "machen" ?

Wie Hubert schon in der ersten Antwort schrieb, das Xbase++ auf dBase zurückgeht, was ein Datenbank System ist.
also wenn du irgendwelche "Daten" zum "Verwalten" hast dann bist du hier schon mal richtig

Die dBase Syntax zum "navigieren" in einer Datenbank hat sich seither nicht viel geändert
... nur die "Ausgabe" ist von 80x28 Zeichen durch eine GUI Oberfäche ersetzt.

leider hat Xbase++ z.Z. aber auch einige Beschränkungen eines 32bit Systems übernommen sodas 2GB immer noch eine Grenze darstellt. in "Zukunft" gibt es als Frontend dann auch eine PostgreSQL "Schnittstelle" ( pgDBE ) welches die "gewohnte" Xbase++ Syntax beim "Zugriff" auf Daten verwendet.

was ist Xbase++ NICHT : ein "click" und "fertig" Programm ...

du solltest also dir schon mal eine gute Tastatur zulegen ... willkommen im Club.

[brandelh]

Ach ja, PROBIEREN geht über STUDIEREN ... es gibt eine Testversion von Xbase++, die solltest du dir mal anfordern (falls noch nicht geschehen).

[Tom]

Maschinencode generiert er nicht.

Nicht? Interessant. Was enthalten EXEn und DLLs dann?

Selbstverständlich erzeugt Xbase++ direkt ausführbaren Code. Es ist keine Interpretersprache. Allerdings enthält die Sprache Elemente, die beispielsweise die Erzeugung und Ausführung von Xbase++-Code zur Laufzeit erlauben, hauptsächlich über den Makroexpander.

Und Xbase++ basiert lediglich syntaktisch auf dBase/Clipper, allerdings auch nur noch zu einem kleinen Teil. Es ist eine absolut konkurrenzfähige Sprache, was OOP, GUI usw. anbetrifft. Eine besondere Eigenschaft ist die, dass einige Datenbankengines "nativ" mitkommen, also ohne Zusatzaufwand, als Bestandteil der Sprache selbst verwendet werden können.

[brandelh]

Hallo Tom,

Xbase++ erzeugt EXE und DLL Dateien, das stimmt. Aber meines Wissens wird nicht direkt in Maschinencode übersetzt, sondern in eine Art von P-Code.
Der seinerseits zur Laufzeit über die Runtime abgearbeitet wird. Das ist kein Interpreter, aber eben auch kein reiner Maschinencode.
C# und VB.NET machen etwas ähnliches indem sie den Quellcode in einen Zwischenform (managed code) bringen, die zur Laufzeit abgearbeitet wird.
Das sind auch EXE Dateien - oder nicht ?

Allerdings kann ich aktuell dazu auch nichts finden was das belegen würde.

PowerBasic z.B. übersetzt direkt in Maschinensprache und reserviert automatisch Prozessorregister für häufig verwendete LONG Variablen.

[nightcrawler]

Was enthalten EXEn und DLLs dann?

Die DLLs sind definitiv nicht native Windows ... sonst könnten Sie in ADS als Stored Procedures eingebunden werden.

[brandelh]

Der TIP ist gut

Jede native maschinencode DLL kann von anderen Sprachen aufgerufen werden:

Windows API ... geht.
C/C++, logisch geht das OT4XB ...
Delphi-DLL, geht => RMChart.dll, QuickPDF.dll
PowerBasic, geht => habe ich mit eigenen schon probiert.

Xbase++ DLL kann nur von Xbase++ genutzt werden (soweit ich weiß)
Man kann ja auch C/C++ OBJ Dateien direkt in eine Xbase++ EXE linken, aber eine Xbase++ OBJ in ein C/C++ Programm ? Ich denke nicht.

[Tom]

Das liegt aber nicht daran, dass sie keinen (theoretisch) direkt ausführbaren Code enthielten, sondern daran, dass das Konzept von Xbase++-DLLs nicht dem Standard entspricht.

[brandelh]

Und woher weißt du das ?

Ein Stück Maschinensprache (z.B. eine Funktion) ist ein vom Prozessor direkt ohne weitere Hilfen abarbeitbarer code.
Weder ein Konzept noch irgendetwas anderes kann den dann stoppen Wie ein Stück VIRUS code der an einer Speicherstelle eingeschleußt wird.
Xbase++ benötigt immer die Runtime, ohne Runtime geht gar nix, ähnlich wie ohne .NET kein C# Programm läuft, auch wenn es hinten .EXE stehen hat
Sollte man die RUNTIME in die EXE compilieren können, bleibt es dennoch die Runtime

Aber ich gebe dir dahingehend recht, dass Xbase++ kein Interpreter ist und das hätte man aus meiner obigen Aussage interpretieren können

Weiteres Beispiel:

Code: Alles auswählen

#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
   ? "Hello World"
   WAITKEY$
END FUNCTION 

Die EXE ist 10 KByte groß !

Code: Alles auswählen

#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
   MSGBOX "Hello World"
END FUNCTION 

Diesmal in GUI sind es 7 KByte !

[nightcrawler]

Das liegt aber nicht daran, dass sie keinen (theoretisch) direkt ausführbaren Code enthielten, sondern daran, dass das Konzept von Xbase++-DLLs nicht dem Standard entspricht.

nochmals Konzept und runtime...in VO zum Beispiel wird eine echte Windows DLL erstellt, welche die runtime nachlädt. Daher muss dort nur die Runtime entsprechend im Pfad vorhanden sein. Bei Xbase++ muss die runtime zuerst vorhanden sein, bevor die DLL geladen wird - und das ist dann definitiv nicht native Windows, Konzept hin oder her;)

[Tom]

Ein Stück Maschinensprache (z.B. eine Funktion) ist ein vom Prozessor direkt ohne weitere Hilfen abarbeitbarer code.

So ein Unsinn.

Kompilierter Xbase-Code wird nicht "von Xbase interpretiert" - es ist ausführbarer Code. Der allerdings Komponentenreferenzen enthält, etwa auf die Runtime-DLLs. Auch andere Windows-DLLs wären ohne Windows nicht ausführbar.

[georg]

Hallo,


also, P-Code ist nicht von Hause aus böse. Die Compiler der iSeries von der IBM (ehemals S/38, AS/400, i5, wie auch immer) produzieren P-Code, der zur Laufzeit interpretiert wird. Bei solchen Aussagen denkt jeder an Basic, und das mit mehr oder weniger Gänsehaut. Der P-Code auf der iSeries ist schnell, verdammt schnell. Es ist ja immer die Frage, wie gut der Code "vorgekaut" ist, der von einem Interpreter umgesetzt wird.

Xbase++ arbeitet zwangsweise mit einem vergleichbaren System, um die in Clipper eingeführten Codeblocks abbilden zu können. Codeblocks sind compilierter Code, einer Variablen zugewiesen ist, und über diese Variable ausgeführt werden kann. Da Codeblöcke auch zur Laufzeit erzeugt werden können, müssen entsprechende Mechanismen zur Verwaltung vorhanden sein.

Aber selbst Maschinencode kann eine Katastrophe sein. Meine ersten Cobol-Kontakte (Begegnung der dritten Art) fanden auf einem Siemens BS1000 System statt. DEN Maschinencode, den der Cobol-Compiler erzeugte, trieb jedem Assembler-Programmierer zu Schreikrämpfen. Der war noch nicht mal effizient. Da wäre jeder Interpreter besser gewesen.

[brandelh]

also, P-Code ist nicht von Hause aus böse.

das wollte ich auch nicht damit ausdrücken ...

Bei solchen Aussagen denkt jeder an Basic, und das mit mehr oder weniger Gänsehaut.

Ich mag BASIC, wenn auch nicht unbedingt die alten GOSUB Spagetties ...

[georg]

Hallo, Hubert -


mein Statement ging nicht gegen Dich, sondern bezog sich auf die Frage im ersten Beitrag, sowie die Kommentierungen ob Xbase++ nun Maschinencode oder noch zu interpretierenden P-Code enthalte.

Da ich von der Host-Programmierung komme, war mir Basic von Anbeginn so ein Greuel, dass ich nach ersten vorsichtigen Kontaktversuchen die Finger davon gelassen habe. Und, was hat es mir gebracht? Jetzt programmiere ich in Xbase++ auf dem PC.

[Ryko]

Huch ich wollte hier nun keine Diskussion auslösen
Was ich in meiner Quelle ganz übersehen habe,dass Xbase++ zur Datenverarbeitung und für Datenbanksysteme gedacht ist....
Nungut aber tut auch nicht weh was neues zu lernen^^.

[georg]

Hallo, Ryko -


das war es, was mich an Clipper faszinierte, die direkte Anbindung an eine (aus damaliger Sicht) ordentliche Datenhaltung. Die DBF-Struktur ist in die Jahre gekommen, aber durch die offene Architektur kann man ohne viel Aufwand auch auf SQL Server und dergleichen zugreifen.

Ansonsten: wir sind ein kommunikationswütiges Völkchen hier ...

[Manfred]

Ja,

so sind wir nun mal hier im Forum. Voll und ganz mit dem Herzen dabei.

[Tom]

Was ich in meiner Quelle ganz übersehen habe,dass Xbase++ zur Datenverarbeitung und für Datenbanksysteme gedacht ist....

Das war der Ursprung. Man kann (inzwischen) mit der Sprache fast alles machen, was mit anderen vergleichbaren Sprachen auch geht. Und lass Dich nicht von dem P-Code-Unsinn hier verunsichern.

[Ryko]

@Tom Das hört sich ja schonmal gut an

Wenn du von VB.NET kommst, was erwartest du mehr ?

Mit VB.Net bin ich sehr zufrieden und mit der Sprache komme ich gut klar,aber ich brauche mich ja nicht nur auf eine beschränken.Ich denke jede Sprache hat seine Vorzüge.^^

[brandelh]

Und lass Dich nicht von dem P-Code-Unsinn hier verunsichern.

wie großzügig

Ich stimme aber völlig darin überein, dass es keine praktischen Unterschiede macht, solange man nicht vor hat Hilfs-DLLs für andere Programmiersprachen zu schreiben
Ich nutze fast ausschließlich Xbase++, egal ob Datenverwaltung, Auswertungsprogramme, PDF Druckprogramme, CGI oder einfach Datenumsetzungen aller Art.

[AUGE_OHR]

hi

...,dass Xbase++ zur Datenverarbeitung und für Datenbanksysteme gedacht ist....

gut das wir wieder beim Thema sind.
klar kann man Xbase++ auch für alles mögliche verwenden aber da man kein DirektX etc. verwenden kann ist die graphische Ausgabe auf 2D beschränkt.

von Geschwindigkeit rede ich gar nicht ... man kann ja schnellere Hardware einsetzten wenn es einem nicht reicht ... oder einen anderen Compiler der die xBase Syntax versteht ...

zum Thema PCODE

Harbour is a PCODE compiler. Generated C functions just calling to hb_vmExecute like Clipper was calling to _plankton Generating an obj directly would not be complex, but no extra benefit.

PCODE muss also nicht langsam sein.

[brandelh]

Guter Hinweis