www.mikrocontroller.net

Forum: Compiler & IDEs includefile "vererben"


Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marius Wensing (mw1987)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marius Wensing (mw1987)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

also ich würde das so machen, dass du einfach folgendes in deine 
Header-Datei reinschreibst:
#include<stdio.h>
Dann hast du automatisch alle Deklarationen aus stdio.h übernommen und 
kannst da dann deine eigenen Erweiterungen unterbringen.

MfG
Marius

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: kosmonaut pirx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
dann hast du einen fehler eingebaut. zeig mal dein beispiel bitte.
bye kosmo

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: kosmonaut pirx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das includefile heisst stdio.h

Autor: kosmonaut pirx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
dann nenn es einfach um. an dieser stelle ist falscher stolz vollkommen 
unangebracht.
bye kosmo

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
_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>

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 ...

Autor: kosmonaut pirx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>>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...

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Du könntest das ja dynamisch beim Compilieren ermitteln lassen.

Es gibt ein define, das den Pfad zur avr-libc enthält ??

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In diesem Fall ist es ja aber eine Bibliothek und keine Anwendung.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.