Warum soviele Strings?

plizer

Ich versteh nicht so ganz warum es so viele verschiedene Strings gibt. Gibt es dafür einen speziellen Grund, um damit spezielle Aufgabenstellungen zu bearbeiten? Ich habe sicherlich mit über 10 verschiedenen String-Typen arbeiten müssen, wie z.B.: CString, string, bstr_t, BSTR, LPTSTR, LPTCSTR, LPWSTR, LPSTR, _bstr_t. Manche Methoden liefern LPCSTR zurück, andere brauchen als Parameter BSTR. Man castet die ganze Zeit von einem String zum nächsten! Wo liegt da denn der Sinn?

CStoll

Zu C-Zeiten gab es nur einen String-Typ: 'char*' - bis jemandem auffiel, daß ein char für bestimmte Anwendungen zu klein sein könnte (um deutsche Texte schreiben zu können, reichen 255 Symbole abzüglich einiger Steuerzeichen aus - für chinesische nicht mehr) und 'wchar_t*' ergänzt wurde.
(die ganzen LP...STR Typen sind auch nur andere Namen für verschiedene Variationen von char*/wchar_t*)

Bei der Einführung von C++ kam man dann auf den Trichter, die String-Funktionalität hinter Klassen zu kapseln. Das Ergebnis war dann CString, AnsiString etc. - und recht spät entschied sich das Standardkommitee, eine eigene Klasse std::string in den Standard aufzunehmen.

Es gibt nur einen _wahren_ string

plizer

CStoll: Thx für die prompte Antwort und aufklärende Antwort. Das entsteht wahrs. schnell, wenn eine Sprache schon lange existiert und immer weiterentwickelt wurde bzw. wird... habe gerade die Methode SysAllocString gefunden, vielleicht geht das Umwandeln damit bequemer!

plizer

Welche sinnvollen Methoden gibt es denn sonst noch um Strings umzuwandeln? Ich muss z.B. jetzt einen LPTSTR nach BSTR umwandeln, was mit SysAllocString() leider nicht geht.

Naja, von diesen komischen LPTSTR-Strings etc habe ich eigentlich keine Ahnung, aber falls sie kompatibel zur Sprache sein sollten ( und das sollten sie ), dann haben die sicherlich einen Methode namen c_str() oder ähnlichen, die einem nen stinknormales const char* zurückgibt.

Wenn das der Fall ist, musst du nicht viel umwandeln, da jeder dieser Klassen auch einen Konstruktor für const char* anbieten sollte.

Jedenfalls ist das bei den "richtige" Klassen wie string, AnsiString und CString der Fall, bei den anderen komischen Sachen bin ich mir nicht sicher.

CStoll

KasF schrieb:

Naja, von diesen komischen LPTSTR-Strings etc habe ich eigentlich keine Ahnung, aber falls sie kompatibel zur Sprache sein sollten ( und das sollten sie ), dann haben die sicherlich einen Methode namen c_str() oder ähnlichen, die einem nen stinknormales const char* zurückgibt.

LPTSTR hat keine Methoden - das ist je nach Projekteinstellungen entweder ein char* (ANSI-Projekt) oder ein wchar_t* (UNICODE-Projekt).

@plizer: Was hat es denn für einen Grund, daß du verschiedene Zeichentypen in einen Topf werfen willst?

CStoll schrieb:

LPTSTR hat keine Methoden - das ist je nach Projekteinstellungen entweder ein char* (ANSI-Projekt) oder ein wchar_t* (UNICODE-Projekt).

Jup, habe ich jetzt gerade eben auch endeckt

typedef CHAR TCHAR;

typedef TCHAR TBYTE,*PTCH,*PTBYTE;
typedef TCHAR *LPTCH,*PTSTR,*LPTSTR,*LP,*PTCHAR;

plizer

