[linux-l] compiler compiler: Bison und Perl

Steffen Dettmer steffen at dett.de
So Feb 8 22:40:47 CET 2004


Hi *,

danke für die vielen Hinweise. Ich antworte hier mal auf Peters
Mail, aber "nur zufällig".

* Peter Ross wrote on Tue, Feb 03, 2004 at 23:43 +1100:
> > In C ist problematisch, wenn man z.B. ne Conncetion hat, die
> > read und write kennt, und man dann plötzlich auf ne Connection
> > trifft, die kein read kennt. read geht dann natürlich, landet
> > eben auf dem nächsten pointer, sprich bei write :)
> 
> Sprichst Du hier ueber eine Netzwerkverbindung? 

Nein, nicht unbedingt. Ist auch egal. Ist auch kein read. Aber
kann man am ehesten damit vergleichen. In der Implmentierung kann
es dann irgendwas sein.

> Dann liesse sich doch zumindest ein Stub generieren... und wenn
> dann C die Sprache Deiner Wahl;-) ist, waere (Sun;-)RPC
> vielleicht das Richtige. 

nee nee, falsche Richtung :-) Das war bloss ein Beispiel für eine
"Klasse". Wichtig dabei war, dass die Applikationen ein Interface
verwenden, also "irgendwas einheitliches", wo eigentlich keiner
weiss, was dann da später passieren wird. Sicherlich wird ne
Connection Bytes versenden können und ne Konfigurationsklasse
Optionen verwenden. Auf PC Systemen wird da sicherlich auch ne
C++ Bibliothek dahinter stehen. Vielleicht wird in bestimmten
Konfigurationen einen Implementierung einer Funktionalität über
eine Art RPC per Proxy-Implementierung zugegriffen, gerade für
Tests scheint das denkbar. Aber das muss natürlich alles hinter
dem Interface versteckt sein. Die Applikation darf davon
natürlich nichts wissen (mal von einem Initialisierungsteil
abgesehen).

Ich wollte einfach nur fragen, ob es ein Tool gibt, mit dem man
einfache Klassendeklarationen aus C++, Java oder IDL Format in
C-Header (vielleicht mit Skeletonimplementierung) erzeugen kann
aber "mehr nicht", also keinen RPC Code, kein CORBA marschalling,
nichts, nur einfach Header und vielleicht Skeletons.

Dann zur Frage zu C vs. C++. Hätte ich die Wahl, würde ich
sicherlich C++ einsetzen. Wie bereits angedeutet, spielen hier
weitere Gründe eine Rolle. Mit einem C Interface ist es möglich,
eine schlanke Implementierung zu erzeugen, beispielsweise eine
Service-Bibliothek für ein Geräte mit 64KB Speicher oder so. Es
gibt andere Gründe, die zumindestens momentan gegen C++ sprechen.
Ebenso kommen Ada, Java, Perl und Phyton nicht in Frage, auch
wenn sie im Gegensatz zu C eine direkte OO Unterstüzung anbieten.

Der verfügbare Compiler kann wohl "eingeschränkt" C++, aber was
genau das heisst, weiss ich nicht. Vielleicht gehen bloss keine
Templates, vielleicht geht keine Mehrfachvererbung, Exceptions
und automatische Destruktoren, ich weiss es nicht. Aus diesen und
weiteren Gründen wurde beschlossen, in C zu arbeiten.

Ein Compiler ist auch nicht hinreichend, man benötigt ja einen
passenden Linker, der das Compiler Objektformat versteht und
architektur-kompatible Binaries erzeugt. Dieses ist nicht einfach
ELF, sondern was spezielles mit besonderen Eigenschaften.
Damit scheidet der g++ sicherlich für eine Zielplattform aus,
ganz abgesehen davon, dass man vermutlich kaum Regressansprüche
oder Hardwaredebugging Support vom g++ "Hersteller" bekommt.

Details schreibe ich sicherheitshalber nicht; ich kann mir auch
nicht vorstellen, dass sie zweckdienlich sind. Offensichtlich
kennt niemand ein solches Tool, und es ist mir schon klar, dass
es sicherlich keine breiten Einsatzmöglichkeiten dafür gibt, da
man bei derartigen Anforderungen in der Regel OO Hochsprachen
einsetzt.

Danke für eure Zeit und Hinweise.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.




Mehr Informationen über die Mailingliste linux-l