Array aus Struct an Funktion übergeben (Call by Reference)

[gh0st124]

bozo schrieb:

man sollte eigentlich keine namen benutzen die mit einem _ beginnen,
denn diese art von namensgebung ist für compilerinterne sachen vorgesehen

Mit Compilerinternen Sachen hat ein Programmierer nichts zu tun. Und Komplikationen sollte es auch nicht geben!

[bozo]

es könnte ein von dir definierter name einen compilerinternen überdecken und so zu problemen führen, ist zwar recht unwahrscheinlich, aber der standart legt dies so fest, und es gibt keinen grund warum man sich nicht daran halten kann

ich benutze z.b.:

typedef struct person_s
{
} person_t;

// oder

struct person_s
{
};

typedef struct person_s person_t;

aber im grossen und ganzen ist das wohl alles eine geschmacks- und gewöhnungssache

[SG1]

gh0st124 schrieb:

Und Komplikationen sollte es auch nicht geben!

Falsch! Namen, die mit _Grossbuchstabe oder mit __ beginnen, sind reserviert, duerfen also nicht verwendet werden!

[gh0st124]

SG1 schrieb:

gh0st124 schrieb:

Und Komplikationen sollte es auch nicht geben!

Falsch! Namen, die mit _Grossbuchstabe oder mit __ beginnen, sind reserviert, duerfen also nicht verwendet werden!

Bitte erst Quelle angeben! Namen, die mit _Grossbuchstabe oder mit __ beginnen, sind NICHT reserviert! Sonst würden die Compiler lauter Fehlermeldungen ausspucken! Ich benutze die CodingConvention von Klaus Schmaranz.

Bei dem CodingStandard von bozo gibt es keine Unterscheidung zwischen lokalen/globalen Variablen und Strukturen.

Wie gesagt: alles eine geschmacks- und gewöhnungssache.

[bozo]

z.b.:

von http://oakroadsystems.com/tech/c-predef.htm und http://oakroadsystems.com/tech/cppredef.htm

never make up any identifier that starts with an underscore.
(Actually, you can legally use an identifier that starts with an underscore if the second character is a lower-case letter or a digit, and the identifier is used inside a function or a function prototype or as a structure member or label. Easier just not to use leading underscores!)

never make up any identifier that starts with an underscore.
(Strictly speaking, a leading underscore followed by a digit or lower-case letter is legal in your own namespaces (but never in the global namespace or ::std). However, articles in the comp.std.c++ newsgroup have warned that some compilers do improperly use such identifiers for their own purposes, so my advice is to steer clear. A trailing single underscore should be fine.)
Any name with two consecutive underscores in any position is reserved for the implementation.

das habe ich mal schnell mit google gefunden,
in der vergangenheit habe ich dies aber an sehr vielen stellen gelesen, dass man namen mit _... meiden soll,
habe aber leider keine offizielle docu vom ansi std. zur hand

Bei dem CodingStandard von bozo gibt es keine Unterscheidung zwischen lokalen/globalen Variablen und Strukturen.

sehe ich bei dir aber auch nicht

ich benutze dafür immer ein prefix, z.b. g_... oder m_... für global und modul

[SG1]

gh0st124 schrieb:

SG1 schrieb:

gh0st124 schrieb:

Und Komplikationen sollte es auch nicht geben!

Falsch! Namen, die mit _Grossbuchstabe oder mit __ beginnen, sind reserviert, duerfen also nicht verwendet werden!

Bitte erst Quelle angeben! Namen, die mit _Grossbuchstabe oder mit __ beginnen, sind NICHT reserviert!

C99, 7.1.3

Sonst würden die Compiler lauter Fehlermeldungen ausspucken!

Seit wann muss ein Compiler bei undefiniertem Verhalten Warnungen, geschweige denn Fehlermeldungen ausspucken? (C99, 3.4.3)

Ich benutze die CodingConvention von Klaus Schmaranz.

Schoen fuer Dich, ich halte mich da lieber an den Standard.