Ich setze eine DLL ein, die nen BSTR als Übergabeparameter braucht und eine CLIstBox von ATL/WTL, die LPTSTR zurückliefert. Und andere DLLs setzen wiederrum LPTCSTR oder sonst was ein. Das ist echt nervig und ich brauche mehr Zeit zum Casten als für die Algorithmen :(.

plizer

Keiner ne Ahnung wie man von nem LPTSTR nach BSTR kommt?

CStoll

Du könntest einen ausreichend großen leeren BSTR anfordern (keine Ahnung, ob es dafür eine Funktion gibt) und anschließend deinen LPTSTR dort reinkopieren.

Das sollte dir helfen: http://www.codeproject.com/string/bstrsproject1.asp

Verwende die CComBSTR-Klasse. Die hat entsprechende Konstruktoren

plizer

Danke für eure Postings. Hab schon alles versucht. Compilieren tut er ja fast alles, semmelt dann aber immer ab. Was ist das für ne Sprache, wenn man sich Stunden mit so nem Scheiss beschäftigen kann :(.

plizer schrieb:

Danke für eure Postings. Hab schon alles versucht. Compilieren tut er ja fast alles, semmelt dann aber immer ab. Was ist das für ne Sprache, wenn man sich Stunden mit so nem Scheiss beschäftigen kann :(.

Das ist nicht die Sprache schuld. Wenn irgendwelche Hirnies sich irgendwelche komischen Typen einfallen lassen, kann C++ auch nichts dafür. In C++ gibts da nur char* ( und die wide's ) und std::string.

Du machst irgendwas falsch. Zeig deinen Code und sag uns was nicht so läuft, wie es laufen soll ...

plizer

ja, ich gebs ja zu! Aber das ist so frustrierend. Habs jetzt endlich hinbekommen. Danke für eure Hilfe!

Hier poste ich einfach mal die Lösung für mein Problem, vielleicht kann ja jemand nochmal was damit anfangen.

CString s = " ";
m_CListBox2.GetText(i,s.GetBuffer(256)); // WICHTIG: ohne GetBuffer läuft nichts und er stürzt zur Laufzeit ab.
CComBSTR ccBSTR(s);
BSTR b = ccBSTR;
myDLLTool->PutName(0, b);

plizer schrieb:

CString s = " ";
m_CListBox2.GetText(i,s.GetBuffer(256)); // WICHTIG: ohne GetBuffer läuft nichts und er stürzt zur Laufzeit ab.
CComBSTR ccBSTR(s);
BSTR b = ccBSTR;
myDLLTool->PutName(0, b);

Keine Ahnung, ob das die beste Lösung ist, aber pack das jetzt in eine Funktion und erfreue dich jedesmal daran

Artchi

plizer! Diese ganze Schei*** die du anmotzt, ist ja auch sche***!! *zustimm* Aber das sind noch alles Relikte aus C-Zeiten. Und es gibt immer noch Leute (selbst hier im Forum) die den ganze alten C-Kram für Businessanwendungen für das beste halten. Weils anscheinend cool ist.

Echtes C++ macht da weit aus weniger Probleme, weil es sowas garnicht fördert (aber zu lässt).

plizer

@KasF: Da kannste drauf wetten, dass das in eine Methode gepackt wird

@Artchi: Ja das glaub ich Dir! Das merk ich ja schon daran, dass solche Fragen garnicht oft auftauchen. Ich finde es eigentlich unmöglich, dass jemand hier ATL/WTL eingesetzt hat, wenn man doch weiß, dass jemand anderes das auch noch pflegen bzw. erweitern muss! Keiner in der Firma hat ATL/WTL angerührt, nur der Hauptentwickler und jetzt steht hier alles undokumentiert und man kann sich einarbeiten. Ausserdem wurden auch alle DLLs damit entwickelt, so dass dort in unterschiedlichen Methoden immer wieder andere String benötigt werden.

Hab mal ne Frage zu .NET an Dich, da Du ja nicht nur C++ gut kannst.
- Im Grunde kann doch jeder in .NET die Programmiersprache einsetzen wie er will. Allerdings wird ja dann ein Zwischencode erzeugt, der wiederum Geschwindigkeitsnachteile hat. Sind das ähnliche Geschwindigkeitseinbußen wie bei Java?
- Ist es möglich ohne den Zwischencode zu programmieren, so dass man in C++ dann auch die volle Performance hat?
- Wie sieht das Java (ich glaube J++) genau für .NET aus? Das wird ja nicht genau das gleiche wie von Sun sein, oder?
- Hast Du vielleicht nen Link, wo man zu solchen Fragestellungen etwas erklärt bekommt. Find ich echt interessant und ich will vor allem gut informiert sein, wenn es um die Planung der zukünftigen Entwicklungsumgebungen geht!

PS: Sorry, wenn ich manchmal über C++ klage, obwohl es garnichts dafür kann. Nur wird man echt wahnsinnig, wenn man für solche String-Geschichten Stunden verbrät!

asc

Prinzipiell gehören deine Fragen in ein anderes Unterforum...

plizer schrieb:

- Im Grunde kann doch jeder in .NET die Programmiersprache einsetzen wie er will. Allerdings wird ja dann ein Zwischencode erzeugt, der wiederum Geschwindigkeitsnachteile hat. Sind das ähnliche Geschwindigkeitseinbußen wie bei Java?

An sich gibt es extrem viele Sprachen unter .Net, die man auch paralell in einem Projekt einsetzen kann. Nur wird zum einen nicht von jeder Sprache alles gleichweit unterstüzt (es sei den man beschränkt sich auf die Mindestgarantien). Zum anderen kann ich dir hierzu nur eins sagen: Ein Sprachbabylon ist eine schlechte Situation (grade wenn jeder Entwickler meint eine andere zu verwenden), den gepflegt werden muss sie dennoch.

Meine Empfehlung ist sich auf maximal 2 zu beschränken (z.B. weitgehend C# und C++/CLI wo man mit alten C++ Code kommunizieren muss).

plizer schrieb:

- Ist es möglich ohne den Zwischencode zu programmieren, so dass man in C++ dann auch die volle Performance hat?

Jein... Du kannst im Prinzip den Zwischencode in Maschinencode umwandeln. Nur dann ist er auch auf die entsprechende Plattform gebunden.

plizer schrieb:

- Wie sieht das Java (ich glaube J++) genau für .NET aus? Das wird ja nicht genau das gleiche wie von Sun sein, oder?

Die haben Differenzen; Genau habe ich mich mit J++ nicht beschäftigt, da es eher ein Nischendarsein fristet (Imho sollte man dann auch das Original vorziehen).

plizer schrieb:

PS: Sorry, wenn ich manchmal über C++ klage, obwohl es garnichts dafür kann. Nur wird man echt wahnsinnig, wenn man für solche String-Geschichten Stunden verbrät!

Nur liegt das wie gesagt nicht an C++. C++ ist nunmal deutlich älter als .Net und demzufolge gibt es "historisch gewachsene" Überbleibsel.

cu André