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.

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.

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?

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;

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 ...

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);

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

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

@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!

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é

zu .NET:

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?

Ja, es gibt für die .NET-Plattform mehrere Sprachen, z.B. C#, Ruby, Python, VisualBasic und natürlich C++/CLI.
Die Performance dürfte sich auf dem Level von der Java Plattform bewegen. Ich hatte schon mal einen Performancetest gemacht: Java vs. C# vs. C++. Also, das war auf Arbeit eher Spaß, weil wir drei Fan-Fraktionen waren. Das C++-Programm hat mit ca. 4 Sekunden, ggü. den Java und C# mit 19 Sek. gewonnen. Komischerweise hat sowohl Java 1.5 als C# auf .NET 1.1 genau 19 Sek. gebraucht. Auch wenn jetzt die Javaner sturm laufen werden... Wer Performance über alles will, muß halt C++ oder eine andere Sprache nehmen, die echten Maschinencode erzeugt. Sonst würde die Games-Indutrie schon lange von C++ weg sein.

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

Wenn du keinen Zwischencode hast, hast du ja auch keine VM mehr und somit kein .NET oder kein Java. Deshalb verstehe ich die Frage nicht so ganz. Willst du C++/CLI machen? Da kannst du natürlich sagen: "Den Teil der Performance braucht, mach ich in nativen C++, und den Rest in C# oder C++/CLI." Du kannst sogar C++ und C++/CLI innerhalb einer Programmzeile mixen. Das ist hammer genial, kann aber einen ungeübenten C++ler verwirren.

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

Habe J# (oder J++?) noch nie benutzt. Aber meines Wissens ist es ja nur die Sprache Java, die Library ist natürlich weiterhin .NET. J# würde ich nicht machen, würde ich lieber C# lernen.

- 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!

Geh doch einfach mal auf die http://www.msdn.com/ da gibts unmengen an Beiträgen zu .NET, C# und C++/CLI. Im Magazin-Forum haben wir meines Wissens auch noch einen .NET-Artikel.

Noch als Hinweis: du kannst .NET-PRogramme eigentlich sogar unter Linux laufen lassen: http://www.go-mono.com Muß man aber schauen, was man machen will.

Der Vorteil von Java-Programmierern wäre ja die bereits bekannte Bibliothek. Da würde ich dann auch lieber C# statt J# (so heisst es richtig) nehmen. Ein wichtiger Vorteil von .NET wäre sich der Einsatz von bereits entwickelten activeX-Elementen.

Werd mich mal bei den genannten Links umschauen, thx!

IBM hält wegen uns das eigentlich schon tot sein müssende CICS am Leben...

Nicht nur wegen euch hält IBM CICS am leben. Auch bei uns wird das verwendet.

Allerdings wird ja dann ein Zwischencode erzeugt, der wiederum Geschwindigkeitsnachteile hat.

Das ist so einfach falsch. Wie hier mehrheitlich gesagt worden ist, *ist* .NET zwar langsamer als z.B. reines C++ (je nachdem, was man macht). Mit dem Zwischencode hat das aber nichts zu tun. Das Overhead durch die Just-in-time-Kompilierung kann man bei solchen Vergleichen nicht mitzählen, zumal es ja die Möglichkeit der Vorkompilierung und des Caching im GAC gibt. Man kann sehr gut argumentieren, dass der Zwischencode die Ausführung sogar schneller macht, da er eine maschinenspezifische Optimierung des Codes erlaubt.

Die Geschwindigkeitseinbußen von .NET resultieren vielmehr darin, dass hier eben Referenztypen für Klassen verwendet werden, dass über alle Maßen viele virtuelle Funktionen eingesetzt werden, dass generell jede Menge hin und her gecastet wird und dass große Teile des Frameworks einfach nur lahm sind. Das .NET-Framework und die CLI sind eben, im Gegensatz zu C++, nicht mit Hinblick auf die Geschwindigkeit designed worden.