Wie gesagt: alles eine geschmacks- und gewöhnungssache.

http://www.nuhr.de/data/FRESSEHA.MP3

[gh0st124]

Seit wann muss ein Compiler bei undefiniertem Verhalten Warnungen, geschweige denn Fehlermeldungen ausspucken? (C99, 3.4.3)

Falsch! Namen, die mit _Grossbuchstabe oder mit __ beginnen, sind reserviert, duerfen also nicht verwendet werden!

Weiß du was reserviert heißt? In C gibt es an die 30 reserved words. Und nicht ein einziges beginnt mit einem Underscore. Und wenn du behauptest, dass alles mit Underscore davor ein reserved word ist, dann verstehe ich darunter:
_irgendeintext = array oder int...

Und wenn du array als Variablennamen nimmst, dann gibt es deiner Meinung nach keine ErrrorMeldungen seitens des Compilers?

Schoen fuer Dich, ich halte mich da lieber an den Standard.

1.Hast du die leiseste Ahnung, wer der Typ ist?
2.Meinst du den Standard von Kernighan und Ritchie? Wenn Ja, dann ist dein CodingStandard älter als 20 Jahre.

[SG1]

gh0st124 schrieb:

Weiß du was reserviert heißt? In C gibt es an die 30 reserved words.

Du meinst Schluesselworte (C99 6.4.1). Ich sprach von "reservierten Namen", und meinte damit das, was im Standard "Reserved Identifiers" (C99, 7.1.3) genannt wird. Dort findet sich dann auch
"If the program declares or defines an identifier in a context in which it is reserved (other than as allowed bei 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined."

Schoen fuer Dich, ich halte mich da lieber an den Standard.

1.Hast du die leiseste Ahnung, wer der Typ ist?

Nein. Sollte ich?

2.Meinst du den Standard von Kernighan und Ritchie? Wenn Ja, dann ist dein CodingStandard älter als 20 Jahre.

Nein, ich beziehe mich auf ISO/IEC 9899:1999, auch bekannt als C99, den einzig derzeit gueltigen C-Standard.

[Bashar]

gh0st124 schrieb:

Schoen fuer Dich, ich halte mich da lieber an den Standard.

1.Hast du die leiseste Ahnung, wer der Typ ist?
2.Meinst du den Standard von Kernighan und Ritchie? Wenn Ja, dann ist dein CodingStandard älter als 20 Jahre.

Welcher Typ? Der Standard ist ein Dokument, was 1990 erstmals und dann in einer neuen Version 1999 von der ISO herausgegeben wurde. Das ist kein Codingstandard, sondern die verbindliche Definition der Programmiersprache C.

Die Tatsache, dass Namen die mit __ oder _Grossbuchstabe beginnen, ausdrücklich reserviert sind, gibt dem Compilerhersteller die Möglichkeit, Bezeichner vor dem Programmierer zu schützen.

Angenommen, ich habe folgendes Programm:

#define FOO 42
#include <stdio.h>

int main() {
  puts("Hello world!");
}

Hat der Compilerhersteller nun in der stdio.h gerade zufällig den Namen FOO benutzt, wird das ganze höchstwahrscheinlich nicht so funktionieren, wie man sich das vorgestellt hat. Obwohl es ein konformes Programm ist.
Daher ist der Namensbereich, den compilerinterne Namen bewohnen, streng von dem benutzerzugänglichen Bereich getrennt, so gibt es hier keine Schwierigkeiten.

Zu den reservierten Namen gehören alle die mit 2 Unterstrichen anfangen (in C++ auch die, die 2 Unterstriche irgendwo enthalten), solche die mit einem Unterstrich, gefolgt von einem Großbuchstaben anfangen, sowie als externe Bezeichner Namen mit einem einfachen Unterstrich. Dazu Erweiterungen bestimmter Funktionsfamilien, str..., wcs... oder auch andere errno-Konstanten (E...).

[gh0st124]

#include <stdio.h>

struct _Test_
{
	int a;
};

