Fehler bei meinen ersten C Schritten

Laut ANSI C Grammatik (http://www.lysator.liu.se/c/ANSI-C-grammar-y.html) ist foo in

Code: 
bar() {

 foo() { /* ... */ }

}

keine Funktion, es ist nicht definiert!

Code: 
%start translation_unit

/* .... */


translation_unit
	: external_declaration
	| translation_unit external_declaration
	;

external_declaration
	: function_definition
	| declaration
	;

function_definition
	: declaration_specifiers declarator declaration_list compound_statement
	| declaration_specifiers declarator compound_statement
	| declarator declaration_list compound_statement
	| declarator compound_statement
	;
 
  • Gefällt mir
Reaktionen: below
Nein, es ist unzulässig, das ändert aber nichts am Begriff der Funktion.

Eine Funktion sieht so aus:
function_definition
: declaration_specifiers declarator declaration_list compound_statement
| declaration_specifiers declarator compound_statement
| declarator declaration_list compound_statement
| declarator compound_statement
;

Und dies erfüllt bar(), auch wenn es in foo() steht. Damit ist es eine Funktion. Sie wird lediglich dort nicht erwartet, ist dort unzulässig.

Daher meldet das auch der Compiler.
 
Falsch! Das hier beschreibt eine Funktion - Zuzüglich der Definitionen der Declaratoren, die ich weggelassen hatte! Die stehen in meiner Quelle oben. Sonst ist es *keine* Funktion! Du könntest sie nicht herleiten!

Code: 
%start translation_unit

/* .... */


translation_unit
	: external_declaration
	| translation_unit external_declaration
	;

external_declaration
	: function_definition
	| declaration
	;

function_definition
	: declaration_specifiers declarator declaration_list compound_statement
	| declaration_specifiers declarator compound_statement
	| declarator declaration_list compound_statement
	| declarator compound_statement
	;

Auf Deutsch: Eine Funktion ist eine Funktion, wenn sie als externe Deklaration als direktes Kind der Übersetzungseinheit angegeben wird. Sie lässt sich durch die 4 Möglichkeiten repräsentieren!

Das was du beschreibst, sieht wie eine Funktion aus, lässt aber eine wichtige Eigenschaft missen, sie ist keine externe Deklaration einer Übersetzungseinheit! Period!
 
Ja, richtig, aber eben nicht alles! Lies bitte nochmal genau, was ich geschrieben hab. Eine Funktion hat in ANSI C mehr Eigenschaften als

ret name(ParType parName,...) { /* Body */ }

Dieser Block darf nirgends eingebettet sein! (Abgesehen von Präprozessoranweisungen, die aber mit dem Compiler nichts zutun haben). Und genau das sagt die Grammatik auch aus!

Und jetzt atme wieder aus, sonst platzt du noch ;)
 
_ebm_ schrieb:
Ja, richtig, aber eben nicht alles! Lies bitte nochmal genau, was ich geschrieben hab. Eine Funktion hat in ANSI C mehr Eigenschaften als

ret name(ParType parName,...) { /* Body */ }

Dieser Block darf nirgends eingebettet sein! (Abgesehen von Präprozessoranweisungen, die aber mit dem Compiler nichts zutun haben). Und genau das sagt die Grammatik auch aus!

Und jetzt atme wieder aus, sonst platzt du noch ;)
Zum Vergrößern anklicken....
Och, ich wollte bloß dein "period"-Argument an Schärfe toppen.

Ja, der Block darf nirgends eingebettet sein. Deshalb ist er ja auch unzulässig. Das ändert nichts daran, dass er die Bedingung einer Funktionsdefinition erfüllt und damit eine Funktion ist.

Ich darf mich auch nicht in der Damenumkleide aufhalten. Das ändert aber nichts daran, dass wenn ich mich in einer Damenumkleide aufhalte, ich immer noch ich bin.

Du verwechselst Sein und Zulässigkeit.

Eigentlich hätte es dir schon hier auffallen müssen:
Eine Funktion ist eine Funktion, wenn […]
Zum Vergrößern anklicken....
"A ist A, wenn …" ist für alles anderes als WAHR im "Wenn-Zweig" logischer Unsinn.
 
anegmawad schrieb:
"A ist A, wenn …" ist für alles anderes als WAHR im "Wenn-Zweig" logischer Unsinn.
Zum Vergrößern anklicken....

