C Verständisfrage objekt kopie

[SoIntMan]

Hallo Leute,

und zwar folgendes. Ich habe einen string "StringA"

typedef char sStringA_t[50];
  const sStringA_t a = "2323";
  sStringA_t b = { 0 };
  b = a; //Geht nicht. änderbare LValue nötig was klar.

wenn ich aber den string in ein struct verpacke:

typedef struct sStringB_t
{
    char s[50];
}sStringB_t;


    
    sStringB_t a = { "232323" };
    sStringB_t b = { 0 };
    b = a; //Geht

nun das ist mir nicht "ganz" klar... was der compiler da macht...

Im Ersten Fall ist der string ein Pointer auf ein speicher bereich von 50 chars und muss da memcpy bzw. strcpy machen.

Aber im zweiten fall ist das ja ein objekt aufm stack, und der compiler macht dann bei der Zuweisung eine impliziertes memcpy?

[SeppJ]

Das hast du dir korrekt erschlossen.

Wobei man vielleicht noch nachtragen sollte, dass das Speicherlayout bei beiden identisch ist. Die Unterschiede sind syntaktischer Art, wie ein Array und ein Struct von der Grammatik von C her unterschiedlich benutzt werden.

[SoIntMan]

@SeppJ sagte in C Verständisfrage objekt kopie:

Wobei man vielleicht noch nachtragen sollte, dass das Speicherlayout bei beiden identisch ist. Die Unterschiede sind syntaktischer Art, wie ein Array und ein Struct von der Grammatik von C her unterschiedlich benutzt werden.

Danke für deine Antwort.

Wenn das Speicherlayout das selbst ist, wieso wird dann bei array copy keine implizites memcpy gemacht?

[SeppJ]

@SoIntMan sagte in C Verständisfrage objekt kopie:

Wenn das Speicherlayout das selbst ist, wieso wird dann bei array copy keine implizites memcpy gemacht?

Weil die Regeln von C das so sagen

Die Idee dahinter ist wahrscheinlich, dass man ein Array nicht eben einfach so unabsichtlich kopieren will, sondern dass das eine spezielle Sonderaktion sein sollte, die man speziell auslösen muss. Dann ist es gut, wenn man das, was man meistens will, das ist, was einfacher zu schreiben ist.

Das ist natürlich ein Design, dass schon unzählige Anfänger zu Fehlern getrieben hat, aber die Sprache richtet sich halt an Profis, die genau wissen, was sie tun.

[wob]

@SeppJ sagte in C Verständisfrage objekt kopie:

aber die Sprache richtet sich halt an Profis, die genau wissen, was sie tun.

Dieses Argument finde ich immer etwas schwach, weil auch Profis Fehler machen. Ja, man möchte natürlich die Möglichkeit haben, ganz genau bestimmen zu können, was passieren soll - aber man möchte auch möglichst wenig Überraschungen haben. Und die andere Frage ist: C ist schon recht alt. Hat man damals, als man diese Regeln so bestimmt hat, wirklich gedacht "Lass mal ne Sprache für Profis machen" oder ist das nicht eher nachträglich rangedichtet - wollte man damals nicht eher eine Hochsprache haben, die Dinge vereinfacht?

Bis auf diesen Halbsatz stimme ich dir ansonsten zu.

[Nachredner]

@SeppJ sagte in C Verständisfrage objekt kopie:

Das ist natürlich ein Design, dass schon unzählige Anfänger zu Fehlern getrieben hat, aber die Sprache richtet sich halt an Profis, die genau wissen, was sie tun.

Das sehe ich genauso wie wob. Ich stimme deiner Aussage bis auf die letzten Halbsätze zu.

Das hat eher etwas von: Das ging im Nachhinein nicht besser - denn etwas gut durchdachtes.

Btw., mit Java hat man solchen Stress nicht - da man genau wusste, dass Zeichenketten in C ein Problem sind, und sich schlauerweise auf etwas Einheitliches (und Besseres) festgelegt hat.