typedef struct _Test_ Test;

int main(void)
{
        Test Sigi = { 5 };
        int _Test_ = 4;

        printf("%d %d", _Test_, Sigi.a);

	return(0);
}

Man sieht keine Komplikationen zwischen struct _Test_ und Variablennamen _Test_. Gut, wenn es eine Struct _Test_ bereits geben sollte, dann kommen schon Fehler auf, aber Hey, wieso sollte ich denn dann das Rat neu erfinden???

Außerdem: Splint 3.0.1.6 Finished Checking -- no warnings

Natürlich bleibt ein Restrisiko, damit kann ich aber leben.

[rüdiger]

@gh0st124
warum sollte ich riskieren mit dem Compiler in Konflikt zu geraten, nur wegen des dummen Dateinamens? Das ist wirklich das geringste Problem, sich hier an den Standard zu halten.

Im Endeffekt funktioniert auch folgender Code auf einigen Compilern.

int *ptr=malloc(sizeof(int));
free(ptr);
*ptr=100;
printf("%d\n",*ptr);

Aber willst du das jetzt in jedem Programm so machen?

[gh0st124]

__dies_benutze_ich__
und
_Dies_

Hab mir gerade eine header-Datei angesehen (stdio.h) und habe nirgends einen Namen gefunden, der mit 2(bzw. 1) Underscore(s) anfängt und WIEDER MIT 2 (bzw. 1) Underscore(s) endet.

Wenn es mal zu Komplikationen kommen sollte, wenn, dann wird es kein schwer zu findender Fehler sein...

Außerdem: was genau meinst du mit Compilerinternen Sachen? Header-Dateien nehmen ich an, oder etwa nicht?

Danke

[rüdiger]

Hab mir gerade eine header-Datei angesehen (stdio.h) und habe nirgends einen Namen gefunden, der mit 2(bzw. 1) Underscore(s) anfängt und WIEDER MIT 2 (bzw. 1) Underscore(s) endet.

Du weisst, dass es nicht nur einen Compiler und eine Standard-Library gibt?

Wenn es mal zu Komplikationen kommen sollte, wenn, dann wird es kein schwer zu findender Fehler sein...

Warum nicht gleich den Fehler vermeiden?

Außerdem: was genau meinst du mit Compilerinternen Sachen? Header-Dateien nehmen ich an, oder etwa nicht?

jo, Header-Dateien und die Standard-Library.

Im Endeffekt kannst du Code schreiben, den du schreiben willst. 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.

Und warum machst du nicht gleich

typedef struct { int foo; } bar;

?

Nur um nicht kompatibel zum Standard zu sein?

[Shade Of Mine]

gh0st124 schrieb:

Wenn es mal zu Komplikationen kommen sollte, wenn, dann wird es kein schwer zu findender Fehler sein...

denkst du

http://www.gotw.ca/gotw/085.htm
ziemlich weit unten ab "Don't stop! Keep reading!"

Es ist ein böser Fehler, weil du ihn nur schwer entdecken kannst. Und es tut überhaupt nicht weh, den Fehler gleic zu vermeiden!

[azoikum]

Na hier ist ja was los.
@gh0st124, mir sagt Klaus Schmaranz etwas.
Ich habe ein gutes Tutorial von ihm.
Und das ist wirklich gut.
Zerreiß mich bitte nicht aber,
er definiert Variablen (auch struct) in der Art:

unsigned int a_u_int_ = 0;

Also nicht _a_u_int || __a_u_int.
Schau mal bitte nach.

Gruß, azoikum.

[gh0st124]

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: DurchgehendCapitalizedOhneUnderlines

Ich habe mir sein Werk zwei mal durchgelesen und weiß ganz genau, was er geschrieben hat und was nicht. So.

[AJ]

@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.

[azoikum]

@gh0st124,
ich entschuldige mich bei dir.
Ich habe Klaus Schmaranz zum Teil falsch interpretiert.

[TriPhoenix]

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 __

[gh0st124]

@TriPhoenix:

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.