mikrocontroller.net

Forum: PC-Programmierung eine allgemeine Header für alle Prototypen


Autor: Cimbom Gs (cimbomgs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

arbeite gerade an einem riesen Projekt, wo ich viele Funktionen habe.
Ich programmiere in C und wie man weiß, braucht man für jede Funktion 
einen Prototyp.

Aber zu jeder Funktion gehört auch eine Quell-Code-Datei (*.c) und ein 
Header-Datei (*.h)..

Wie jeder Vernünftige es machen würde, beginnt auch bei mir jede 
Header-Datei mit:
#ifndef _BSP_H
#define _BSP_H

...

#endif

so jetzt zu meiner eigentlichen Frage :-)
ich wollte eine "Allgemeine Header-Datei" erstellen, in dem alle 
Header-Dateien inludiert werden, die erzeugt wurden.

Somit bräuchte ich nicht immer alle Headers includieren, ich müsste nur 
die "Allgemeine Header-Datei" einmal unclidieren.

ungefähr so...

...anstatt:
//Datei test.c
#include "a.h"
#include "b.h"
#include "c.h"
#include "d.h"
#include "e.h"
#include "f.h"
...
void main(void)
{
...
}



...will ich:
//Datei allgemein.h
#ifndef _ALLGEMEIN_H
#define _ALLGEMEIN_H

#include "a.h"
#include "b.h"
#include "c.h"
#include "d.h"
#include "e.h"
#include "f.h"
...


//Datei test.c
#include "allgemein.h"

void main(void)
{
...
}


Gibt's da irgendwelche bedenken?
Kann es zu Problemen kommen?

Vielen Dank

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, wenn es zwischen den Einzelheaders keine Konflikte (bspw. durch
mehrfach definierte Makros) gibt.

Die Kompilierzeiten werden (je nach Größer der Headers) etwas länger
sein, weil der Compiler auch unbenutzte Headers unnötigerweise
durchnudelt.

Autor: Cimbom Gs (cimbomgs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
yalu wrote:
> Nein, wenn es zwischen den Einzelheaders keine Konflikte (bspw. durch
> mehrfach definierte Makros) gibt.

durch
#ifndef abc
#define abc
ist doch sichergestellt, dass es zu keinem Konflikt kommt

> Die Kompilierzeiten werden (je nach Größer der Headers) etwas länger
> sein, weil der Compiler auch unbenutzte Headers unnötigerweise
> durchnudelt.

ja gut das passiert ja nur einmal beim Beginn, es muss ja nur einmal 
kompiliert werden..

Hat es irgendwelche Auswirkungen auf den Speicher?

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> durch
> #ifndef abc
> #define abc
> ist doch sichergestellt, dass es zu keinem Konflikt kommt

Ja, wenn alles richtig untereinander koordiniert ist, gibt es keine
Probleme. Ich meinte auch eher so etwas von der Sorte:

temperatursensor.h:
#define UMRECHNUNGSFAKTOR 13

drucksensor.h
#define UMRECHNUNGSFAKTOR 472

Normalerweise wird temperatursensor.h nur in temperatursensor.c und
drucksensor.h nur in drucksensor.c includet. Wenn du beide gemeinsam
includest, gibt es einen Konflikt. Ein zusätzliches #ifdef löst zwar
den Konflikt auf, dafür wird dann aber für beide Sensoren der gleiche
Umrechnungsfaktor benutzt. Da helfen nur unterschiedliche Namen, was
sowieso der bessere Stil ist, also bspw. TEMP_UMRECHNUNGSFAKTOR und
DRUCK_UMRECHNUNGSFAKTOR.

> Hat es irgendwelche Auswirkungen auf den Speicher?

Nicht dann, wenn du dich an die Gutestilregel hältst, dass in
Headerfiles nur Deklarationen aber keine Definitionen von Variablen
oder Funktionen stehen. Reine Deklarationen belegen keinen Speicher,
da kannst du soviel unnötiges Zeugs includen wie du lustig bist.

Autor: Cimbom Gs (cimbomgs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
yalu wrote:
> Ich meinte auch eher so etwas von der Sorte:
> temperatursensor.h:
> #define UMRECHNUNGSFAKTOR 13
> drucksensor.h
> #define UMRECHNUNGSFAKTOR 472
> Ein zusätzliches #ifdef löst zwar den Konflikt auf

überall wo ein #define steht, wird bei mir vorher ein #ifndef realisiert
#ifndef UMRECHNUNGSFAKTOR
#define UMRECHNUNGSFAKTOR 13
#endif

>TEMP_UMRECHNUNGSFAKTOR und
> DRUCK_UMRECHNUNGSFAKTOR.

ganz genau so wird's auch gemacht. Keine gleiche Bezeichnungen für 
Konstanten :-)


@yalu
Danke für deine Hilfe ;-)

