Externe Variablen in C

  • Externe Variablen in C

    in K&R steht in Kapitel 1.10 folgendes über externe Variablen: "The variable must also be declard in each funtion that wants to access it."

    Dann ein Programm mit externen / globalen Variablen.

    In diesem Programm werden außerhalb jeglicher Funktion externe / globale Variablen definiert.

    Dann jedoch, in den einzelnen Funktionen, die Deklaration eben dieser Variablen mit dem extern keyword vorneweg.

    Für die externe / globale Variable max wird in den jeweiligen Funktionen noch einmal extern int max deklariert.

    Ich selbst habe bisher globale Variablen lediglich einmal außerhalb jeglicher Funktion definiert und nie zusätzlich innerhalb einer Funktion deklariert.

    Das keyword extern ist bei mir nur für globale Variablen vorbehalten, die in einem seperat compilierten Code definiert wurden.
  • hier ein Ausschnitt aus dem Code des in K&R abgedruckten Programms

    Quellcode

    1. #inlude <stdio.h>
    2. #define MAXLINE 1000
    3. int max;
    4. char line[MAXLINE];
    5. char longest[MAXLINE];
    6. .
    7. .
    8. main()
    9. { extern int max;
    10. extern int longest[];
    11. .
    12. .
    13. }
    Alles anzeigen
    achtet auf die Variablen max und longest

    versteht ihr was ich meine?

    wieso wird die externe Variable max noch einmal mit dem keyword extern in main deklariert?

    ich habe das bisher nie so gemacht.
  • Das verstehe ich auch nicht. Deklaration und Definition wurde doch schon vor main erledigt, wozu nochmals deklarieren? Gut wenn die Sachen getrennt compiliert werden, dann weiß der Compiler durch extern dass die Definition woanders zu finden ist, aber hier in dem Beispiel fehlt mir auch der Sinn. Ich bin aber auch kein C Experte.
  • Aha wer lesen kann ist klar im Vorteil:

    Auf der darauffolgenden Seite steht geschrieben:

    "if the definition of an external variable occurs in the source file before it's use in a particular function, then there is no need for an extern declaration in the function."

    Das eine ist wohl die Schulversion von C und das andere ist wie es in der Praxis gemacht wird.
  • MOS schrieb:

    Aha wer lesen kann ist klar im Vorteil:

    Auf der darauffolgenden Seite steht geschrieben:

    "if the definition of an external variable occurs in the source file before it's use in a particular function, then there is no need for an extern declaration in the function."

    Das eine ist wohl die Schulversion von C und das andere ist wie es in der Praxis gemacht wird.
    Wichtig auch das "before it's use". Man kann ja auch Variablen unter der main-Funktion definieren und die würde der Compiler dann dort noch gar nicht kennen.
  • MOS schrieb:

    hier ein Ausschnitt aus dem Code des in K&R abgedruckten Programms

    achtet auf die Variablen max und longest

    versteht ihr was ich meine?

    wieso wird die externe Variable max noch einmal mit dem keyword extern in main deklariert?

    ich habe das bisher nie so gemacht.
    Das macht aus Faulheit so gut wie niemand. Korrekter wäre es allerdings, die (bei dieser Faulheit angewendete) implizite "extern"-Deklaration explizit anzugeben. Das erleichtert dem Compiler die Typprüfung (wurde hier ja schon erwähnt) und verhindert die (unbeabsichtigte) Vermischung von lokalen und Modul-globalen Variablen.

    Soweit ich weiß, ist das nicht ausschließlich K&R-Stil. Im ANSI-C (bis wenigstens C99) sollte das auch vorkommen. Ich kann mich irren, von daher möge man mich da gern korrigieren.

    Dummerweise hat es sich eingebürgert, zu Funktionen externe Variablen als "globale" Variablen zu bezeichnen, was so vereinfacht nicht stimmt. Das erschwert das Verständnis der "extern"-Deklaration innerhalb von Funktionen.
  • ogd schrieb:

    androSID schrieb:

    Das ist absolut nicht mehr zeitgemäß!
    So wie unser ganzes Hobby.

    Nicht alles, was hinkt, ist ein Vergleich...

    Die Programmiersprache ist ein Werkzeug um dem Hobby nachzugehen - nicht das Hobby!


    ps: Meine Kritik galt im übrigen ausschliesslich dem Coding-Style... und nicht der Sprache C (oder C++) an sich: Mit der verdiene ich seit 25 Jahren mein Geld!

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von androSID ()

  • mc71 schrieb:

    androSID schrieb:

    nicht das Hobby!
    Wer so etwas sagt, der bohrt auch Löcher in einen Ur-64er und dübelt ihn an die Wand...
    Abgesehen davon fallen ältere Compiler mitunter derbe auf die Schnauze, wenn man ihnen 'modernen Style' vorsetzt.

    Dann wirds Zeit einen neuen Compiler zu nehmen!

    Abgesehen davon: Einen Ur-64 habe ich bisher nicht an die Wand gedübelt... keine Ahnung was Dich zu dieser falschen Behauptung verleitet.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von androSID ()

  • androSID schrieb:

    Gut gemeinter Rat:

    Besorg Dir ein aktuelleres Buch zur Sprache C und eigne Dir um Himmels Willen nicht mehr den K&R Programmierstil/Coding Style an.

    Das ist absolut nicht mehr zeitgemäß!
    Falls es um "K&R" vs. "ANSI" C-Syntax geht:
    Stimmt.
    Falls es aber um "K&R" vs. "<whatever>" indentation style geht:
    :popcorn:
    Yes, I'm the guy responsible for the ACME cross assembler
  • Mac Bacon schrieb:

    Falls es um "K&R" vs. "ANSI" C-Syntax geht:Stimmt.

    Endlich einer der's versteht... Danke!


    Falls es aber um "K&R" vs. "<whatever>" indentation style geht:
    :popcorn:

    Ist Geschmacksache... das soll/muß jeder so halten wie er lustig ist! :D
    Die Hauptsache ist IMHO: Konsequent bleiben! Nix ist schlimmer als komplett fehlender
    Style bzw. inkonsequente Indentation.


    ps: Ich war mal in einem *wirklich großen* Projekt, da gab es Dateien komplett ohne Indentation! Das war fürchterlich
    zum warten. Ich hab' die Dateien dann mal formatiert und eingecheckt... Ergebnis: Anschiss vom Projektleiter,
    weil sein Diff/Merge-Tool auch whitespaces als Änderung betrachtet hat. OMG!

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von androSID ()

  • androSID schrieb:

    ps: Ich war mal in einem *wirklich großen* Projekt, da gab es Dateien komplett ohne Indentation! Das war fürchterlich
    zum warten. Ich hab' die Dateien dann mal formatiert und eingecheckt... Ergebnis: Anschiss vom Projektleiter,
    weil sein Diff/Merge-Tool auch whitespaces als Änderung betrachtet hat. OMG!
    Was ja auch völlig richtig ist. Es gibt Programmiersprachen, da sind die Whitespaces syntaktisch relevante Zeichen. Und nein, ich meine nicht Whitespace (da sowieso!). ;) Das Problem ist, dass der Trottel vorher keine gemacht hat. Ein ähnliches Problem hatten wir hier vor kurzem auch erst wieder.
    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890
  • 7Saturn schrieb:

    androSID schrieb:

    ps: Ich war mal in einem *wirklich großen* Projekt, da gab es Dateien komplett ohne Indentation! Das war fürchterlich
    zum warten. Ich hab' die Dateien dann mal formatiert und eingecheckt... Ergebnis: Anschiss vom Projektleiter,
    weil sein Diff/Merge-Tool auch whitespaces als Änderung betrachtet hat. OMG!
    Was ja auch völlig richtig ist. Es gibt Programmiersprachen, da sind die Whitespaces syntaktisch relevante Zeichen. Und nein, ich meine nicht Whitespace (da sowieso!). ;) Das Problem ist, dass der Trottel vorher keine gemacht hat. Ein ähnliches Problem hatten wir hier vor kurzem auch erst wieder.

    Wir sprachen hier über C... und das Projekt war in C/C++! Da ist es nicht relevant.
    Insofern sehe ich das anders: Der Aufwand sein Merge/Diff-Tool einmal umzukonfigurieren ist sicher deutlich geringer als der Aufwand, der entsteht beim
    Code lesen/warten. Schlimmer noch: Die Stelle war sehr zentral und musste oft angefasst werden!