double to wchar_t*
-
gleiche Meldung vom Compiler

EDIT:
Ich sollte vielleicht dazusagen dass ich mit wxDev C++ arbeite. Es handelt sich aber nur um eine KonsolenApplikation. Bin ich mit der Fragestellung hier vielleicht falsch?
-
void f() { double d = 0.2; std::basic_ostringstream<wchar_t> oss; oss << d; std::wstring s = oss.str(); const wchar_t* c = s.c_str(); }
-
Wir kommen der Lösung wohl näher, einzige Compiler-Meldung jetzt für die Zeile:
oss << d;
expected constructor, destructor, or type conversion before '<<' token
Wenn ich diese Zeile auskommentiere meckert der compiler nicht, die Funktion
SetString schreibt nun natürlich nichts da der String leer ist.
-
Die Konversion des strings in const wchar_t* funktioniert, habe testweise:
std::wstring s = L"0.2"; const wchar_t* c = s.c_str(); //SetString schreibt "0.2" hr = pOutput->SetString(device, 0, 2, 9, c);Möglicherweise ist es einfacher (double)d in einen String mit Literal L zu konvertieren...
Diese Typkonvertierungen machen mich fertig...
-
Alberich schrieb:
expected constructor, destructor, or type conversion before '<<' token
Vielleicht solltest du dir deine Entwicklungsumgebung noch mal neu aufsetzen. Es kann ja nicht sein, dass du Teile von C++ nicht benutzen kannst und immer drumherum schiffen musst.
-
Kommt mir auch seltsam vor...
Bin jetzt soweit einen string in einen wide-string umwandeln zu können
std::string strc="100"; std::wstring wstrc = std::wstring(strc.begin(), strc.end()); const wchar_t* c = wstrc.c_str();Aber diesem string eine double "mitzugeben" indem ich d in einen string umwandele geht schief...
Sehr seltsam...
-
So, habe den code wie vorgeschlagen jetzt unter Visual C++ 2010.
#include <stdio.h> #include <tchar.h> #include <windows.h> #include <math.h> #include <string> #include <sstream> #include <stdlib.h> ... double d = 0.2; std::basic_ostringstream<wchar_t> oss; oss << d; std::wstring s = oss.str(); const wchar_t* c = s.c_str(); ...Meldung für Zeile
oss << d;Diese Deklaration hat keine Speicherklasse oder keinen Typspezifizierer
Wie kann das sein? Andere Umgebung, gleicher Fehler...
-
Sehr wahrscheinlich liegt es an windows.h. windows.h definiert einen großen Haufen Makros, die sich mit allem möglichen beißen - heiße Kandidaten sind da min() und max().
Wenn du die dadurch ausgeklammerten Teile nicht unbedingt benötigst, kannst du versuchen, windows.h wie folgt einzubinden:
#define WIN32_LEAN_AND_MEAN #define NOMINMAX #include <windows.h> #undef NOMINMAX #undef WIN32_LEAN_AND_MEANHäufig reicht das schon. Falls nicht, oder falls du andere Microsoft-Bibliotheken benutzt, die den Kram brauchen - Teile von MFC kriegen beispielsweise Probleme, wenn die Makros min und max nicht vorhanden sind (wobei sich MFC wieder mit windows.h beißt und sich den Kram wohl an anderer Stelle holt. Das ist alles...äh...historisch gewachsen.) - wirst du den von windows.h abhängigen Code in eine eigene Übersetzungseinheit auslagern und so einpacken müssen, dass du ihn an anderer Stelle im Programm unabhängig davon benutzen kannst.
-
Ok, dann hast du irgendwas in deinem Code (in einem der Includes oder einfach weiter oben), was die Funktionalität zerhaut.
Die windows.h dürfte es aber eigentlich nicht sein, benutze ich öfters mit allen möglichen Std-Lib-Sachen.
-
Versuch mal
#include <windows.h> #include <limits> // std::numeric_limits<>::min() bzw. max()Wahlweise <algorithm> (std::min, std::max), und compilerabhängig kann das mit anderen Standardheadern auch Probleme geben (Standardheader dürfen sich beliebig gegenseitig einbinden).
Siehe dazu auch http://support.microsoft.com/kb/143208/en-us
-
Welche MinGW-Version hast du denn? Denn die offizielle Version (3.irgendwas) kann keine Wide-Streams!

Du mußt den ewigen Beta von MinGW 4.irgendwas nehmen. Oder am besten gleich den MS C++ Compiler.
-
Vielen Dank für die Vorschläge!
Ich habe wxDev C++ (7.3.1.3) nochmal komplett neu aufgesetzt, jetzt gibts keine Probleme mehr, auch nicht mit inkludierter windows.h. Keine Ahnung was da schiefgegangen ist...
Nochmal vielen Dank, ist ein super Forum!
-
Als Entwicklungsumgebung ist Visual Studio unter Windows auch keine schlechte Wahl.