syntax errors in netzwerkheader files
Christian Uhrhan
-------BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hallo alle zusammen,
ich will mich einwenig in Socketprogrammierung einarbeiten. Nun habe ich aus dem Internet ein Beispielprogramm runtergeladen und versucht dieses zu compilieren. Allerdings bekomme ich einige Fehlermeldungen, die angeblich in den Headerfiles, die auf meinem System sind, sein sollen.
/usr/include/netinet/in.h:233: syntax error before 'in_addr_t'
Dies sind die Fehlermeldungen die ich bekomme (hab nur diese gepostet, aber es sind noch mehr in in6.h, ip.h, tcp.h und socket.h). Muss ich vielleicht noch irgendeine Library beim compilieren mit angeben?
Als System setze ich FreeBSD 4.5-RELAESE ein.
Danke schon mal im Voraus fuer Eure Hilfe
mfg
Christian U.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE8TJIyPSFx5p2QK9MRAq+zAJ9Rpju2ZmK0q+NLm5N0giPxfqlcagCdET56
FgKl7X8IIrDRHq5X7X1YVsw=
=rhoM
-----END PGP SIGNATURE-----
Patrick Schaaf
>ich will mich einwenig in Socketprogrammierung einarbeiten. Nun habe ich aus dem Internet ein Beispielprogramm runtergeladen und versucht dieses zu compilieren. Allerdings bekomme ich einige Fehlermeldungen, die angeblich in den Headerfiles, die auf meinem System sind, sein sollen.
>/usr/include/netinet/in.h:233: syntax error before 'in_addr_t'
>Dies sind die Fehlermeldungen die ich bekomme (hab nur diese gepostet, aber es sind noch mehr in in6.h, ip.h, tcp.h und socket.h). Muss ich vielleicht noch irgendeine Library beim compilieren mit angeben?
Nein, Du musst weitere #include-Files in der richtigen Reihenfolge angeben.
>Als System setze ich FreeBSD 4.5-RELAESE ein.
Ich kenne jetzt speziell FreeBSD nicht, nehme aber an, dass die manpages auch
da eine hohe Qualitaet haben. Schau' Dir die manpages zu den von Dir verwen-
deten Funktionen an. Jede davon sollte zu Beginn die genaue benoetigte Liste
von #includes praesentieren, die Du brauchst, um die Funktion sauber zu
verwenden.
Falls Du so nicht weiterkommst, streich' bitte Deinen Quelltext so zusammen,
dass es nur noch aus den #include's und dem gewuenschten Funktionsaufruf
besteht, und immer noch den "syntax error" zeigt. Dieses Extrakt postest
Du dann bitte hier, und man wird Dir konkret helfen koennen.
Gruss
Patrick
Peter Simons
Include-Statement einbinden, das diesen Fehler produziert. Es ist
generell eine gute Idee, zu _jeder_ (Socket-)Funktion, die Du in
Deinem Programm aufrufst, die entsprechende Man-Page aufzurufen und in
der SYNOPSIS-Sektion nachzusehen, welche System-Includes Du brauchst,
damit die Funktion samt der dazugehörigen Datentypen vollständig
deklariert ist.
Felix von Leitner
> /usr/include/netinet/in.h:233: syntax error before 'in_addr_t'
Wie du siehst, ist BSD scheiße.
Das ist ein typisches BSD-Problem, das auf deren minderwertige Müll-libc
zurückzuführen ist. Man kann nicht einfach irgendwelche Header
includen, man muß davor möglicherweise noch irgendwelche anderen Header
includen. Diese Schikanemaßnahmen dienen dem Zweck, Programmierer von
BSD fernzuhalten. Wie man sieht, funktioniert es prächtig. Kein
Schwein entwickelt Software für BSD, stattdessen müssen die BSDler den
ganzen Linux-Kram portieren.
> Als System setze ich FreeBSD 4.5-RELAESE ein.
Selbst schuld. BSD -> Tonne.
Rainer Weikusat
> Thus spake Christian Uhrhan (Christia...@gmx.de):
> > /usr/include/netinet/in.h:233: syntax error before 'in_addr_t'
>
> Wie du siehst, ist BSD scheiße.
> Das ist ein typisches BSD-Problem,
Nicht wirklich. Es ist 'ein tradtionelles C-Problem' (header files
shouldn't include other header file, => Pike).
Immo 'FaUl' Wehrenberg
> Nicht wirklich. Es ist 'ein tradtionelles C-Problem' (header files
> shouldn't include other header file, => Pike).
Dumme frage: Warum nicht?
FaUl
end
This article does not support incompatible and broken newsreader.
--
If you are using a Macintosh e-mail program that is not from Microsoft,
we recommend checking with that particular company. But most likely
other e-mail programs like Eudora are not designed to enable virus rep-
lication. - www.microsoft.com/mac/products/office/2001/virus_alert.asp
Rainer Weikusat
> begin followup to the posting of Rainer Weikusat:
> > Nicht wirklich. Es ist 'ein tradtionelles C-Problem' (header files
> > shouldn't include other header file, => Pike).
>
> Dumme frage: Warum nicht?
<URL:http://www.lysator.liu.se/c/pikestyle.html>
[unten]
Ich sehe das allerdings nicht so: Ein Compilerlauf ist ein 'typischer'
Batchjob und wenn der mir zu lange dauert, läuft er im Hintergrund und
mailt mir irgendwann eine Ausgabe. Zumal die Sache mit dem 'lexical
analyzer' schlicht falsch ist (für GCC). 'Multiple inclusions'
entsorgt cpp, meinetwegen auch 4x hintereinander. YMMV.
[mich hat das unter NetBSD auch schon zu Tode genervt...]
Immo 'FaUl' Wehrenberg
> Immo 'FaUl' Wehrenberg <im...@faul.dyndns.org> writes:
>> begin followup to the posting of Rainer Weikusat:
>> > Nicht wirklich. Es ist 'ein tradtionelles C-Problem' (header files
>> > shouldn't include other header file, => Pike).
>>
>> Dumme frage: Warum nicht?
>
> <URL:http://www.lysator.liu.se/c/pikestyle.html>
> [unten]
>
> Ich sehe das allerdings nicht so:
Ich auch nicht. Und wenn ich ein Prototyp
int function (FILE*, int);
habe, dann kann ich nicht erwarten, das der aufrufende stdio included hat.
Deswegen steht im Header
#include <stdio.h>
int function (FILE*, int);
Alles andere ist bloedsinn, IMO.
FaUl
end
This article does not support incompatible and broken newsreader.
--
>Wann ist denn dein Raumschiff auf der Erde angekommen ???
Wohl garnicht. Die muessen ihn beim Abbiegen hinterm Mond durchs
Klo gespuelt haben. Zu dumm, das er gerade hier aufschlagen musste.
[Juergen P. Meier in dcsf]
Immo 'FaUl' Wehrenberg
> Immo 'FaUl' Wehrenberg <im...@faul.dyndns.org> writes:
>> begin followup to the posting of Rainer Weikusat:
>> > Nicht wirklich. Es ist 'ein tradtionelles C-Problem' (header files
>> > shouldn't include other header file, => Pike).
>>
>> Dumme frage: Warum nicht?
>
> <URL:http://www.lysator.liu.se/c/pikestyle.html>
> [unten]
>
> Ich sehe das allerdings nicht so:
Ich auch nicht. Und wenn ich ein Prototyp
int function (FILE*, int);
habe, dann kann ich nicht erwarten, das der Aufrufende Stdio included hat.
Deswegen steht im Header
#include <stdio.h>
int function (FILE*, int);
Alles andere ist bloedsinn, IMO.
FaUl
end
This article does not support incompatible and broken newsreader.
--
Klaus von der Heyde
> Ich auch nicht. Und wenn ich ein Prototyp
>
> int function (FILE*, int);
> habe, dann kann ich nicht erwarten, das der Aufrufende Stdio included hat.
Muss man das? Ich habe in verschiedenen programmen schon beide
"philosophien" ausprobiert. Es funktioniert problemlos, wenn
man sich darauf einlaesst. Im zweifelsfall gibt es eine
fehlermeldung.
> Deswegen steht im Header
>
> #include <stdio.h>
> int function (FILE*, int);
>
> Alles andere ist bloedsinn, IMO.
Um dann mehrfachinklusionen auszuschliessen, kommt man zu den
#ifndef _MYHEADER_H_ ... #endif geschichten. Die braucht man beim
anderen verfahren nicht, und es muessen dann vom praeprozessor
auch keine .h-dateien geoeffnet werden, die dann per #ifndef
ueberlesen werden.
Dafuer muss man dann selbst sehen, dass man die .h-dateien in der
richtigen reihenfolge angibt.
Ueberdies, in deinem beispiel will der programmierer ja stdio.h
schon benutzen (er muss ja FILE* nutzen, um die funktion aufzurufen),
also kann man ihn das auch aktiv inkluden lassen.
Imvho kann es sogar sinnvoll sein, nichts "heimlich" einzubinden.
Da kenne ich auch einige probleme, die damit entstanden, insbesondere,
wenn .h-dateien irgend etwas redefinieren......
Klaus
--
Klaus von der Heyde -- he...@informatik.uni-bonn.de
Rainer Weikusat
> Muss man das? Ich habe in verschiedenen programmen schon beide
> "philosophien" ausprobiert. Es funktioniert problemlos, wenn
> man sich darauf einlaesst. Im zweifelsfall gibt es eine
> fehlermeldung.
Im Zweifelsfall bedeutet es 'x (mit x>5) min Suchen', weil jemand
anderer zu faul war. Vollredundant.
> Um dann mehrfachinklusionen auszuschliessen, kommt man zu den
> #ifndef _MYHEADER_H_ ... #endif geschichten. Die braucht man beim
> anderen verfahren nicht, und es muessen dann vom praeprozessor
> auch keine .h-dateien geoeffnet werden, die dann per #ifndef
> ueberlesen werden.
Ach, wirklich? Vorläufig ist meine Zeit immer noch wertvoller, als die
meines Computers.
> Imvho kann es sogar sinnvoll sein, nichts "heimlich" einzubinden.
> Da kenne ich auch einige probleme, die damit entstanden, insbesondere,
> wenn .h-dateien irgend etwas redefinieren......
Das dieselben Leute, die anderen diese Ratespielchen aufzwingen,
außerdem zu dämlich sind, um sowas zu verhindern, ist keine
Überraschung.
Merkregel für *BSD-gestörte: Take Un*x w/ a grain of salt, even if it
looks impressing.
... und der Rest ist 'plan 9'.
Klaus von der Heyde
[...]
>> anderen verfahren nicht, und es muessen dann vom praeprozessor
>> auch keine .h-dateien geoeffnet werden, die dann per #ifndef
>> ueberlesen werden.
>
> Ach, wirklich? Vorläufig ist meine Zeit immer noch wertvoller, als die
> meines Computers.
Kann schon sein, ich wollte auch nur mal die hintergruende
erwaehnen. Ich bin sicher, da kann man _lange_ drueber diskutieren,
genau wie ueber die verwendung von #... ueberhaupt, von #define,
goto, oder das setzen der "{" ;)
> Das dieselben Leute, die anderen diese Ratespielchen aufzwingen,
> außerdem zu dämlich sind, um sowas zu verhindern, ist keine
> Überraschung.
Die redefinitionen befanden sich in von .h-dateien eingebundenen
.h-dateien..........
[ueberhebliches entsorgt]
Dass C manchmal mehr freiheiten laesst, als man ahnt, ist
doch ein "bekanntes problem"(TM).
bye,
Andreas Pflug
Rainer Weikusat wrote:
> ...
> Ich sehe das allerdings nicht so: Ein Compilerlauf ist ein 'typischer'
> Batchjob und wenn der mir zu lange dauert, läuft er im Hintergrund und
> mailt mir irgendwann eine Ausgabe. Zumal die Sache mit dem 'lexical
> analyzer' schlicht falsch ist (für GCC). 'Multiple inclusions'
> entsorgt cpp, meinetwegen auch 4x hintereinander. YMMV.
selbst, wenn man davon absieht, finde ich das Zitat
".... the lexical analyzer, which is (in good compilers) the most
expensive phase. " schlicht merkwürdig. Daraus würde folgen, dass
der Compiler länger mit lexikalischer Analyse als mit den eigentlichen
Problemen der Datenflussanalyse, Codegenerierung und der Optimierung
beschäftigt wäre. Damit hätten wir dann eher sowas wie eine
Skriptsprache als einen "echten" Compiler ... ;-)
Viele Grüße
Andreas
Rainer Weikusat
> Rainer Weikusat wrote:
[ multiple inclusions/ Pike ]
[...]
> dass der Compiler länger mit lexikalischer Analyse als mit den
> eigentlichen Problemen der Datenflussanalyse, Codegenerierung und
> der Optimierung beschäftigt wäre.
Eine 'Grundannahmen' ist vermutlich, das der Compiler bei
'vernünftigem' Code nicht mehr allzu viel zum optimieren findet.
Patrick Schaaf
>> Deswegen steht im Header
>>
>> #include <stdio.h>
>> int function (FILE*, int);
>>
>> Alles andere ist bloedsinn, IMO.
>Um dann mehrfachinklusionen auszuschliessen, kommt man zu den
>#ifndef _MYHEADER_H_ ... #endif geschichten. Die braucht man beim
>anderen verfahren nicht, und es muessen dann vom praeprozessor
>auch keine .h-dateien geoeffnet werden, die dann per #ifndef
>ueberlesen werden.
Mit den ifdefs tut's in beiden Varianten. Ohne nicht. Das macht
die Sache fuer mich klar. Schreibe ich .h-Files, beginne ich immer
mit den doofen ifdefs. Und aergere mich noch nicht mal: es kommt
selten vor, dass man neue .h-Files schreibt.
>Ueberdies, in deinem beispiel will der programmierer ja stdio.h
>schon benutzen (er muss ja FILE* nutzen, um die funktion aufzurufen),
>also kann man ihn das auch aktiv inkluden lassen.
Die Annahme ist im allgemeinen FALSCH.
In einem Headerfile stehen in der Regel mehrere Deklarationen, die irgendwie
zusammen gehoeren. Nicht jeder Nutzer des Headerfiles verwendet alles, was
drin steht. Fuer einen #includer, der obigen Header included, und der nicht
vor hat, stdio zu verwenden, der ist jetzt gezwungen, zur Nutzung des
Headers nicht eine, sondern zwei #include-Statements zu schreiben.
Die Arbeit fuer den Praeprozessor ist in beiden Faellen die Gleiche
(und auf heutigen Systemen voellig irrelevant). Die Auswirkungen
auf der Quellebene sind aber verheerend: alle .c-Files fangen sich
mit der Zeit eine Latte an #includes von Standard-Headern ein, die
sie eigentlich garnicht interessieren. Verschwendung von vertikalem
Bildschirmplatz.
Gruss
Patrick
Felix von Leitner
> > Wie du siehst, ist BSD scheiße.
> > Das ist ein typisches BSD-Problem,
> Nicht wirklich. Es ist 'ein tradtionelles C-Problem' (header files
> shouldn't include other header file, => Pike).
Pike ist ein Idiot.
Laßt ihn in seinem Loch mit seinem Outlook verrosten.
Herbert Martin Dietze
> Felix von Leitner <usenet-...@fefe.de> writes:
>> Wie du siehst, ist BSD scheiße.
>> Das ist ein typisches BSD-Problem,
> Nicht wirklich. Es ist 'ein tradtionelles C-Problem' (header files
> shouldn't include other header file, => Pike).
Naja, man muss ja nicht alles glauben, was der Herr sagt :-)
Vor ein paar Jahren hat Jack Klein in clc da mal etwas nettes
zu geschrieben (google-anschmeiss):
Kurzes Zitat:
| 2. All headers must be totally independent. That is, myheader.h
| must compile without errors in a source file like this:
| [...]
Ich schliesse mich dem Standpunkt an. Es ist unsinnig, wegen
der Verwendung eines in einem dritten Header definierten
`typedef' in einem Prototyp einige zig Quellen editieren zu
muessen, um das entsprechende `#include' einzufuegen.
Gruss,
Herbert
--
If you cannot convince them, confuse them.
-- Harry S Truman
-=-=- -=-=-=-=-
Dipl.Ing. Martin "Herbert" Dietze -=-=- The University of Buckingham -=-=-
Andreas Pflug
> [...]
>
>> dass der Compiler länger mit lexikalischer Analyse als mit den
>> eigentlichen Problemen der Datenflussanalyse, Codegenerierung und
>> der Optimierung beschäftigt wäre.
>
> Eine 'Grundannahmen' ist vermutlich, das der Compiler bei
> 'vernünftigem' Code nicht mehr allzu viel zum optimieren findet.
ok, dann lies Dir mal den entsprechenden Vorgang für den gcc
(z.B. unter http://gcc.gnu.org/onlinedocs/gcc-3.0.3/gcc_17.html#SEC170 )
durch. Danach wüßte ich gerne, welchen Anteil der beschriebenen
Optimierungen man bereits durch "vernünftigen" C-Quellcode als
unnötig streichen kann.
IMHO ist die lexikalische Analyse im Compilerbau
(und auch in einigermaßen performanten Skriptsprachen) verglichen
mit den übrigen Anforderungen eher ein Trivialproblem.
Viele Grüße
Andreas
Rainer Weikusat
> > 'vernünftigem' Code nicht mehr allzu viel zum optimieren findet.
>
> ok, dann lies Dir mal den entsprechenden Vorgang für den gcc
> (z.B. unter http://gcc.gnu.org/onlinedocs/gcc-3.0.3/gcc_17.html#SEC170 )
> durch. Danach wüßte ich gerne, welchen Anteil der beschriebenen
> Optimierungen man bereits durch "vernünftigen" C-Quellcode als
> unnötig streichen kann.
Alle. Sonst hätte es Ende der siebziger auf den damaligen
Rechnern unter keinen mir erklärbaren Umständen auch nur ansatzweise
portable Kernel geben können. Genau weiß ich das nur für x86, aber da
kann man mit gcc wunderbar 'hübsch aussehenden' Assemblercode aus C
erzeugen lassen.
> IMHO ist die lexikalische Analyse im Compilerbau
> (und auch in einigermaßen performanten Skriptsprachen) verglichen
> mit den übrigen Anforderungen eher ein Trivialproblem.
Für K&R-C wäre ich da nicht so sicher (oder für Perl).
Klaus von der Heyde
> mit den doofen ifdefs. Und aergere mich noch nicht mal: es kommt
> selten vor, dass man neue .h-Files schreibt.
Bei mir nicht.
> Die Arbeit fuer den Praeprozessor ist in beiden Faellen die Gleiche
> (und auf heutigen Systemen voellig irrelevant). Die Auswirkungen
> auf der Quellebene sind aber verheerend: alle .c-Files fangen sich
> mit der Zeit eine Latte an #includes von Standard-Headern ein, die
> sie eigentlich garnicht interessieren. Verschwendung von vertikalem
> Bildschirmplatz.
Ist der bei dir knapp? :)
Immo 'FaUl' Wehrenberg
> Patrick Schaaf <mailer...@bof.de> wrote:
>> mit den doofen ifdefs. Und aergere mich noch nicht mal: es kommt
>> selten vor, dass man neue .h-Files schreibt.
> Bei mir nicht.
?
Hauptberuflich als Headerschreiber angestellt?
>> Die Arbeit fuer den Praeprozessor ist in beiden Faellen die Gleiche
>> (und auf heutigen Systemen voellig irrelevant). Die Auswirkungen
>> auf der Quellebene sind aber verheerend: alle .c-Files fangen sich
>> mit der Zeit eine Latte an #includes von Standard-Headern ein, die
>> sie eigentlich garnicht interessieren. Verschwendung von vertikalem
>> Bildschirmplatz.
> Ist der bei dir knapp? :)
Natuerlich, ist in der heutigen Zeit das einzige was knapp ist, nicht?
FaUl
end
This article does not support incompatible and broken newsreader.
--
Looking for : Female with E10k
[telnet blinkenlights.nl]
Klaus von der Heyde
Ich habe natuerlich keine ahnung und ihr alle habt ganz recht.
Klaus
Immo 'FaUl' Wehrenberg
>> Hauptberuflich als Headerschreiber angestellt?
> Ich habe natuerlich keine ahnung und ihr alle habt ganz recht.
Och guck mal, jetzt ist er beleidigt ;).
Aber mal ernsthaft, was hast du gegen die ifdefs? Ist kaum Arbeit und hat
keinen Nachteil. Warum sollte man keine Header in anderen Headern einbinden?
FaUl
end
This article does not support incompatible and broken newsreader.
--
[...]
checking for intelligent life... not found
[...]
[aus 'configure' von GIMP-1.2.2]
Klaus von der Heyde
>
> Aber mal ernsthaft, was hast du gegen die ifdefs? Ist kaum Arbeit und hat
> keinen Nachteil. Warum sollte man keine Header in anderen Headern einbinden?
Ich habe nichts dagegen. Man kann es so machen, und es gibt auch
gruende dafuer (die ich nicht erwaehnte...). Man _muss_ es aber
nicht. Gruende --> siehe Rob Pike's artikel.
Es gibt auch gruende gegen #bedingte compilierung im allgemeinen.
Man muss sich dem ja nicht anschliessen, aber wer's nicht will,
der macht es eben nicht.
Um zu den .h zurueckzukommen: ich koennte auch mit "nicht einbinden"
leben; bei manchen hier hat das ja wirklich schmerzensschreie
hervorgerufen.......
> This article does not support incompatible and broken newsreader.
?
Bernd Petrovitsch
>Nicht wirklich. Es ist 'ein tradtionelles C-Problem' (header files
>shouldn't include other header file, => Pike).
Naja, wenn man Arbeit von der Maschine auf den Programmierer
abschieben will ...
Bernd
--
Bernd Petrovitsch Email : be...@gams.at
g.a.m.s gmbh Fax : +43 1 205255-900
Prinz-Eugen-Straße 8 A-1040 Vienna/Austria/Europe
LUGA : http://www.luga.at
Christian Uhrhan
-------BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
also eigentlich wollte ich lediglich eine Antwort auf meine Frage.
Merkwuerdig, dass es immer leute gibt die sich anscheinend persoenlich
angegriffen fuehlen. Wenn du BSD scheiße findest, dann nutz es eben nicht.
mfg
Christian U.
PS: Danke an Patrick Schaaf und Peter Simons, wenigstens habt ihr
auf das Thema geantwortet. Wollte eigentlich keinen Glaubenskreig
ausloesen
Andreas Pflug
> Alle. Sonst hätte es Ende der siebziger auf den damaligen
> Rechnern unter keinen mir erklärbaren Umständen auch nur ansatzweise
> portable Kernel geben können. Genau weiß ich das nur für x86, aber da
> kann man mit gcc wunderbar 'hübsch aussehenden' Assemblercode aus C
> erzeugen lassen.
Klar konnten Compiler auch damals schon Assemblercode generieren,
darum ging es mir auch nicht. Btw. - Die erste gcc-Version scheint vom
22.03.1987 zu stammen.
Die Frage ist, wie man *heutige* Prozessoren sinnvoll ausreizen kann
("sinnvoll" steht hier für einen vernünftigen Kompromiss zwischen
Entwicklungszeit und Programmperformance).
>> IMHO ist die lexikalische Analyse im Compilerbau
>> (und auch in einigermaßen performanten Skriptsprachen) verglichen
>> mit den übrigen Anforderungen eher ein Trivialproblem.
>
> Für K&R-C wäre ich da nicht so sicher (oder für Perl).
demnach beschäftigt sich also ein mehrköpfiges Programmierteam
seit 1987 hauptsächlich mit lexikalischer Analyse von Perl-Syntax.
Das meinst Du nicht wirklich ernst... ;-)
Viele Grüße
Andreas
Rainer Weikusat
> Rainer Weikusat wrote:
[Why the human always wins]
> Klar konnten Compiler auch damals schon Assemblercode generieren,
Zusammenhang?
> Die Frage ist, wie man heutige Prozessoren sinnvoll ausreizen kann
Im Zusammenhang mit alten Aussagen über noch ältere C-Compiler
wohl kaum.
> ("sinnvoll" steht hier für einen vernünftigen Kompromiss zwischen
> Entwicklungszeit und Programmperformance).
Die Antwort ist einfach: Shellskripte schreibt man als solche.
Ich halte die Fragestellung für sinnlos: Es Programm löst ein
gegebenes Problem oder es tut das nicht.
What C-compilers might gain by offering 'tail recursion elimination' is
serverly beyond me, though. Why write them?
[Mir fehlen ein paar deutsche Wörter]
> > Für K&R-C wäre ich da nicht so sicher (oder für Perl).
>
> demnach beschäftigt sich also ein mehrköpfiges Programmierteam
> seit 1987 hauptsächlich mit lexikalischer Analyse von Perl-Syntax.
> Das meinst Du nicht wirklich ernst.
Stimmt. Du hast mir bloß nicht zugehört.
Also nochmal von vorne: Ein 'vernünftiger Compiler' (nach dem
angeführten Text) ist ein Ding, das sehr viel Zeit damit verbringt,
einen möglichst 'für Menschen lesbar formatierten Text' (also zB
*keine* Prototypen) in token zu zerlegen und hält sich ansonsten
weitestgehend bedeckt (siehe auch 'portabler Macroassembler'), dh es
versucht nicht, selbstätig meine Fehler zu korrigieren, denn
vielleicht waren es ja gar keine.
Ich sehe das nicht ganz so radikal (ich mag Hochsprachen ;-), aber es
bringt mir weniger, wenn der Optimizer 'bei der Datenflußanalyse'
seine eigenen Variablen durcheinander schmeißt und ich halbe Tage nach
unerklärlichen Fehlern suchen muß.
Beispiel:
---------------
$a = 2;
{
my $a = 1;
sub outer {
return sub { $a; }
}
}
$b = outer();
printf("%d\n", &$b());
---------------
Zur allgemeinen Überraschung gibt dieses Skript '0' aus.
-----------------
$a = 2;
{
my $a = 1;
printf("%s\n", \$a);
sub outer {
printf("%s\n", \$a);
return sub { $a; }
}
}
$b = outer();
printf("%d\n", &$b());
-----------------
... und das hier zwei identische Referenzen sowie '1'.
Den Nutzwert halte ich 'begrenzt' (außer, daß ich eine ähnliche
Konstruktion real für etwas anderes verwende).
Felix von Leitner
> serverly beyond me, though. Why write them?
man parser generator
Ich schreibe einfache Algorithmen übrigens gerne mal als Rekursion, auch
wenn die iterative Variante ein paar Prozent schneller wäre. Z.B. bei
den ternary search trees habe ich keinerlei Lust gehabt, eine iterative
Variante zu entwickeln.
Felix
Klaus von der Heyde
>
> Ich schreibe einfache Algorithmen übrigens gerne mal als Rekursion, auch
> wenn die iterative Variante ein paar Prozent schneller wäre.
Moegest du immer genug platz auf dem stack haben....
Scherz beiseite, wer wuerde das nicht machen, insbesondere wenn es
leichter nachzuvollziehen ist.
Koennte man nicht die ueberfuehrung von rekursiv nach iterativ
maschinell (also z.b. vom compiler) durchfuehren lassen, wenn man
geschwindigkeits-/platzvorteile davon zu erwarten hat?
Matthias Bethke
>> Ich schreibe einfache Algorithmen übrigens gerne mal als Rekursion,
>> auch wenn die iterative Variante ein paar Prozent schneller wäre.
> Moegest du immer genug platz auf dem stack haben....
Genau deswegen macht man ja tail recursion elimination. D.h.
void recurse(int i) {
if(i < LIMIT) recurse(i-1);
}
knallt dir bei entsprechendem Optimizer nicht den Stack voll, egal wie
hoch LIMIT ist.
> Koennte man nicht die ueberfuehrung von rekursiv nach iterativ
> maschinell (also z.b. vom compiler) durchfuehren lassen, wenn man
> geschwindigkeits-/platzvorteile davon zu erwarten hat?
Klar. Das ist es, was LISP & Co. schon immer machen (auf einer Maschine
mit ein paar KB Kernspeicher kann man sich große Stacks eh nicht
leisten), und die Optimizer einiger anderer Sprachen mittlerweile auch.
> Klaus
--
regards
Matthias
--
PGP used here!
2048/0x90CF8389 / 8E 1F 10 81 A4 66 29 46 B9 8A B9 E2 09 9F 3B 91
Rainer Weikusat
> Genau deswegen macht man ja tail recursion elimination.
Genau deswegen verzichtet man auf 'tail recursions'. Das Verfahren zum
Eliminieren ist primitiv genug, es von Hand anzuwenden, falls man auf
den großartigen Gedanken kommen sollte.
Patrick Schaaf
>Felix von Leitner <usenet-...@fefe.de> wrote:
>>
>> Ich schreibe einfache Algorithmen übrigens gerne mal als Rekursion, auch
>> wenn die iterative Variante ein paar Prozent schneller wäre.
>Moegest du immer genug platz auf dem stack haben....
Es gibt Gegenden, wo man das bedenken muss, zB. in OS-Kernen.
>Koennte man nicht die ueberfuehrung von rekursiv nach iterativ
>maschinell (also z.b. vom compiler) durchfuehren lassen, wenn man
>geschwindigkeits-/platzvorteile davon zu erwarten hat?
Ja. Das nennt man dann 'tail recursion elimination'.
Hach, driftet der Thread so schoen...
Gruss
Patrick
Andreas Pflug
Rainer Weikusat wrote:
> Also nochmal von vorne: Ein 'vernünftiger Compiler' (nach dem
> angeführten Text) ist ein Ding, das sehr viel Zeit damit verbringt,
> einen möglichst 'für Menschen lesbar formatierten Text' (also zB
> *keine* Prototypen) in token zu zerlegen und hält sich ansonsten
> weitestgehend bedeckt (siehe auch 'portabler Macroassembler'), dh es
> versucht nicht, selbstätig meine Fehler zu korrigieren, denn
> vielleicht waren es ja gar keine.
ok, die Optimierungen sollten nicht dazu führen, dass sich am
Resultat des Programmes irgendwas ändert. Einen heutigen
Prozessor gut auszulasten bedeutet aber etwas anderes als
zu den Zeiten, als ein Prozessor ein Daten- und ein Adressregister besaß.
Von einem heutigen Compiler erwarte ich eine geschickte
Registerausnutzung, sowie z.B. eine für den Prozessorcache
günstige Anordnung der Daten im Speicher usw. - alles Dinge, die
man z.B. im C-Quelltext nicht direkt manipulieren kann.
[ Perl-Beispiel, dessen Laufzeitverhalten
durch simples printf von Referenzen
signifikant beeinflußt wird ]
Das ist in der Tat merkwürdig, offenbar schafft es perl (bei mir Version
5.6.0) nicht, nach Verlust der lokalen Variable $a die Bindung in der
Unterroutine an die globale Variable $a korrekt wiederherzustellen.
Allerdings ist das wiederum ein typisches Beispiel dafür, dass die
eigentlichen Probleme beim Compiler-
bzw. Skriptsprachenbau erst *nach* der lexikalischen Analyse
anfangen...
Viele Grüße
Andreas
Matthias Bethke
> Genau deswegen verzichtet man auf 'tail recursions'. Das Verfahren zum
> Eliminieren ist primitiv genug, es von Hand anzuwenden, falls man auf
> den großartigen Gedanken kommen sollte.
Wenn ich primitive Dinge von Hand erledigen will, nehme ich einen
Assembler. Das habe ich lange genug gemacht, und dachte auch noch,
darauf stolz sein zu müssen. Jetzt kümmere ich mich lieber um Dinge, die
Compiler nicht können.
Rainer Weikusat
> Rainer Weikusat wrote:
> > Genau deswegen verzichtet man auf 'tail recursions'. Das Verfahren zum
> > Eliminieren ist primitiv genug, es von Hand anzuwenden, falls man auf
> > den großartigen Gedanken kommen sollte.
>
> Wenn ich primitive Dinge von Hand erledigen will, nehme ich einen
> Assembler.
Es geht aber nicht 'um primitive Dinge'.
> Das habe ich lange genug gemacht, und dachte auch noch,
> darauf stolz sein zu müssen.
Du bist das immer noch.
> Jetzt kümmere ich mich lieber um Dinge, die
> Compiler nicht können.
Compiler können nicht denken.
F'up2 poster
Rainer Weikusat
> ok, die Optimierungen sollten nicht dazu führen, dass sich am
> Resultat des Programmes irgendwas ändert. Einen heutigen
> Prozessor gut auszulasten bedeutet aber etwas anderes als
> zu den Zeiten, als ein Prozessor ein Daten- und ein Adressregister
> besaß.
Das ist zunächst mal eine Annahme.
> Von einem heutigen Compiler erwarte ich eine geschickte
> Registerausnutzung,
Was soll das sein?
> sowie z.B. eine für den Prozessorcache günstige Anordnung der Daten
> im Speicher usw. - alles Dinge, die man z.B. im C-Quelltext nicht
> direkt manipulieren kann.
Wozu? Das ist low-level-Quatsch, der praktisch keine Rolle spielt. IdR
verarbeiten Programme etwas und so ziemlich alles ist langsamer als
die CPU. Welche übrigens? Es soll da mehrere geben.
> [ Perl-Beispiel, dessen Laufzeitverhalten
> durch simples printf von Referenzen
> signifikant beeinflußt wird ]
Es wird durch die Dereferenzierung beeinflußt. Jeglicher (AFAIK)
Zugriff genügt.
> Das ist in der Tat merkwürdig, offenbar schafft es perl (bei mir Version
> 5.6.0) nicht, nach Verlust der lokalen Variable $a die Bindung in der
> Unterroutine an die globale Variable $a korrekt wiederherzustellen.
Was soll das für ein Unsinn sein? Hier geht nichts 'verloren' und das
globale $a ist innerhalb des Blocks unter keinen Umständen
sichtbar. Sollte es auch nicht. Der Compiler macht Müll (und zwar
ziemlich gründlich -- falls Deparse ein Inhaltspunkt ist [was ich
bezweifle], korreliert das Ergebnis der Übersetzung auf keine
nachvollziehbare Weise mit den tatsächlich stattfindenden
Ereignissen.
> Allerdings ist das wiederum ein typisches Beispiel dafür, dass die
> eigentlichen Probleme beim Compiler- bzw. Skriptsprachenbau erst
> nach der lexikalischen Analyse anfangen...
Ist das Dein Lieblingsausspruch, oder warum wiederholst Du den
ständig?
F'up2 poster