Nullelement eines struct

Probier es doch einfach mal aus.

Antwort: Nein. NULL ist kein Objdata_t. Du kannst aber auch einen Zeiger 
auf Objdata_t zurückgeben...

Und dein return obj; "funktioniert" zwar insofern, als der Compiler es 
übersetzt, es macht aber nicht das, was du sillst und ist ein grober 
Schnitzer.

Und man sieht dort sehr schön einen großen Vorteil von Rust 
(www.rust-lang.org): Der läßt das return obj; nämlich nicht zu, weil er 
die Lebensdauer von Variablen überprüft (und aufgrund des 
Rust-Typsystems im gegensatz zu C/C++ das auch eindeutig überprüfen 
kann).

Fred schrieb:
> Und dein return obj; "funktioniert" zwar insofern, als der Compiler es
> übersetzt, es macht aber nicht das, was du sillst und ist ein grober
> Schnitzer.

warum denn nicht? Es wird dabei eine Kopie vom objekt erzeugt und diese 
zurückgegeben.


Es wird allgemein angenommen das ein objekt selber nicht NULL sein 
sollte. Auch wenn es technisch geht.

wenn du also ein objekt oder NULL zurückgeben willst. dann verwende ein 
zeiger.

Walter Tarpan schrieb:
> Hallo zusammen,
> ich frage mich gerade, wie unter C das Nullelement eines struct
> aussieht.

Was meinst du mit "das Nullelement eines Struct"? Ein struct besteht aus 
mehreren Variablen, von denen jedes je nach Typ 0 sein kann oder auch 
nicht.

> Ich habe eine Funktion, die in etwa so aufgebaut ist:
> typedef struct{ ...   } Objdata_t;
>
> Objdata_t Objinit(Objinittype_t Init)
> {
>     Objdata_t obj;
>
>     [...]
>
>     return obj;
>
>     error:
>     return NULL; // geht das?

Nein. NULL ist für Zeiger vorgesehen, um anzugeben, daß ein Zeiger keine 
gültige Objekt-Adresse enthält. Ein Struct enthält aber keine Adresse.

> }
>
> und ich würde in der aufrufenden Funktion gern prüfen, ob die
> Initialisierung fehlgeschlagen ist, etwa so[...]
> Objdat = Objinit(Init);
> if(Objdat==NULL) goto error;
> [...]
>
> Geht das so? Laut C-Standard kann man structs ja nicht vergleichen.

Wenn du deine Objekte irgendwie als "ungültig" markieren und später 
erkennen können willst, mußt du dir selber eine Methode dafür überlegen.

Peter II schrieb:
> warum denn nicht?

Weil ich mich mit dem Hinweis auf die Pointerrückgabe selbst verwirrt 
hatte. :-)