[SoIntMan]

Naja.. unterbewusst habe ich immer bei solchen dingen nach "best-practices" gehandelt.. aber habe es jetzt einfach mal hinterfragen wollen;) wieso das so ist;)

Danke für euere Antworten

[Nachredner]

@SoIntMan sagte in C Verständisfrage objekt kopie:

aber habe es jetzt einfach mal hinterfragen wollen;) wieso das so ist;)

Das ist wegen des Encodings so - und UTF-8 bzw. 16 gab es damals noch nicht.

[SoIntMan]

@Nachredner sagte in C Verständisfrage objekt kopie:

Das ist wegen des Encodings so - und UTF-8 bzw. 16 gab es damals noch nicht.

ja es nicht explizit um ein string char array, sonndern im allgmeinnen um arrays:

typedef struct stFoo_t
{
    int bar;
} stFoo_t;

typedef stFoo_t stArray[50];

typedef struct stArrayNested
{
    stFoo_t s[50];
}stArrayNested;

und dann objekt/Array zuweisung:

stArray a1 = { ... };
stArray b1 = { 0 };
b1 = a1; //Geht nicht. änderbare LValue nötig was klar.
    
stArrayNested a2 = { ... };
stArrayNested b2 = { 0 };
b2 = a2; // geht (implizit memcpy)

das hat mich irritiert;)

[Quiche Lorraine]

@SoIntMan sagte in C Verständisfrage objekt kopie:

ja es nicht explizit um ein string char array, sonndern im allgmeinnen um arrays:

Ich bin mir nicht sicher ob Nachredner eine Inkarnation unseres Forentrolls ist.

[Quiche Lorraine]

@wob sagte in C Verständisfrage objekt kopie:

Hat man damals, als man diese Regeln so bestimmt hat, wirklich gedacht "Lass mal ne Sprache für Profis machen"

Ich vermute wohl eher: "Lass uns nicht mehr mit Assembler programmieren."

[SeppJ]

@wob sagte in C Verständisfrage objekt kopie:

@SeppJ sagte in C Verständisfrage objekt kopie:

aber die Sprache richtet sich halt an Profis, die genau wissen, was sie tun.

Dieses Argument finde ich immer etwas schwach, weil auch Profis Fehler machen. Ja, man möchte natürlich die Möglichkeit haben, ganz genau bestimmen zu können, was passieren soll - aber man möchte auch möglichst wenig Überraschungen haben. Und die andere Frage ist: C ist schon recht alt. Hat man damals, als man diese Regeln so bestimmt hat, wirklich gedacht "Lass mal ne Sprache für Profis machen" oder ist das nicht eher nachträglich rangedichtet - wollte man damals nicht eher eine Hochsprache haben, die Dinge vereinfacht?

Du musst das aber andersrum sehen: Ein Array unabsichtlich zu kopieren ist der eigentliche Fehler. Daher ist es möglichst schwer gemacht, diesen Fehler zu machen. Mit dem Nebeneffekt, dass unbedarfte Anfänger dann eben Fehler anderer Art machen, weil das Verhalten von Arrays anders ist, als von allen anderen Objekten, was man halt einfach wissen muss.

[Tyrdal]

@wob sagte in C Verständisfrage objekt kopie:

@SeppJ sagte in C Verständisfrage objekt kopie:

aber die Sprache richtet sich halt an Profis, die genau wissen, was sie tun.

Hat man damals, als man diese Regeln so bestimmt hat, wirklich gedacht "Lass mal ne Sprache für Profis machen"

Damals hatten sich die wenigsten hobbymäßig ne PDP-11 o.ä. ins Kinderzimmer gestellt. Von daher waren einfach alle Profis. Und Ziel von C war die Entwicklung von Unix portabler zu machen. Vorher war assembler das Mittel der Wahl.