Das war von mir unsauber formuliert.. Da müsste stehen: Ein Konstrukt ist eine Funktion, wenn...

Für dich gehört also das "Nicht eingebettet sein dürfen" nicht zur Definition einer Funktion in ANSI C?

*hust* wir sind weit im OT. Wehe ein MOD liest das.

Nachtrag: Laut einer imaginären Grammatik, in der kein Mann in einer Damenumkleide definiert ist, gäbe es diesen Mann nicht ;)
 
Zuletzt bearbeitet:
Ich kann einen Mann definieren, ohne einen Kontext zu seinem Aufenthaltsort in Bezug zu nehmen.

Ich kann einen Damenumkleide definieren, ohne einen Kontext zu einer Person in Bezug zu nehmen.

Ich kann eine Regel festlegen, nach der sich kein Mann in einer Damenumkleide befinden darf.

Befindet sich dennoch darin einer, ist das ein Verstoß. Es definiert aber weder die Damenumkleide weg noch den Mann.

Sicherlich ist das ein Stück weit Geschmäckle. Aber die formale Definition der Funktionsdefinition setzt selbst nicht ihre Verortung voraus.
 
coacetan schrieb:
Letzter Offtopic Post :D

Sei nicht so streng below, wir wissen ja wie es bei ihm um das lesen steht :)
Zum Vergrößern anklicken....
Jepp, für einen Kurs zu programmieren, kann heißen im Rahmen eines Kurses zu programmieren, oder eben ein Kursprogramm zu erstellen.

Das ist eigentlich einfach zu erkennen. Deshalb hatte ich auch nachgefragt.

Deine mangelnde Eloquenz betrifft wohl nicht nur formale Sprachen …

Hier noch etwas zum Lernen:
Zum von mir verwendeten Fachbegriff "Nachfrage":
http://www.duden.de/suche/index.php?begriff=nachfrage&bereich=mixed&pneu=&x=0&y=0#inhalte

Und zum von mir verwendeten Fragezeichen:
http://www.duden.de/suche/index.php?begriff=Fragezeichen&bereich=mixed&pneu=&x=0&y=0#inhalte
 
(a) Ihr redet knapp aneinander vorbei:

Es gibt den Begriff der Funktion ( da hat anegmawad recht) und es gibt seine Umsetzung/Realisierung in ANSI-C ( da hat offenbar ebm recht - ich kann's nicht beurteilen). Ihr vergleicht also einen abstract Apfel mit einem implementierten Apfel der weitere Einschränkungen enthält ;)

(b) Ihr werdet schonwieder persönlich wenn Ihr sachlich nicht weiterkommt!

Vielleicht versucht ihr einfach mal sachlich zu bleiben ohne hier im schnoderrigen Ton den King rauszulassen? Diese Entwicklung mißfällt mir nämlich arg, sowas gab es bis vor einigen Monaten in den Programmiererforen hier noch nicht und ich gucks mir auch nicht mehr lange an!
 
1) Wegus, danke. So ganz stimmt das aber nicht ;)

Es geht um Funktionen in ANSI C. ANSI C ist eine Sprache. Sprachen werden durch Grammatiken beschrieben. Wenn in einer Grammatik keine Transition

funktion -> funktionskopf funktion funktionsende

definiert ist, ist eine Funktion in einer Funktion formal nie erzeugbar. Damit kann zwar in einer Funktion ein Konstrukt stehen, das wie eine Funktion aussieht, dieses ist aber als solches nicht verwertbar. Ein Kellerautomat würde nie in den Endzustand übergehen. Ein Parser würde über ein "unexpected token" monieren. Auch eine Grammatik ist eine formale Definition. Ich glaub eher, hier gibt es ein Problem mit Entität und Identität.

2) Es tut mir leid, sollte ich mich in meinem Ton vergriffen haben.
 
_ebm_ schrieb:
ANSI C ist eine Sprache. Sprachen werden durch Grammatiken beschrieben.
Zum Vergrößern anklicken....

glaub mir, ich ahb auch formale Sprachen und theo. Inf. genossen ich weiß das! :)

_ebm_ schrieb:
Es geht um Funktionen in ANSI C
Zum Vergrößern anklicken....

Dir ja! anegmawad sieht glaub ich eher generalisierten Begriff und genau deswegen kommt ihr nämlich auf keinen Nenner!
 