Rufus Τ. Firefly schrieb:
> Ineffizient ist es, weil bei einer Strukturzuweisung die komplette
> Struktur [...] gleich zweimal kopiert [wird], einerseits
> bei der Übergabe via return (da wird die lokale Struktur auf den Stack
> kopiert (auch wenn sie als automatische Variable eh' schon auf dem Stack
> lieg) und andererseits bei der Zuweisung an "Objdat" als Rückgabewert
> der Funktion (da wird sie vom Stack wiederum in Objdat kopiert).

Danke für die Info. Effizienz ist mir hier nicht so wichtig, weil Init 
über die gesamte Programmlaufzeit ohnehin nur wenige Male aufgerufen 
wird, aber es ist gut, das im Hinterkopf zu behalten.

Ich will keinen Zeiger auf ein struct haben- denn dann müßte ich das 
Struct schon vor dem Aufruf von Init übergeben. Oder eine dynamische 
Speicherverwaltung in Objinit() einbauen. Das macht keinen Spaß.

Aber dann muß ich in Objdata_t eben einen Marker einbauen, der es als 
gültig oder ungültig markiert. Geht auch.

Danke für die Diskussion!

Udo Schmitt schrieb:
> Wobei das als Zeiger so aber auch nicht funktionieren würde, weil der
> Zeiger auf eine lokale Variable zeigt, die auf dem Stack liegt und bei
> Verlassen der Funktion nicht mehr gültig ist.

das man dann die stuct mit new anlegen musst, sollte eigentlich klar 
sein.

Rufus Τ. Firefly schrieb:
> Fred schrieb:
>> Und dein return obj; "funktioniert" zwar insofern, als der Compiler es
>> übersetzt, es macht aber nicht das, was du sillst und ist ein grober
>> Schnitzer.
>
> Nein. Es ist nicht sonderlich performant, aber es funktioniert im Sinne
> des Erfinders.

Wenn der Compiler einigermaßen modern ist und "return value optimization 
(1)" kann, wird da gar nichts kopiert, und es ist die effizienteste Art, 
die Struktur rauszugeben.
Wenn er das nicht kann, hängt es letztendlich von der Größe der struct 
ab und davon, welche Alternative man wählt. Wenn man nämlich in der 
Funktion die struct dynamisch allokiert und später wieder freigeben muß, 
ist die Kopiererei wahrscheinlich effizienter, sofern die Struktur nicht 
allzu riesig ist.

> Ineffizient ist es, weil bei einer Strukturzuweisung die komplette
> Struktur kopiert wird; hier wird sie gleich zweimal kopiert, einerseits
> bei der Übergabe via return (da wird die lokale Struktur auf den Stack
> kopiert (auch wenn sie als automatische Variable eh' schon auf dem Stack
> lieg) und andererseits bei der Zuweisung an "Objdat" als Rückgabewert
> der Funktion (da wird sie vom Stack wiederum in Objdat kopiert).

Aber nur bei einem schlechten Compiler, denn beides kann heutzutage 
problemlos wegoptimiert werden.

(1) http://en.wikipedia.org/wiki/Return_value_optimization

Hier bietet sich wirklich Übergabe als Zeiger oder Refenz an.

1

obj Objdata_t;

2

3

if( !Objinit(obj) ) goto error;

Udo Schmitt schrieb:
> Schön, und was hilft das jetzt dem Programmierer mit seinem C Problem?

Akut nicht viel, aber das ist hier ja auch keine 1:1-Kommunikation.

> Rust ist so eine tolle Sprache, daß als erste Treffer in google
> "Europapark" erscheint.

Und bei "Go" erscheint ein Expreß-Kurier, und dann schließlich auf Platz 
zwei das Brettspiel.

Zu "C" kommt zuoberst ein Chart der Citigroup-Aktie.

Deine Bewertungsmethodik für Relevanz ist durchaus verbesserungsfähig.

Und dein Gefühl, wann du etwas zu einer Diskussion beiträgst, ebenso.

Udo Schmitt schrieb:
> Gut, dann zeige die vielen tausend Stück Software die damit schon
> erfolgreich geschrieben und verkauft wurden, oder die Firmen, die die
> Sprache einsetzen, oder die offenen Stellen am Arbeitsmarkt, die diese
> Programmiersprache fordern.

Ich wiederhole mich:
>> Deine Bewertungsmethodik für Relevanz ist durchaus verbesserungsfähig.

Peter II schrieb:
> Hier bietet sich wirklich Übergabe als Zeiger oder Refenz an.
> obj Objdata_t;
>
> if( !Objinit(obj) ) goto error;

Objinit mit Rückgabewert für SUCCESS und FAIL ausstatten. Ist auch eine 
Überlegung wert.

Udo Schmitt schrieb:
> deine ist wohl: "ich mag das also ist es relevant" :-)

Nein, meine ist "es wird vermutlich einige Leute interessieren".

Es gibt hier durchaus Leser, die nicht alles in industrieller Verwendung 
messen. Angeblich sogar Hobbyisten. Gerüchtehalber gar Leute, die sogar 
Basic einsetzen. :-)

Udo Schmitt schrieb:
> Ok, das lass ich gerne auch gelten. Ich habe wohl deinen Post dazu
> missverstanden. Klang für mich nach "Rust ist vel besser, also wechsle
> dazu" und war wohl eher gemeint als "Übrigens da gibts Rust, kann man
> sich bei Interesse mal anschauen".
> :-)

Genau so. Schön, dann ist ja alles gut. :-)

zu "Rust" als Programmiersprache gibt es nicht mal einen 
deutschsprachigen Wikipedia Eintrag. Das sollte genug drüber aussagen, 
wie relevant diese Sprache ist.

Professionel uninteressant, und für Hobbyisten wohl auch. Denn als 
Hobbyist ist ein wichtiges Bewertungskriterium: wieviele Infos finde ich 
darüber im Netz?

Ist ja schön und gut dass es für jedes Problem ein eigenes Werkzeug gibt 
und man nicht immer die C oder C++ Brechstange rausholen muss. Aber 
solche Insellösungen wie Rust sind dann auch nicht erstrebenswert.

Sorry, mir war fad.

Udo Schmitt schrieb:
> Rolf Magnus schrieb:
>> Wenn der Compiler einigermaßen modern ist und "return value optimization
>> (1)" kann, wird da gar nichts kopiert, und es ist die effizienteste Art,
>> die Struktur rauszugeben.
>
> Effizienter wäre trotzdem noch der Call by Reference, also über einen
> Pointer, oder optimiert der Compiler hier derart, daß Änderungen in der
> Funktion direkt in der Zielstruktur (die ausserhalb definiert ist)
> gemacht werden?

Ja, genau das ist ja die Idee hinter dieser Optimierung.

Wegstaben Verbuchsler schrieb:
> oder, noch schlimmer: GOTO in C-Programmen! ;-)

läßt sich steigern: int anstelle int16_t oder char anstelle uint8_t und 
so weiter. Das geradezu teuflische an goto ist, daß es fest im 
Grundwortschatz von C enthalten ist ;-)

Die Skale der erreichbaren Unleserlichkeit bei C ist wie die 
Richterskale: nach oben offen..

W.S.

So ist das ja auch gedacht. Exakte größen braucht man außer für 
Memory-Mapped-Register nur zur Kommunikation nach außen (Binäre Files & 
Übertragungsprotokolle).