Array aus Struct an Funktion übergeben (Call by Reference)
-
weiß nicht wem ich zuerst antworten sollte...
Nur empfehl bitte keinen anderen Leuten Code, der nicht Standard-Kompatibel ist (außer sie fragen danach), wir sind hier nunmal im ANSI-C Forum.
1.@kingruedi: nimms nicht persönlich, aber wovon zum Teufel/Geier redest du? Ich habe nur ein Code-Sample gezeigt und wurde wegen dem Coding-Style kritisiert. Erst die Beiträge lesen, bevor man irgendwelche Behauptungen aufstellt.
Warum nicht gleich den Fehler vermeiden? Und warum machst du nicht gleich
o Weil ich dann unmengen von sauberem Quellcode, die mindestens, Achtung: ich sagte mindestens, 3 Compiler kompatibel sind, ändern muss.
Unter Kompatibel verstehe ich = der verdammte Compiler gibt keine einzige verdammte Warnung aus!o kein Bock.
o Warum nicht gleich dein Coding-Style mir aufzwingen
o in den header-Dateien gibt es so viele Bezeichner, Makros, die gar keine _'s besitzen. Ein Restrisiko ist also immer da!
Nur um nicht kompatibel zum Standard zu sein?
Nein, nur um nicht kompatibel zu deinem Standard zu sein
2.@azoikum:
Schmaranz sagt:
C.2 Coding-Rules
Die hier angeführten Regeln helfen, den Source-Code so weit wie möglich zu
vereinheitlichen und damit die Arbeit im Team zu erleichtern:[...]
o Namen von Bezeichnern müssen den folgenden Konventionen genügen:
Funktionen: erstesWortKleinRestCapitalizedOhneUnderlines
Konstanten: GROSS_MIT_UNDERLINES
Lokale Variablen: klein_mit_underlines
Globale Variablen: klein_mit_underlines_und_underline_am_ende_
Structures: _CapitalizedMitUnderlinesZuBeginnUndEnde_
Diese dürfen nicht direkt verwendet werden, sondern nur über ein
typedef (=typedef'ed Structures)!
typedef'ed Structures: DurchgehendCapitalizedOhneUnderlines
Unions: _CapitalizedMitUnderlinesZuBeginnUndEnde_
Diese dürfen nicht direkt verwendet werden, sondern nur über ein
typedef (=typedef'ed Unions)!
typedef'ed Unions: DurchgehendCapitalizedOhneUnderlinesIch habe mir sein Werk zwei mal durchgelesen und weiß ganz genau, was er geschrieben hat und was nicht. So.
-
@ghost
Du hast vielleicht jetzt keine Probleme mit deinen mindestens 3 Compilern. Aber was ist, wenn von deinem Compiler eine neue Version rauskommt und genau dieser Compiler hat auf einmal irgendeine globale Variable definiert, die du durch deinen Quellcode als struct überschreibst? Die Folge kann sein, dass du deinen Quellcode nicht mehr compilieren kannst und ab einer gewissen Anzahl von Codezeilen ist es kein Leichtes mehr den Fehler zu finden.
Wenn du das natürlich bedenkenlos riskieren möchtest, ist das deine Sache. Wir wollen dir ja nur Tipps geben, damit du Probleme vermeiden kannst.
-
@gh0st124,
ich entschuldige mich bei dir.
Ich habe Klaus Schmaranz zum Teil falsch interpretiert.
-
gh0st124 schrieb:
Warum nicht gleich den Fehler vermeiden? Und warum machst du nicht gleich
o Weil ich dann unmengen von sauberem Quellcode, die mindestens, Achtung: ich sagte mindestens, 3 Compiler kompatibel sind, ändern muss.
Unter Kompatibel verstehe ich = der verdammte Compiler gibt keine einzige verdammte Warnung aus!o kein Bock.
o Warum nicht gleich dein Coding-Style mir aufzwingen
o in den header-Dateien gibt es so viele Bezeichner, Makros, die gar keine _'s besitzen. Ein Restrisiko ist also immer da!
Da fällt mir doch als schönes Beispiel die Nummer im VC6-Compiler ein mit Schleifen der art for (int i; i < 10; i++), wo der VC6-Compiler die Variable afair im Scope der umgebenden Funktion/Whatever definiert hat und nicht wies der Standard vorschreibt, mit dem Effekt dass i im VC6 auch nachm for definiert ist, was nicht sein soll. Angenommen ich schreibe nun ein Programm damit und jemand will dass ichs ändere (z.B. die Deklaration des i rausziehen), weils nicht dem Standard entspricht
<bogusargumente>
o mein Programm kompiliert warnungsfrei auf dem VC6-Compiler und die werden ja wohl wissen wies geht
o kein Bock zu ändern
o zwing mir doch gleich deinen Coding-Style auf
o C hat teilweise undefinierte Statements. Ein Restrisiko ist also immer da!
</bogusargumente>Das alles macht die Standardverletzung auch nicht besser und sorgt garantiert irgendwann für Ärger, nämlich z.B. wenn ein neuer VC-COmpiler kmmt, ders richtig macht.
Und falls du noch interne Bezeichner suchst mit Doppel-Unterstrich, schau dir mal auf einem Linux-System z.B. die Standard-C-Library im mc an, da ist rund die hälfte der exportierten Dinger mit __
-
Das Beispiel finde ich nicht passend.
@aj:
Die Folge kann sein, dass du deinen Quellcode nicht mehr compilieren kannst und ab einer gewissen Anzahl von Codezeilen ist es kein Leichtes mehr den Fehler zu finden.
Borland Compiler: multiple declaration for +++
gcc Compiler: conflicting types for +++, previous declaration for +++
usw.==> aus den Fehlermeldungen wird klipp und klar deutlich, wo der Fehler steckt.
Du muss beachten, dass ich nur die struct _SoDefiniere_, also nur an einer STelle; danach benutze ich ja nur noch den typedefed struct ohne _.
Also bei einer Real-World-Fehlermeldung müsste ich nur eine Stelle ändern.
-
Was ist schlimmer? Ignoranz oder Dummheit?
Weiß ich nicht, ist mir sowieso egal.
-
Schwein melde dich