Frage zu implementierung in C

[Michael (Gast)]

Einen schönen guten morgen,

ich habe hier einen Code, den ich weiter bearbeiten muss. An für sich 
läuft es auch ganz gut. Ich habe aber mal eine Frage warum etwas 
implementiert worden ist, wie es ist:

file1.h

const timeParameter_ts * getTimeParameter_ps(void);

file1.c

static timeParameter_ts timeParameter_s;
static const timeParameter_ts* const timeParameter_ps = &timeParameter_s;

const timeParameter_ts* getTimeParameter_ps(void)
{
  return timeParameter_ps;
}

die Funktion getTimeParameter_ps kann dann von anderen files aufgerufen 
werden.
Meine Frage ist warum man nochmal einen pointer auf die Lokale variable 
macht.
Warum gibt man in der getter-funktion nicht einfach timeParameter_s 
zurück?

Ist das nur wegen dem const? warum macht man dann diese Funktion 
überhaupt const?

[Rolf M. (rmagnus)]

Michael schrieb:
> Meine Frage ist warum man nochmal einen pointer auf die Lokale variable
> macht.

Ich sehe keinen Grund dafür.

> Warum gibt man in der getter-funktion nicht einfach timeParameter_s
> zurück?

Ich hätte es so gemacht.

Was hier zusätzlich noch verwunderlich ist, ist, dass in der Funktion 
das const vom Pointer-Ziel wieder implizit entfernt wird. Ich würde da 
eine Compiler-Warnung erwarten.

[NichtWichtig (Gast)]

Sicherheit.
Man kann den Inhalt ermitteln aber nicht seinen Wert ändern.

[g457 (Gast)]

> Meine Frage ist warum man nochmal einen pointer auf die Lokale variable
> macht.

Bequemlichkeit. Wird wahrscheinlich auch an anderer Stelle für 
nur-lesenden Zugriff genutzt.

> Warum gibt man in der getter-funktion nicht einfach timeParameter_s
> zurück?

Falscher Datentyp (oder, falls Du den Rückgabetyp adäquat anpasst, 
unnötiges Rumkopieren).

> Ist das nur wegen dem const?

Nein.

> warum macht man dann diese Funktion überhaupt const?

Die Funktion ist nicht const.

[cppbert3 (Gast)]

Michael schrieb:
> warum macht man dann diese Funktion überhaupt const?

der rückgabewert ist const, nicht die funktion - was auch gar nicht geht

[Rolf M. (rmagnus)]

g457 schrieb:
>> Warum gibt man in der getter-funktion nicht einfach timeParameter_s
>> zurück?
>
> Falscher Datentyp (oder, falls Du den Rückgabetyp adäquat anpasst,
> unnötiges Rumkopieren).

Man müsste ja nur den Adress-Operator verwenden. Dann ist der Datentyp 
nicht falsch, und es muss auch nix zustäzlich rumkopiert werden.

    return &timeParameter_s;

PS:

Das ist natürlich Blödsinn:

Rolf M. schrieb:
> Was hier zusätzlich noch verwunderlich ist, ist, dass in der Funktion
> das const vom Pointer-Ziel wieder implizit entfernt wird. Ich würde da
> eine Compiler-Warnung erwarten.

Bitte ignorieren. Da war ich wohl noch nicht ganz wach.

[g457 (Gast)]

>>> Warum gibt man in der getter-funktion nicht einfach timeParameter_s
>>> zurück?
>>
>> Falscher Datentyp (oder, falls Du den Rückgabetyp adäquat anpasst,
>> unnötiges Rumkopieren).
>
> Man müsste ja nur den Adress-Operator verwenden. Dann ist der Datentyp
> nicht falsch, und es muss auch nix zustäzlich rumkopiert werden.

Dann gibt er aber nicht timeParameter_s zurück wie in der Frage 
geschrieben, sondern dessen Adresse. Das ist ein Unterschied.

[Yalu X. (yalu) (Moderator)]

Es sollten wohl die folgenden drei Forderungen (von denen die ersten
beiden bereits genannt wurden) erfüllt werden:

1. Aus fremden Übersetzungseinheiten soll auf timeParameter_s nur lesend
   zugegriffen werden können.

2. Es sollen Kopieraktionen des Inhalts von timeParameter_s vermieden
   werden.

3. Der Aufrufer von getTimeParameter_ps soll über den zurückgelieferten
   Pointer weiterhin Änderungen in timeParameter_s mitbekommen, ohne die
   Funktion erneut aufrufen zu müssen.

Dies hätte man auch auf einfachere Weise erreicht, indem man sowohl die
Funktion getTimeParameter_ps als auch das "static" in der Deklaration
von timeParameter_ps weggelassen hätte.

[A. S. (Gast)]

Michael schrieb:
> Ich habe aber mal eine Frage warum etwas
> implementiert worden ist, wie es ist:

Der Codeausschnitt selber liefert noch keinen Grund für die Komplexität.

Vermutlich hat er sich durch die Vermischung mehrere Paradigmen ergeben, 
vielleicht sogar schon in Programmierrichtlinen gegossen oder um des 
lieben Frieden willens angewendet.


Oder es blieb nach einer Refakturierung übrig weil der Refakturierer 
erstmal erschöft war.