Ich quäle mich zur Zeit mit der Frage, welche Variante sinnvoller ist, ein String als Parameter an eine Methode zu übergeben.

Angenommen, man möchte Attribute von Objekten setzten, wie z.B. ein Pfad zu einer Datei etc., so könnte man folgende Varianten verwenden (ich benutze mal die UNICODE-Varianten):

class Config{

public:

    Config();
    ~Config();

    void SetFilename1(LPCWSTR fileName);
    void SetFilename2(const std::wstring& fileName);
    void SetFilename3(const std::wstring fileName);

private:

    std::wstring cfgFileName;
}

void Config::SetFilename1(LPCWSTR fileName){

    cfgFileName = fileName;
}

void Config::SetFilename2(const std::wstring& fileName){

    cfgFileName = fileName;
}

void Config::SetFilename2(const std::wstring fileName){

    cfgFileName = fileName;
}

Welche Variante würdet Ihr nehmen (eine von den obigen oder eine weitere Variante)?

Gruß Roger

void SetFilename2(const std::wstring& fileName);

die da, weil sie keine unnötigen kopien erzeugt.

Grüße
Franz

v1) was ist ein LPCWSTR? (wstring ist glaub ich so ein windows-unicode-string, oder?)

Long Pointer to Constant Wide STRing. elendes windows-geraffel.

franz schrieb:

v1) was ist ein LPCWSTR? (wstring ist glaub ich so ein windows-unicode-string, oder?)

Long Pointer to Constant Wide STRing. elendes windows-geraffel.

Danke, gut zu wissen
Aus dem Namen geht hervor, dass das wohl ein Pointer ist, somit wär das vllt. auch eine Alternative, da bei der Parameterübergabe an die Funktion kein Kopieren statfindet.

somit wär das vllt. auch eine Alternative, da bei der Parameterübergabe an die Funktion kein Kopieren statfindet.

Nur wenn du in der Schnittstelle der Klasse sowieso noch andere Windows-Spezifika einbauen musst, d.h. wenn es sowieso eine Windows-spezifische Klasse ist. Allgemein würde ich wenn möglich die Schnittstellen von Klassen möglichst plattformunabhängig definieren.

Diesen Datentyp trifft man bei der WinAPI so gut wie immer an, wenn es um String-Parameter geht.

@Pumuckl:

Bei meinen Klassen handelt sich um stark WinAPI-bezogene Klassen für Windows-BS. Ich nutze aber intern immer std::wstring. Nun überlege ich auch für die Schnittstellen grundsätzlich auf std::wstring zu setzen. Bisher habe ich es mit LPCWSTR gemacht, was den Nachteil hat, dass man immer wieder auf C-Strings zurückgreifen muss (z.b: per .c_str()).

Die Variante 3 nutze ich dort, wo ich die Option benötige wstrings und const. C-Strings (z.B. SetFilename(L"config.ini");) übergeben zu können.

Die Variante 3 nutze ich dort, wo ich die Option benötige wstrings und const. C-Strings (z.B. SetFilename(L"config.ini");) übergeben zu können.

Wieso das? Const-Referenzen können auch an temporäre Objekte gebunden werden. Übergib doch eine Const-Referenz.

@Nexus: Das musst Du mir nochmal erklären.

funktion 2 funktioniert auch mit c-strings, weil ggf. ein temporäres stringobjekt erzeugt wird.

@Nexus: Das musst Du mir nochmal erklären.

Es gibt eigentlich keinen Grund, Strings (wie std::wstring ) als Kopie zu übergeben. Das einzige wäre, wenn du innerhalb der Funktion sowieso eine Kopie anlegen würdest, und diese veränderst. Dann kannst du gleich eine Kopie übergeben. Sonst nimmst du besser eine Const-Referenz.

Auch wenn du ein Literal an die Funktion übergeben willst, zum Beispiel L"config.ini" , darf der Parameter eine Const-Referenz sein. Normale Referenzen können nur an LValues gebunden werden. Const-Referenzen hingegen darf man auch an RValues (zum Beispiel temporäre Objekte wie das WString-Literal) binden.

funktion 2 funktioniert auch mit c-strings, weil ggf. ein temporäres stringobjekt erzeugt wird.

Das ist das andere. std::wstring besitzt einen nicht expliziten Konstruktor, der einen wchar_t* aufnimmt. Also kann man auch einen wchar_t* übergeben, der wird dann implizit konvertiert.

Im Grunde braucht man damit nur eine Funktion, mit der alle Fälle abgedeckt werden.

Würdet Ihr im Falle der Windows-Programmierung, wo man viel mit LPCSTR/LPCWSTR als Parametertyp zu tun hat und intern mit std::wstring arbeitet, für eigene Schnittstellen die C-String-Zeiger (LPCWSTR) oder C++-String-Referenzen (const std::wstring&)benutzen?

Würdet Ihr im Falle der Windows-Programmierung, wo man viel mit LPCSTR/LPCWSTR als Parametertyp zu tun hat und intern mit std::wstring arbeitet, für eigene Schnittstellen die C-String-Zeiger (LPCWSTR) oder C++-String-Referenzen (const std::wstring&)benutzen?

Wie schon oben gesagt würde ich grundsätzlich plattformunabhängige Schnittstellen bereitstellen. Die einzige Ausnahme ist, wenn du die Schnittstellen der WinAPI übergeben musst, damit diese die Funktionen aufrufen kann. Da die WinAPI aber ein C-API ist wirst du dafür sowieso nicht die Klassenmethoden direkt benutzen können.

