Array aus Struct an Funktion übergeben (Call by Reference)
-
will das machen aber es kommen im .net immer Warnungen so nun meine Frage wie bring ich die Weg und übergebe das array aus struct perfekt an funktion?
WARNUNG = warning C4133: 'Funktion': Inkompatible Typen - von 'Person [10]' zu 'Person *'
void setPerson (struct Person Person[10]) {
}
struct Person{
char vorn[5];
char nname[20];
} Person[10];setPerson (Person);
-
hab grad herausgefunden dass wenn man das
struct Person{
char vorn[5];
char nname[20];
} Person[10]; global macht und die übergabeparameter so lässt alles wunderbar funktioniert aber warum ist das so???
-
die definition des datentypen, hier die struct, muss im gleichen namensraum wie die benutzer der struct erfolgen, also das struct Person und setPerson(...) müssen im gleichen namensraum sein
du hattest sicher erst das struct Person { .. } in einer anderen funktion drin, das geht so nicht
du kannst aber das array anlegen wo du willst, es muss nicht im globalen namensraum sein, es kann auch in der funktion seinhier ein beispiel:
#include <conio.h> #include <stdio.h> struct Person { char vorn[5]; char nname[20]; }; void setPerson(struct Person Person[10]) { } void main(void) { struct Person Person[10]; setPerson(Person); }
-
struct _Person_ { }; typedef struct _Person_ Person; void setPerson(Person *set_person)
-
man sollte eigentlich keine namen benutzen die mit einem _ beginnen,
denn diese art von namensgebung ist für compilerinterne sachen vorgesehen
-
bozo schrieb:
man sollte eigentlich keine namen benutzen die mit einem _ beginnen,
denn diese art von namensgebung ist für compilerinterne sachen vorgesehenMit Compilerinternen Sachen hat ein Programmierer nichts zu tun. Und Komplikationen sollte es auch nicht geben!
-
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
-
gh0st124 schrieb:
Und Komplikationen sollte es auch nicht geben!
Falsch! Namen, die mit _Grossbuchstabe oder mit __ beginnen, sind reserviert, duerfen also nicht verwendet werden!
-
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.
-
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 handBei 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
-
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.
-
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.
-
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.
-
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...).
-
#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.
-
@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?
-
__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
-
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?
-
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!
-
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.