GCC mag kein führendes 'v' im Funktionsnamen?

Daß der Compiler kein 'v' als ersten Buchstaben des Funktionsnamen
akzeptiert, oder daß 'verstaerkung' zu lang wäre, das kann beides mit
Sicherheit ausgeschlossen werden.

Das klingt eher nach Aufruf der Funktion ohne vorheriges Bekanntgeben
durch einen Prototypen.

Abhilfe:

entweder Funktionsdefinition im Sourcecode vor den Aufruf packen oder
Funktionsdeklaration (Prototyp) vor den Aufruf packen:

Erste Variante:

  void bla(void)
  {
    //...
  }

  int main(int argc, char **argv)
  {
    bla();
  }


Zweite und bessere Variante:

  // Prototyp
  void bla(void);

  int main(int argc, char **argv)
  {
    bla();
  }

  void bla(void)
  {
    //...
  }

_
die Deklaration steht korrekt am Anfang des
Quellcodes, mit Parametern und so weiter.
_


Hehe.
Prototypen Schreibt man ohne Parameter.

zB

int bla(int, char, char, int);

funktion:

int bla(int a, char b, char c, int d)
{
    //Tut
}

Schick's doch mal durch den Präprozessor... (avr-gcc ... -E).  Wenn du
alle Arten von Schreibfehlern konsequent ausschließen kannst, dann
würde ich fast meine nicht vorhandene Perücke drauf verwetten, dass du
irgendwo ein

#define verstaerkung foobar

hast.  Wenn du dann

void verstaerkung(void);

deklarierst, deklarierst du natürlich in Wirklichkeit

void foobar(void);

> Hehe.
> Prototypen Schreibt man ohne Parameter.

Schon. Ist von der Sprache her erlaubt.
Nur wenn Du das tust, bist Du Deinen Job los
:-)

Hab ich mir jetzt wohl ganz schöne Rügen mit eingesammelt mit der
Aussage.

In meinem C Buch für die Schule stand, Prototypen werden wie
Funktionsnamen geschrieben aber ohne Parameternamen. Darauf habe ich
mich bei der Aussage gestützt.

Nun gut, zugegeben, ich ändere gleich mal meine Programme um, ist
nämlich in der Tat besser :-)

In Läden, in denen auf brauchbar kommentierten und dokumentierten
Quelltext geachtet wird.

Hi

mal ein hypotetischer Codeschnipsel mit Kommentar:

1

/**

2

 * Calculates the volume of a cylinder

3

 *

4

 * @param hight

5

 * @param radius

6

 */

7

float calcCylinderVolume(float, float);

Ist ein gültiger Prototyp. Die Funktion ist fertig kompiliert in einer
Bibliothek. In welchen Parameter kommt jetzt der Radius und in welchen
die Höhe? Paramternamen kann man zwar in Prototypen weglassen man
sollte es aber unbedingt vermeiden.

Matthias

> @Karl Heinz,
> in was fuer nem Laden wird man fuer das Weglassen der
> Parameternamen im prototype rausgeschmissen, abgemahnt oder
> zumindest abgewatscht ?

Wenn Du in meiner Gruppe arbeitest.
Zuerst wirds einem freundlich erklaert,
dann schon etwas heftiger
und wenn alles nichts hilft: Tut uns leid.

Den Ueberblick ueber 15000 Funktionen zu behalten ist
so schon schwer genug. Da brauch ich nicht auch noch
Ratespiele.

> mal ein hypotetischer Codeschnipsel mit Kommentar:
1  /**
2   * Calculates the volume of a cylinder
3   *
4   * @param hight
5   * @param radius
6   */
7  float calcCylinderVolume(float, float);

Doxygen-Kommentare kommen aber besser in die Definition, nicht in die
Deklaration.  Die Definition hat aber immer Parameternamen...

Ist übrigens zwiespältig.  In meinem eigenen Code würde ich die Namen
wohl immer mitschreiben.  In Bibliothekscode (z. B. als avr-libc-
Maintainer) ist das nicht mehr so ohne weiteres möglich, da ein
beliebig erfundener (aussagekräftiger) Name ja im application
namespace liegt.  Man denke an sowas:

1

void *memcpy(void *dest, void *src, size_t len);

Wenn dann in der Applikation davor ein

#define len strlen(msg)

steht, ist das nicht mehr so lustig...

In der avr-libc haben wir daher alle Parameternamen mit führenden
Unterstrichen geschrieben, was wiederum in der Doku nicht so nett
aussieht.  Wenn mal jemand viel lange Weile hat, sollte man die Doku
aber besser aus den Headerfiles in die Implementierungsdateien ziehen
und in den Headers dann die Parameternamen einfach weglassen.

Hi

@Jörg
Über die platzierung von doxygen-Kommentaren kann man geteilter Meinung
sein. Ich platziere sie ganz gerne zur Deklaration ins Headerfile da
genau diese Datei die Schnittstellenbeschreibung enthält. Brauch ich
also eine Information zu dieser Schnittstelle ist diese Datei auch mein
erster Anlaufpunkt. Mit den aus den doxygen-Kommentaren erstellten
Dokumenten arbeite ich nur sehr selten bzw. wenn ich mir einen
Überblick über größere Zusammenhänge schaffen will.

#define len strlen(msg)

Wer sowas macht braucht sich nicht zu wundern das was nichtmehr
funktioniert. Präprozessormakros schreib ich nur mit Großbuchstaben
(das ist wohl fast überall so üblich). Im Quellcode selber entweder
aaa_bbb_ccc oder aaaBbbCdd und schon sind sämtlicher Kollisionen dieser
Art ausgeschlossen.

Matthias

> Präprozessormakros schreib ich nur mit Großbuchstaben
> (das ist wohl fast überall so üblich).

Nö.  Eigentlich nur für Konstanten und Makros mit Seiteneffekten.  OK,
strlen(msg) hat natürlich einen solchen. ;-)  Gerade bei den Makros,
die wie Funktionen behandelt werden, sind Kleinbuchstaben nicht
unüblich, siehe getc() in der stdio-Bibliothek.

Es ging ja auch nur ums Prinzip, als Bibliothekshersteller darf ich
mich einfach nicht auf die Freundlichkeit der Benutzer verlassen.