3. Warum soviele Strings?

Warum soviele Strings?

  • ?

    Verwende die CComBSTR-Klasse. Die hat entsprechende Konstruktoren

    0
  • P

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

    0
  • ?

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

    0
  • P

    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);
    0
  • ?

    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 😉

    0
  • A

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

    0
  • P

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

    0
  • A

    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é

    0
  • A

    Die ATL zu benutzen ist nicht schlecht. Wenn jemand ActiveX-Komponenten in C++ enwickelt, und ATL dafür benutzt, ist das sogar sehr schlau. Weil einfacher geht es nicht. 😉 Über die WTL kann man aber streiten. Da tut es meiner Meinung nach die MFC dann besser. Außerdem ist die Frage, wie alt denn die Projekte schon sind, an denen du bastelst? Habe hier noch Kollegen die proggen in COBOL. Wird hier auch nie aussterben in der Firma. IBM hält wegen uns das eigentlich schon tot sein müssende CICS am Leben... 😃

    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.

    0
  • P

    C# mit .NET habe ich schon genutzt. Der Umstieg ging sehr schnell von Java. Nach ca. 1-2 Wochen war ich schon recht fix und nach dieser Zeit deutlich effektiver als jetzt nach 3-4 Monaten in C++ ;-). C# ist halt Java sehr nahe nach meiner Erfahrung.

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

    0
  • T

    Artchi schrieb:

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

    0
  • K

    plizer schrieb:

    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.

    0
Anmelden zum Antworten