Autor: Cimbom Gs (cimbomgs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmmm.. wieso ist die Reihenfolge der Includes so wichtig?

naja ich hatte die Reihenfolge der Includes nicht beachtet gehabt und 
habe gesehen, dass mein Programm nicht gelaufen ist.
Jetzt wo die Reihenfolge stimmt, funktioniert das Programme und bekomme 
keine Fehlermeldungen

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cimbom Gs wrote:
> überall wo ein #define steht, wird bei mir vorher ein #ifndef realisiert
> #ifndef UMRECHNUNGSFAKTOR
> #define UMRECHNUNGSFAKTOR 13
> #endif

Das ist auch mist. Wenn eine doppelte Definition auftritt (siehe Post 
von yalu) Dann merkst du dies nicht. Problematisch ist aber, wenn du in 
Tempsensor.c alle h-Dateien inkludierst und den eigentlich 
Temp-Umrechnungsfaktor heraus-ge-ifndef-nt hast und der jetzig gültig 
der Umrechenfaktor der Temperatur ist.

(In deinem Falle würde also immer das zuletzt definierte gelten)

Autor: Cimbom Gs (cimbomgs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:
> (In deinem Falle würde also immer das zuletzt definierte gelten)

stimmt, da hast du ganz recht. Es ist das selbe wie wenn ich die #ifndef 
weglasse. Aber ich verwende solche Definitionen nicht, zumindest nicht 
mehrere die gleiche Bezeichnung haben.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#ifndef _BSP_H
#define _BSP_H

Das obige ist uebrigens nicht erlaubt, weil Bezeichner mit fuehrendem _ 
fuer den Compiler reserviert sind. Lass den Unterstrich am besten 
einfach weg, um wohlgeformten Code zu schreiben. Oder mach ihn ans Ende, 
da ist es erlaubt.

void main() ist ein anderer Punkt, das sollte selbstverstaendlich int 
main() heissen, damit jeder C-Compiler das akzeptiert.

Autor: Cimbom Gs (cimbomgs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris wrote:
> Das obige ist uebrigens nicht erlaubt, weil Bezeichner mit fuehrendem _
> fuer den Compiler reserviert sind.

das höre ich zum ersten mal :-(..Bei Minus-Zeichen "-" würde ich sagen 
ok geht nicht aber dass Unterstrich für Compiler reserviert sein soll, 
noch nie gehört.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> aber dass Unterstrich für Compiler reserviert sein soll,
> noch nie gehört.

Ist aber so, sofern der Unterstrich ein führender ist.

Autor: Cimbom Gs (cimbomgs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus t. Firefly wrote:
>> aber dass Unterstrich für Compiler reserviert sein soll,
>> noch nie gehört.
>
> Ist aber so, sofern der Unterstrich ein führender ist.

wenn das so ist, warum beginnt jede Header-Datei in der Library von 
Freescale mit:
#ifndef __xxx
#define __xxx
bei 2 Unterstrichen würde sich ja wohl nichts ändern..

Es ist wohl von Compiler zu Compiler unterschiedlich und bei dem 
Compiler, was ich benutze, gilt der Unterstrich nicht

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt einen -verbindlichen- C-Standard, wenn sich ein Hersteller nicht 
daran hält, gilt der Standard dennoch.

Autor: Cimbom Gs (cimbomgs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus t. Firefly wrote:
> Es gibt einen -verbindlichen- C-Standard, wenn sich ein Hersteller nicht
> daran hält, gilt der Standard dennoch.

Was kann denn passieren, wenn der Standard nicht eingehalten wird?

Ich kann es nirgends finden, dass führender Unterstricht nicht erlaubt 
sei..kann mir jemand einen Link geben?

Danke!

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cimbom Gs wrote:
> Rufus t. Firefly wrote:
>> Es gibt einen -verbindlichen- C-Standard, wenn sich ein Hersteller nicht
>> daran hält, gilt der Standard dennoch.
>
> Was kann denn passieren, wenn der Standard nicht eingehalten wird?

Du kannst gleichartige Definements in vom Hersteller zur Verfügung
gestellten Header Files und deinen eigenen haben. Solche Fehler
sind äußerst ekelig und schwer zu finden.

Durch die Regelung hat man so etwas wie einen Namespace geschaffen,
so dass garantiert ist (wenn sich alle daran halten), dass es
zu keinen unliebsamen Überraschungen kommen kann.

>
> Ich kann es nirgends finden, dass führender Unterstricht nicht erlaubt
> sei..kann mir jemand einen Link geben?

Kauf dir den C-Standard. Da stehst drinnen.

Mein Gott: Das ist doch keine Reketentechnik! Halte dich an die
einfache Regel, dass ein Name der mit Unterstrich und dann ein
Grossbuchstabe für dich tabu ist und gut ists. Das ist doch nun
wirklich kein Beinbruch.


http://gcc.gnu.org/onlinedocs/cpp/System_002dspeci...

> wenn das so ist, warum beginnt jede Header-Datei in der Library von
> Freescale mit:
> #ifndef __xxx
> #define __xxx
> bei 2 Unterstrichen würde sich ja wohl nichts ändern..

Freescale ist meines Wissens immer noch Hersteller eines Compilers.
Damit gilt für Freescale genau diese Regelung: Ihre eigenen
definements machen sie mit __ und damit in dem 'Namespace' der
für den Compilerhersteller reserviert wurde.

Autor: Cimbom Gs (cimbomgs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK jetzt verstehe ich :-)

>All names which begin with two underscores, or an underscore and a capital 
>letter, are reserved for the compiler and library to use as they wish

Daher sollte ich als Entwickler KEINE Unterstriche benutzen ^^, weil es 
ja für den Compiler und der Library reserviert ist.
Und darum beginnt in der Library vom Hersteller jede Header-Datei mit 2 
Unterstrichen
> #ifndef __xxx
> #define __xxx

und daher gilt diese Aussage:
>Du kannst gleichartige Definements in vom Hersteller zur Verfügung
>gestellten Header Files und deinen eigenen haben.

Vielen Dank @all und besondern @ Karl heinz Buchegger..

Dankeschön ^^

Autor: Oliver Sch. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry ich finden Vorschlag Müll ehrlich,

Es macht keinen Sinn erst alle Funktionen in eigne Header und C-Files zu 
kapseln und dann alles über einen Generischen Header wieder zu 
inkludieren, Dann kannst du dir das Kapseln auch gleich Sparen. Zumal 
das nicht nur beim Kompielerin mehr Zeit Kostet und unter Umständen 
großer Objekt Dateien erzeugt. Auch das Warten wird ein Horror.
Kapsel deine Funktion Vernünftig , so das es nicht zu so vielen includes 
kommt, wenn dir das nicht möglich ist stehe zu Komplexität deines 
Projekt. Aber alle inkludiert in einen Header auslagern macht kein Sinn. 
Zumal du dann auch Probleme mit defines bekommen Könntest
Und das

#ifndef BLA
#define BLA 25
#endif

ist auch keine Lösung wenn du bla 2 mal hast bekommst du falsche 
Ergebnisse.
wenn es zu viele Headers gibt, die du immer wieder inkludieren musst 
hast du entweder ein sehr Komplexes Projekt oder eine falsche Aufteilung 
der Funktionalität in die Header, beides löst man durch ein Überdenken 
des Software Design.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Die Kompilierzeiten werden (je nach Größer der Headers) etwas länger
>> sein, weil der Compiler auch unbenutzte Headers unnötigerweise
>> durchnudelt.
>
> ja gut das passiert ja nur einmal beim Beginn, es muss ja nur einmal
> kompiliert werden..

... pro Datei, die deinen generischen Header verwendet.

Autor: Cimbom Gs (cimbomgs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja gut aber das macht ja die Software..sobald daraus ein Hex-Datei 
erstellt wird und auf den Mikrocontroller geflasht wird, spielt es doch 
keine Rolle mehr oder?!

Es verbraucht auch nicht mehr Speicherplatz

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahem, ich arbeite seit kurzem an einem Projekt mit, welches zwar nicht 
allzu kaputt ist, aber:
Es gibt in dem Projekt ziemlich viele magische Header, die von fast 
jeder Quelldatei direkt oder indirekt eingebunden werden, und - das ist 
das Üble - bei Erweiterungen der Software geändert werden müssen. Je 
nachdem an was du gerade genau arbeitest, machst du dann relativ viele 
Kaffee- und Rauchpausen, bis du wieder mal testen kannst.

Wenn dein Projekt wirklich "riesig" ist, wie du in deinem ersten Post 
schreibst, würd ich an deiner Stelle Dateiabhängigkeiten nicht 
auswuchern lassen.

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Insbesondere würd ich Dateiabhängigkeiten nicht durch Einführung eines 
generischen Headers künstlich vergrössern.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cimbom Gs wrote:
> ja gut aber das macht ja die Software..sobald daraus ein Hex-Datei
> erstellt wird und auf den Mikrocontroller geflasht wird, spielt es doch
> keine Rolle mehr oder?!
>
> Es verbraucht auch nicht mehr Speicherplatz

Das nicht.

Aber du führst damit das Arbeitsprinzip deines Make
ad absurdum.

Make hat die Aufgabe Abhängigkeiten beim Erstellen eines
Projektes zu berücksichtigen. Wenn ein Source Code File
B.CPP nicht von einem Header File A.H abhängt, dann braucht
es auch nicht neu kompiliert werden, wenn sich A.H ändert.

Mit einem generellen Header File hängt dann aber jedes *.CPP
von allen Headern *.H ab. D.h. jede Änderung in irgendeinem
x-beliebigen Header File führt dazu, dass alle *.CPP neu
kompiliert werden.

Bei kleinen Mikrocontroller Projekten mag das angehen.
Bei großen Projekten (vor allem, wenn wir uns von µC
entfernen und auf PC-Ebene übergehen) kann das aber
zeitlich ins Gewicht fallen und einen ziemlichen
Unterschied in der Entwicklungszeit ausmachen. Entwicklungs-
zeit ist aber teuer.

Das andere Argument:
Wenn du tatsächlich alle Header Files quer durch das Projekt
in vielen (bis allen) *.CPP Files benötigst, dann sollte man
mal untersuchen, ob hier nicht ein Designfehler vorliegt. Die
einzige Ausnahme ist die Datei in der main() enthalten ist, aber
ansonsten ist dieser Fall eher selten.
Mit der einfachen Grundregel "jedes Header File, jedes Source Code
File inkludiert genau die Header die es selbst unbedingt benötigt"
fährt man eigentlich auf lange Sicht immer am Besten.

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.