Der Vorteil bei plattformunabhängigen Schnittstellen ist folgender: Auch wenn du im Moment die Implementierungen deiner Klassen stark windows-spezifisch machst, kannst du später trotzdem z.B. eine Linuxspezifische Implementierung dazu schreiben, die du dann mit linken kannst, ohne die Schnittstelle selber ändern zu müssen.

Ich denke auch std::strings als const. reference zu benutzen ist auch einfach fehlersicherer. Die LPCWSTR-Zeiger können ja sonst wo hinzeigen (auch NULL sein) und man kann sich nicht sicher sein, dass die Strings auch initialisiert und nullterminiert sind.

Ich denke auch std::strings als const. reference zu benutzen ist auch einfach fehlersicherer. Die LPCWSTR-Zeiger können ja sonst wo hinzeigen (auch NULL sein) und man kann sich nicht sicher sein, dass die Strings auch initialisiert und nullterminiert sind.

Wenn du aber einen wchar_t* übergibst, wird der in einen std::wstring konvertiert - egal, ob er auf einen gültigen Speicherbereich, auf Null oder in ein schwarzes Loch zeigt. std::wstring wird dann die entsprechenden Probleme haben...

Wenn es also möglich ist, Nullzeiger zu übergeben, brauchst du doch eine Funktion, die einen wchar_t* nimmt und diesen prüft. Gegen wilde Zeiger kannst du nicht viel machen, da musst du halt schauen, dass diese nicht vorkommen, was bei guter Programmierung eigentlich im Bereich des Möglichen liegt.

Wenn es also möglich ist, Nullzeiger zu übergeben, brauchst du doch eine Funktion, die einen wchar_t* nimmt und diesen prüft. Gegen wilde Zeiger kannst du nicht viel machen, da musst du halt schauen, dass diese nicht vorkommen, was bei guter Programmierung eigentlich im Bereich des Möglichen liegt.

Das ist eine Frage des Schnittstellendesigns. Tendenziell würde ich die Schnittstelle eher schmal halten, sprich nur std::wstring. Es ist dann Sache des Aufrufers bei eventuell auftretenden wchar_t-Pointern die nötigen Überprüfungen vorzunehmen. Idealerweise sollte eine Schnittstelle nur die nötigen Funktionen bereitstellen und nicht alle möglicherweise irgendwann mal auftretenden Fälle abdecken. In der Praxis macht man natürlich Kompromisse - wenn ein Fall häufig auftaucht, der von der minimalen Schnittstelle nicht abgedeckt wird, dann erweitert man die Schnittstelle unter Umständen entsprechend. Im vorliegenden Fall würde ich aber eher drauf verzichten und lediglich in die Doku der Schnittstelle schreiben, dass die wstrings gewissen Einschränkungen unterliegen (z.B. keine wchar_t-Nullpointer).

Wenn es eher um Schnittstellen für geschlossene Systeme geht (z.B. innerhalb einer Anwendung), dann mache ich nur die nötigsten Schnittstellen. Weil wenn ich was brauche, kann ich die ruck zuck selber hinzufügen.

@all: Und welche Variante bevorzugt ihr für Strings als Rückgabewert?

std::wstring GetFilename();

std::wstring configFile = GetFilename();

bool GetFilename(std::wstring& filename);

std::wstring configFile;
if (!GetFilename(configFile)){ ... }

welchen sinn sollte variante 2 haben?

@all: Und welche Variante bevorzugt ihr für Strings als Rückgabewert?

Kommt drauf an, das ist eine Frage der Fehlerbehandlung. Wenn es "normal" ist, dass kein Filename zurückgegeben werden kann, ist die zweite Version durchaus legitim (oder die erste mit leerem String, um anzuzeigen dass da nix kommt), andernfalls wenn eigentlich immer ein Filename zurückgegeben werden kann, die erste Version und im Notfall eine Exception werfen.

welchen sinn sollte variante 2 haben?

Ich dachte sie wäre (minimal) schneller, da keine Kopie gemacht wird. (Zusätzlich hat man gleich eine kompakte SUCCESS/FAILURE-Behandlungsmöglichkeit.)

Ich dachte sie wäre (minimal) schneller, da keine Kopie gemacht wird. (Zusätzlich hat man gleich eine kompakte SUCCESS/FAILURE-Behandlungsmöglichkeit.)

Unter Laborbedienungen wäre die Variante mit direktem Return vermutlich schneller. In der freien Wildbahn hängt es von zuvielen Faktoren ab...

SUCCESS/FAILURE wird mittels exceptions gelöst. Return Werte sind sowas von letztem jahrhundert...

Bei sowas sollte man nicht versuchen schlauer zu sein als Compiler, wenn es auf Codeverständnis geht.

Weiterhin würde ich bei einem unerwarteten Fehler eine Exception werfen.

Zum Thema Exceptions: Davor habe ich mich bisher immer gedrückt.

Das Prinzip ist mir klar, aber wie werden die in einem Projekt sinnvoll (einheitlich, plausibel etc.) eingesetzt. Mir fehlen da einfach Ansätze für ein Prinzip, eine einheitliches und sinnvolles Verfahren.

Das fängt ja an beim Design von Exceptions, deren Klassifizierung etc...

Daher noch die alte Returnwert-Prüfung zur Fehlerbehandlung.

Wenn es da hilfreiche Links oder Literatur gibt, wäre ich sehr dankbar.

SUCCESS/FAILURE wird mittels exceptions gelöst. Return Werte sind sowas von letztem jahrhundert...

Hmm, Exceptions sind fuer Ausnahmen da. Bei z.B. falschen Nutzereingaben fuer Dateien sollte keine Exception geworfen werden. Auch sollte bei Ressourcemanagement auf Exceptions verzichtet werden. Java/C# gehen da andere Wege als C++. Returnwerte sind also sowas von nicht letztes Jahrhundert.