return of const char * from function

Hi
Ich habe eine Frage bezgl. eines const char * return aus einer Funktion.

Beispiel:

inline const char * myfunc(Foo blubb)
{
//Foo blubb is a enum

switch (blubb)
{
  case: Blubb::Alpha: {return "Alpha";}
  case: Blubb::Bravo: {return "Bravo";}
  default: {return "Unknown";}
}

Wenn "Alpha", "Bravo", "Unknown" ein String waere, waere ich mir sicher, dass es sich hier um einen Pointer return auf eine lokale Variable handelt aber wie Verhaelt es sich mit "kompilierten Strings".
Ist garantiert, dass die Strings so lange das Produkt laeuft immer im gleichen Speicherort liegen?

TyRoXx

Ja, Zeiger auf Literale bleiben immer gültig.

Singender Holzkübel

Hi schrieb:

Ist garantiert, dass die Strings so lange das Produkt laeuft immer im gleichen Speicherort liegen?

Ja. Es ist garantiert, dass String Literale statisch im readonly (sofern das dein System untersützt) Speicher des Programms ruhen, in der Data-Sektion der Binary.

AFAIK

Columbo

Es ist garantiert, dass String Literale statisch im readonly (sofern das dein System untersützt) Speicher des Programms ruhen, in der Data-Sektion der Binary.

Wo ist denn das garantiert? Es ist lediglich garantiert dass Stringliterale static storage duration besitzen.

RHBaum

Hi Hi,

unabhängig davon, was meine Vorredner hier zusichern (ja es würde funktionieren), solltest so eine funktionssignatur zumindest in einem professionellen framework nicht verwenden.

Weil der Anwender sieht nicht, das du Zeiger auf den data segment zurueckliefert.
Also fragt er sich ...
ich hab nen zeiger auf nen speicherbereich bekommen, wo meine gewünschten daten drinnestehen. was mach ich mit dem, wenn ich fertig bin ?
Es löscht sich selbst ? ja wenn denn ? .... etc.
Sowas muesstest alles in ne doku schreiben, die eh kein Anwender vorher liest, sondern erst wenns Probleme gibt ^^

Irgendwann wird dein programm vielleicht mehrsprachig, oder generell die art wie du die strings bekommt ändert sich.
Dann liegen sie nicht mehr im data segment, und müssen plätzlich freigegeben werden. Oder du musst sie selbst bis zum programmende im speicher behalten, obwohl sie nimmer gebraucht werden ....
Also entweder Schnittstelle konstant halten oder Speicherverbrauch minimieren ... beides geht dann nimmer ^^ doofe situation.

Normal sind stringopertionen eh zu unperformant das man an so einer stelle wegen performance auf nen saubereres zukunftssicheres interface verzichten würde.
wenn performance nen Thema, dann würde man an den logischen bereichen eher mit enums arbeiten, und die strings nur zur ausgabe erzeugen ...

für interne zwecke, lohnt es sich wirklich den "switch" in ne eigene funktion zu packen ?

Ciao ...

hustbaer

RHBaum schrieb:

für interne zwecke, lohnt es sich wirklich den "switch" in ne eigene funktion zu packen ?

Er.
Auf jeden Fall.

OK, 5 Zeilen Code, dann 5-10 Zeilen enum-to-string Geswitche, dann nochmal 5 Zeilen Code, das wäre gerade noch OK. Gerade noch. An einer einzigen Stelle. Wenn es mehr als 5-10 Zeilen Geswitche ist ne eigene Funktion machen. Und wenn es an mehr als einer einzigen Stelle gebraucht wird stellt sich die Frage mMn. überhaupt nicht - natürlich packt man das dann in ne eigene Funktion.

Und wenn man lieb ist, dann exportiert man die Funktion auch. Nicht nur der Framework-Entwickler selbst will tracen/loggen, der Anwendungsentwickler auch. Und wenn der dann fertige enum-to-string Funktionen verwenden kann, ist er sicher nicht böse.

Und zu guterletzt: ich sehe das etwas entspannter als du wegen Returntyp. Für ne enum-to-string Funktion ist char const* OK. Gut, string hätte auch hier nen Vorteil, nämlich dass man im default Fall "undefined foo value (123)" o.ä. statt einfach nur "undefined foo value" zurückgeben kann.
Generell bin ich aber deiner Meinung, im Zweifelsfall lieber string verwenden. char const* wirklich nur für Sachen wo garantiert ist dass man ausschliesslich Literals zurückgeben kann, und das auch nach jeder erdenklichen Änderung immer noch so sein wird.