wegus schrieb:
glaub mir, ich ahb auch formale Sprachen und theo. Inf. genossen ich weiß das! :)
Zum Vergrößern anklicken....

Glaub ich dir, ich musste nur meine Argumentationskette aufbereiten ;)

wegus schrieb:
Dir ja! anegmawad sieht glaub ich eher generalisierten Begriff und genau deswegen kommt ihr nämlich auf keinen Nenner!
Zum Vergrößern anklicken....

Dann verweise ich nochmal deutlich auf Posting #21 ;) Ich rede die ganze Zeit, genau wie coacetan in Posting 4ff über Funktionen in ANSI C oder bei mir vielleicht noch allgemeiner in kontextsensitiven Sprachen. ;) Damit ist das Problem wohl beseitigt und ich kann meinen Hitzkopf wieder einstecken.

Gruss Carsten
 
Die Verwertbarkeit ist aber keine Voraussetzung der Definition. Das sieht auch nicht aus wie eine Funktion, sondern entspricht der Defintion einer Funktion. Ihre Verwertbarkeit ergibt sich nicht aus ihr selbst. Das ist auch für die Definition nicht erforderlich.

BTW: Du meinst kontextabhängig? Kontextsensitiv verwendet man IIRC nicht in diesem Kontext (Hihi).
 
Zuletzt bearbeitet:
wegus schrieb:
(b) Ihr werdet schonwieder persönlich wenn Ihr sachlich nicht weiterkommt!

Vielleicht versucht ihr einfach mal sachlich zu bleiben ohne hier im schnoderrigen Ton den King rauszulassen? Diese Entwicklung mißfällt mir nämlich arg, sowas gab es bis vor einigen Monaten in den Programmiererforen hier noch nicht und ich gucks mir auch nicht mehr lange an!
Zum Vergrößern anklicken....
Ich glaube nicht, dass meine Antworten an _ebm_ zur Beanstandung Anlass geben,
 
Ich muss mich korregieren. Die oben beschriebene Grammatik ist kontextfrei. Auf der linken Seite der Ableitungen steht nur ein Nichtterminal. Trotzdem hab ich damit ein Problem, dass eine Funktion alles ist, was so aussieht.
 
Zuletzt bearbeitet:
_ebm_ schrieb:
Und genau da liegt mein Problem. Konstrukte existieren abhängig von ihrer Umgebung - eben Kontextsensitiv! Darum sträub ich mich auch so dagegen, dass nur die Signatur einer Funktion mit Body die Funktion ausmacht. Für mich gehört der Kontext dazu.
Zum Vergrößern anklicken....
Ich habe deinen Punkt schon verstanden. Nur ist das Konstrukt gerade von dem Kontext isoliert beschreibbar. Daher zietierte ich ja auch stets den letzten Teil der Definition.

Anders: Ich kann ohne den Kontext zu kennen, sagen, ob ein $STÜCKTEXT eine C-Funktion (selbst) darstellt.

Damit kann ich einen Parser schreiben, der zu $STÜCKTEXT sagen kann, ob er es parsen kann (sogar vollständig verstehen) oder nicht, unabhängig davon, in welchem Kontext es sich befindet. Es dürfte auch völlig unproblematisch ein, nested Functions zuzulassen, was der gcc auf Option IIRC auch tut.

Übrigens meine ich, dass der Hinweis darauf, dass es eine Typ-1-Grammatik für C gibt, nicht darüber aussagt, ob eine bestimmte Regel kontextfrei ist. Eine Typ-2-Grammatik würde verlangen, dass sämtliche Regeln kontextfrei sind. Die Einordnung in Typ-1 sagt also lediglich aus, dass es mindestens eine Regel gibt, welches nicht kontextfrei ist. Ob damit eine gewählte Regel K kontextfrei ist, lässt sich damit nicht entscheiden. Da unterliegst du wohl einem unzulässigen Umkehrschluss.
+++
Habe den Anfang deines Beitrages noch einmal ohne Lesefehler zur Kenntnis genommen. Ja, das ist ja das, was ich im letzten Absatz meine: Bloß weil irgendwas in C kontextabhängig (ich bleibe dabei, angewöhnt ist angewöhnt) ist, sagt ja nichts über dieses Konstrukt aus.
 
Zuletzt bearbeitet:
Könnt ihr das nicht draussen regeln :kopfkratz:

Der TE kann dem mit Sicherheit nicht mehr folgen

Alex
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten