Problem

[ChrisM]

Hi,

sorry wegen dem Betreff, mir ist nix besseres eingefallen

Also, ich hab ja immer noch meine Klasse String (ehemals CString ) und die ist auch immer noch von std::string abgeleitet, weil mir das Schreiben einer eigenen Stringklasse doch viel zu viel Aufwand war (ich hab mir jetzt vorgenommen, keine Datenmember in String hinzuzufügen, deswegen macht es nix, wenn der std::string Destruktor nicht virtuell ist und deswegen meiner evtl. nicht aufgerufen wird).

Meine Stringklasse hat folgende Methode (ruft intern einfach c_str() der Basisklasse auf):

AGEAPI operator const char*(void) const;

Die Methode funktioniert auch überall einwandfrei und ich schreibe kein c_str() mehr, nur hier nicht:

hSearch = ::FindFirstFile(m_strPath + "*.*", &FindData)  // m_strPath ist eine String-Instanz!

FindFirstFile ist eine Funktion der WinAPI, der erste Parameter ist ein LPCTSTR, also ein Zeiger auf einen nullteminierten konstanten C-String.

Aber der Code oben kompiliert nicht:

error C2664: 'FindFirstFileA' : Konvertierung des Parameters 1 von 'class std::basic_string<char,struct std:
:char_traits<char>,class std::allocator<char> >' in 'const char *' nicht moeglich
Kein benutzerdefinierter Konvertierungsoperator verfuegbar, der diese Konvertierung durchfuehren kann, oder der Operator kann nicht aufgerufen werden

Der Abschnitt, den ich nicht kapiere, hab ich schon fett gemacht

ChrisM

PS: Das hier geht!

hSearch = ::FindFirstFile((m_strPath + "*.*").c_str(), &FindData)

[KPC]

Ich bin mir nicht sicher, aber ich glaube es dürfen intern nicht mehr als eine Typumwandlung gemacht werden, das wäre bei dir

1. einen neuen CString erzeugen der das "." am Ende hat
und dann 2. (was er der Compiler nicht mehr darf) den operator() aufzurufen, was dann logischerweise scheitert!

[HumeSikkins]

ich hab mir jetzt vorgenommen, keine Datenmember in String hinzuzufügen, deswegen macht es nix, wenn der std::string Destruktor nicht virtuell ist und deswegen meiner evtl. nicht aufgerufen wird

Es macht was. Egal ob mit oder ohne Datenmember, es bleibt undefiniertes Verhalten. Warum machst du dir soviel Mühe mit einer halben/unsauberen Lösun, wenn eine ordentliche/saubere Lösung leichter zu erreichen ist.

Ich bin mir nicht sicher, aber ich glaube es dürfen intern nicht mehr als eine Typumwandlung gemacht werden

Nicht ganz. Es darf nicht mehr als eine *benutzerdefinierte* Konnvertierung durchgeführt werden.

Das ist hier aber nicht das Problem. Das Problem ist schlicht und einfach, dass std::string (das Ergebnis von m_strPath + ".") *keine* inplizite Konvertierung nach const char* anbietet.

Überlädst du den op+ für den neuen Stringtyp klappt's auch mit dem Aufruf.

[ChrisM]

Wird gleich getestet, das erscheint mir logisch. Danke!

Warum machst du dir soviel Mühe mit einer halben/unsauberen Lösun, wenn eine ordentliche/saubere Lösung leichter zu erreichen ist.

Also, für mich ist es definitiv nicht leicht, eine eigene Stringklasse zu programmieren. Zusammensetzen von Strings usw. ist ja nicht das Problem (einfache memcpy()s von char[]), aber wenns dann darum geht, möglichst intelligent Speicher zu allokieren, damit nicht bei jedem angehängten Buchstaben gleich new aufgerufen werden muss, ist das für mich keine einfache Lösung.
Von möglichen Bugs, für die ich dann wieder euch nerven müsste, mal ganz zu schweigen...

ChrisM

[fifs]

Also, für mich ist es definitiv nicht leicht, eine eigene Stringklasse zu programmieren.

Das hat HumeSikkins auch sicher nicht gemeint.

[HumeSikkins]

Das hat HumeSikkins auch sicher nicht gemeint

Ganz gewiss nicht

@ChrisM
Zwichen öffentlicher Vererbung und alles neu schreiben exitsieren mehrere schöne Mittelwege.

[ChrisM]

Und die wären? Privat vererben und alles kapseln oder HasA-Beziehung? In beidem seh ich hier keinen Sinn...

ChrisM

[Gerard]

privat erben und mit using die methoden die gleich bleiben reinhollen oder?