Hallo, ist es möglich ein includefile quasi zu vererben ? Ich möchte der stdio.h der avr-libc eine funktion hinfügen, und dazu quasi ein kapselndes includefile erstellen das dann die original stdio.h einbindet nur seh ich da im moment keine Möglichkeit
Mach doch einfach ein #include<stdio.h> in deine Header-Datei... Dann hat deine Headerdatei die Daten von stdio.h und deine eigenen noch dazu... MfG Marius
Hallo, also ich würde das so machen, dass du einfach folgendes in deine Header-Datei reinschreibst:
1 | #include<stdio.h> |
Dann hast du automatisch alle Deklarationen aus stdio.h übernommen und kannst da dann deine eigenen Erweiterungen unterbringen. MfG Marius
wie ich vermutet habe, funktioniert genau das leider nicht da das includefile damit auf sich selbst verweist. Ich konnts nur nicht beweisen bevor ichs probiert hab. Hat noch jemand eine andere Idee ?
hallo, dann hast du einen fehler eingebaut. zeig mal dein beispiel bitte. bye kosmo
Was genau willst du denn damit anstellen? Übrigens, #include "foo.h" wird zuert im aktuellen Verzeichnis gesucht, #include <foo.h> dagegen nur in den Systemverzeichnissen. Ich fände es aber hochgradig verwirrend, in einem Projekt ein lokales "stdio.h" vorzufinden, das sich anders benimmt als das System-<stdio.h>. Was genau willst du eigentlich hinzufügen?
Nein, ich möchte nicht das man sie mit "stdio.h" einbinden muss. Ich möchte fopen hinzufügen. @kosmonaut, was soll ich da bitte falsch gemacht haben ? Es ist doch absoulut logisch das der compiler die stdio.h von mir einbindet. In dem includefile steht drin #ifndef _MY_STDIO_H #define _MY_STDIO_H #include <stdio.h> FILE* fopen(const char *filename, const char *mode); #endif
hallo, >>funktioniert genau das leider nicht da das >>includefile damit auf sich selbst verweist >#ifndef _MY_STDIO_H > #define _MY_STDIO_H >#include <stdio.h> >FILE* fopen(const char *filename, const char *mode); >#endif und wo verweist das include auf sicht selbst? bye kosmo
hallo, dann nenn es einfach um. an dieser stelle ist falscher stolz vollkommen unangebracht. bye kosmo
_MY_STDIO_H steht dir übrigens nicht zu, das ist ein reservierter Name. Benenne deine eigenen Symbole besser ohne führenden Unterstrich. Eine (hässliche) Variante wäre es übrigens noch, dass du im #include in deiner Headerdatei einen absoluten Pfad angibst. Für mein System wäre das dann #include </usr/local/avr/include/stdio.h>
@kosmonaut das hat doch nichts mit falschem stolz zu tun, entschuldige aber du versucht hier tips zu geben die ich einfach nicht gebrauchen kann. Du kennst den hintergrund überhaupt nicht und 3 posts lang hast du noch nichtmal meine beiträge gelesen. es stand nämlich schon im ersten das das ding stdio.h heisst. weiterhin versuch ich eine unix compatible kapselung um FreeRTOS und die avr-libc zu basteln mit nem Treiber und Dateisystemlayer ich kann die stdio.h also nicht einfach umbenennen da es dann nicht mehr libc konform wäre. @jörg setzt aber vorraus das ich wissen muss wo die avr-libc installiert ist was bei mir allein schon 2 verschiedene locations sind (linux,windows) und real ist das bei mir _SDOS_STDIO_H das define gibt es garantiert nirgends ich habs jetzt erstmal in ein anderes includefile mit hineingetan was eh immer eingebunden werden muss zufrieden bin ich mit der lösung nicht aber ...
hallo, >das hat doch nichts mit falschem stolz zu tun, entschuldige aber du >versucht hier tips zu geben die ich einfach nicht gebrauchen kann. ok, lass ich's halt. ist wohl vergeudete zeit. >Du >kennst den hintergrund überhaupt nicht und 3 posts lang hast du noch >nichtmal meine beiträge gelesen. es stand nämlich schon im ersten das >das ding stdio.h heisst. nun bleib bitte auf dem teppich. ich zitiere dich gerne: >>Hallo, >>ist es möglich ein includefile quasi zu vererben ? >>Ich möchte der stdio.h der avr-libc eine funktion hinfügen, und dazu >>quasi ein kapselndes includefile erstellen das dann die original stdio.h >>einbindet nur seh ich da im moment keine Möglichkeit wo, bitte schön, steht hier, dass deine datei stdio.h heißt? aber hilf mir doch mal auf die sprünge. >weiterhin versuch ich eine unix compatible kapselung um FreeRTOS und die >avr-libc zu basteln mit nem Treiber und Dateisystemlayer ich kann die >stdio.h also nicht einfach umbenennen da es dann nicht mehr libc konform >wäre. wenn deine anforderungen so sind, dass deine datei so heissen muss, solltest du dann vielleicht auch in deinem post schreiben. häppchenweise informationen zu erfahren macht wirklich keinen spaß. und sich dann noch etwas anhören lassen zu müssen, nein danke. dennoch viel erfolg, bye kosmo
>>>Hallo, >>>ist es möglich ein includefile quasi zu vererben ? >>>Ich möchte der stdio.h der avr-libc eine funktion hinfügen, und dazu >>>quasi ein kapselndes includefile erstellen das dann die original stdio.h >>>einbindet nur seh ich da im moment keine Möglichkeit >wo, bitte schön, steht hier, dass deine datei stdio.h heißt? aber hilf >mir doch mal auf die sprünge. Entschuldige, ich dachte das kann man aus dem "vererben" und "zu stdio.h hinzufügen" ersehen. Ich war eigentlich der Meinung alle nötigen Informationen angegeben zu haben. Wenn dem nicht so ist bitte ich das zu entschuldigen, trotzallem hören sich Aussagen wie: >hallo, >dann nenn es einfach um. an dieser stelle ist falscher stolz vollkommen >unangebracht. >bye kosmo nicht gerade nach "Ich hab zuwenig Information" an...
> trotzallem hören sich Aussagen wie: > >>hallo, >>dann nenn es einfach um. an dieser stelle ist falscher stolz vollkommen >>unangebracht. >>bye kosmo > > nicht gerade nach "Ich hab zuwenig Information" an... Das kam aber erst, nachdem du explizit erwähnt hast, daß dein Header stdio.h heißt. > Du kennst den hintergrund überhaupt nicht Den kennt hier keiner, wenn du ihn uns nicht mitteilst. Die einfachste Lösung ist eben, der Headerdatei einen anderen Namen zu geben. Daß du einen Grund hast, genau das nicht zu tun, kann ja hier keiner auf magische Weise aus deinem Kopf lesen. Hättest du das gleich erwähnt, wäre die ganze Diskussion deutlich kürzer gewesen. > setzt aber vorraus das ich wissen muss wo die avr-libc installiert ist > was bei mir allein schon 2 verschiedene locations sind (linux,windows) Du könntest das ja dynamisch beim Compilieren ermitteln lassen.
>Du könntest das ja dynamisch beim Compilieren ermitteln lassen.
Es gibt ein define, das den Pfad zur avr-libc enthält ??
Christian Ulrich wrote: > setzt aber vorraus das ich wissen muss wo die avr-libc installiert ist Ja. Du kannst halt nicht alles auf einmal haben, es geht schlicht nicht. > was bei mir allein schon 2 verschiedene locations sind (linux,windows) > und real ist das bei mir _SDOS_STDIO_H das define gibt es garantiert > nirgends Das ist egal, ob es das schon irgendwo gibt oder nicht. Diese Garantie kannst du nicht erteilen. Ein Präprozessormakro, dessen Name mit einem Unterstrich, gefolgt von einem weiteren Unterstrich oder einem Großbuchstaben beginnt, ist per Standard ``reserved for the implementation'', d. h. es steht nur der Systembibliothek oder dem Compiler zu (diese müssen sich gegenseitig irgendwie absprechen), ein solches Symbol zu definieren/benutzen.
Christian Ulrich wrote:
> In diesem Fall ist es ja aber eine Bibliothek und keine Anwendung.
Ja, und? Warum kann man diese nicht mit einem Editor ändern? Kannst
dir ja den Patch mittels diff -u aufheben, damit du ihn beim nächsten
Update einfach wieder einspielen kannst.
Wie geschrieben, du kannst nicht alles haben: sowohl zweimal den
gleichen Namen als auch keine üblen Hacks à la absoluter Pfadname
als auch die Rückführung auf die avr-libc-Dateien ohne duplizieren
von deren Inhalt.
Falls sich deine Bemerkungen auf die Bezeichner mit Unterstrich
bezog: ist egal. Bibliotheken haben keine Sonderrechte, mit Ausnahme
der Systembibliothek (die der Standard gemeinsam mit dem eigentlichen
Compiler als ``the implementation'' bezeichnet).
Es ist doch in diesem falle die Systembibliothek, ich stelle dort libc und unix funktionalität zur verfügung oder wo definierst du gehören fcntl.h, conio.h,unistd.h und ioctl.h funktionalitäten dazu ? ich muss doch nur zusehn das meine Symbole in der avr-libc nicht vorkommen. Und ist die avr-libc nicht mit dem Editor editierbar ? Das Argument versteh ich jetzt nicht.
Christian Ulrich wrote: > Es ist doch in diesem falle die Systembibliothek, ich stelle dort libc > und unix funktionalität zur verfügung oder wo definierst du gehören > fcntl.h, conio.h,unistd.h und ioctl.h funktionalitäten dazu ? conio.h? MS-DOS. ;-) > ich muss doch nur zusehn das meine Symbole in der avr-libc nicht > vorkommen. ...und nicht vom Compiler benutzt werden. Das solltest du mit den ,,Herstellern'' von Compiler und Bibliothek absprechen, ansonsten kann es dir schnell mal passieren, dass Dinge, die heute noch funktionieren, morgen nicht mehr gehen. Die Diskussion in einem Webforum würde ich nicht als Absprache bezeichnen... (zumal das ja eher zufällig mit hochkam dabei). Aber du bist eben nicht die Systembibliothek, sonst hättest du auch diesen Kuddelmuddel nicht. Um das sinnvoll machen zu können, müsstest du das gesamte stdio von avr-libc links liegen lassen und komplett durch dein eigenes ersetzen. Es hat doch sowieso keinen Sinn, zwei grundverschiedene stdio-Systeme mischen zu wollen, das funktioniert doch in der gesamten Bibliothek nicht. Wenn du deine eigene stdio-Implementierung hast, musst du halt dann (mittels -I- Optionen) sicherstellen, dass die Nutzer sich die dazu passende <stdio.h> includieren und natürlich auch, dass sie sich mit -l die dazu gehörige Bibliothek auch linken.
>conio.h? MS-DOS. ;-)
hab noch gar nicht nachgeschaut gehabt, stimmt es gibt im unix ja gar
keine Möglichkeit durch einen einfachen Funktionsaufruf den screen zu
löschen o.ä. naja ioctl ist ja Erfahrungen und \33 auch :p.
momentan werd ich die avr-libc erstmal drin lassen vielleicht werden
freertos und avr-libc irgendwann mal durch eigene Routinen ersetzt
aktuell will ich erstmal ein möglichst einfaches und schlankes layer
schaffen das es einem ermöglicht ab atmega16 unix like zu programmieren.
Ich bin mir der gefahren mit den symbolen durchaus bewusst jedoch ist
die Wahrscheinlichkeit das es da Probleme gibt doch äußerst gering.
Naja, du kannst doch den Rest der avr-libc drin lassen, aber was brauchst du denn bei einer eigenen stdio-Implementierung wirklich noch aus avr-libc's stdio.h? Das würde doch schlimmstenfalls sogar zum Crash führen.
print
getc
putc
usw
ich übernehme ja quasi alles was aus der stdio.h kommt füge nur fopen
hinzu so das man z.b.
fopen("/dev/tty0") benutzen kann.
eigentlich auch überflüssig da man eh über open,read,write,ioctl,close
zugreifen sollte zum beispiel beim i2c treiber ist das wichtig da bei
fopen nur getc und putc definiert werden und die avr-libc den rest macht
wenn mann jetzt aber 2 byte vom i2c lesen oder schreiben will geht das
natürlich nicht da die avr-libc das ganze in 2 zugriffe mittels getc
teilt und der treiber dann nicht mehr weiss wann er ne start und stop
condition zu senden hat.
vorerst ist aber die implementierung über die libc denk ich günstioger
als alles wegzulassen und die ganzen print routinen werd ich wohl so
schnell nicht implementieren.
Christian Ulrich wrote: > *print* > getc > putc > usw > > ich übernehme ja quasi alles was aus der stdio.h kommt füge nur fopen > hinzu so das man z.b. > > fopen("/dev/tty0") benutzen kann. Das kann doch aber nicht funktionieren. Dein fopen() müsste ja dann ein FILE * bereitstellen, mit dem die avr-libc-Funktionen wieder was anfangen können. Das bedeutet aber, dass du komplett mit den Interna der avr-libc arbeiten musst. Da du auf diese Weise versionsabhängig von der konkreten Implementierung der avr-libc bist, kannst du die entsprechenden Deklarationen auch gleich bei dir dupliziert mit aufnehmen. > eigentlich auch überflüssig da man eh über open,read,write,ioctl,close > zugreifen sollte Dafür brauchst du aber kein fopen() sondern nur open(). Das hat dann auch nichts mehr mit stdio zu tun.
>Das kann doch aber nicht funktionieren. Dein fopen() müsste ja dann >ein FILE * bereitstellen, mit dem die avr-libc-Funktionen wieder >was anfangen können. Das bedeutet aber, dass du komplett mit den >Interna der avr-libc arbeiten musst. deswegen benutze ich fdevopen um die FILE Struktur zu befüllen. >Dafür brauchst du aber kein fopen() sondern nur open(). Das hat dann >auch nichts mehr mit stdio zu tun. richtig, man kommt auch komplett ohne fopen,fread,fwrite ... aus aber ich hätte sie gern mit drin aus kompatibilitätsgründen. genauso will ich fork und co aus der unistd implementieren aus kompatibilitätsgründen aber auch die wichtigsten funktionen aus der pthread lib bereitstellen.
> deswegen benutze ich fdevopen um die FILE Struktur zu befüllen.
Hmm. Dann bau lieber eine Erweiterung für die avr-libc, die offiziell
ins stdio mit rein kann, und die fopen() implementiert. Diskutier
die Details auf der avr-libc-dev-Mailingliste. fopen() sollte dann
implizieren, dass sein erstes Argument über open() auflösbar ist,
und bewirkt in der Folge, dass backend-Funktionen benutzt werden, die
ihrerseits read() und write() nutzen. Die avr-libc muss dabei nicht
notwendigerweise selbst Implementierungen für open()/read()/write()
enthalten, sondern kann dies der Applikation überlassen. (Ggf. hat
die avr-libc Dummies dafür. Wenn deren open() für jedes Argument
ein -1 liefert, werden die anderen Funktionen ja nie angesprochen.)
Du wirst nicht um eine Integration herum kommen auf Dauer, da das
fclose() dahingehend erweitert werden müsste, dass es noch close()
ruft.
Auch wirst du perspektivisch eine Pufferung als Option haben wollen
(kann ja beim normalen fdevopen() ausgeschaltet bleiben), damit du
auch disk blocks bearbeiten kannst, d. h. read() und write() können
nur auf (Vielfachen von) 512-Byte-Blöcken arbeiten.
Wenn das alles ordentlich gemacht ist, könnte ich mir das sehr gut
als Erweiterung der avr-libc vorstellen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.