by what I read in some posts here I came to understand that I cannot use wide streams like
wstringstream, wostringstream, etc with MingW, is that true.
If so, what's the best solution for that?
use another compiler?
if so, which one gives support to that?
I wonder what you think of Digital Mars compiler for Windows that I heard it is free and very conformant.
the thing is I wonder if it is a good thing to change compiler as soon as one meets with the first hurdle and whether would be too hard to change my dev-c++ environment to use the new compiler.
please, I'd appreciate some enlightenment here ;)
is there an alternative still using mingw without having to define my own wide char traits?
do you find the task of doing that a fine one or a desperate measure? :)
thanks for your suggestions in advance :)
(please: tell me that I'm mistaken and that mingw does support wide streams :) and then tell me what header I'm missing :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-08-17
>> ...by using TCHAR. that seems to be standard C and work fine.
It is standard Win32 API not standard C.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-08-10
Whatever you are doing, be aware that Windows console apps cannot display wide characters.
Visual C++ 2005 supports is wstringstream etc. There is a free Express Edition. Frankly teh IDE and debugger are better that Dev-C++, but if you are married to Dev-C++ you would need to switch to teh derivitive wxDev-C++ which apparently now supports VC++ toolchain as a back-end.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well, I'm not really willing to send wide characters to the console window. Not that I'm married to it. I've been using it for just a while and so far so good. I like the idea that it is not visual. at least at this stage of my learning when I want to understand the way things happen in Windows though I might eventually move to a visual tool if I feel appropriate. what's the difference between this free Express Edition to the standard version? Isn't it a too small subset of the real thing?
any more comments about your developing experiences with wide characters together with streams and your way to deal with it? does anyone here keeps with dev and works with wide streams by any means?
I was wondering if it would be a too huge effort to create new traits myself for the wchar_t template versions of the basic streams. I think this might solve the problem. But even if I do so, I wonder if that would be the sensible thing to do since it would me a private implementation of it and not the standard one available in some compilers.
Any new insights are welcome. Thank you very much for yours Clifford. ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-08-11
>>Isn't it a too small subset of the real thing?
Ha! It depends what you want I guess, but it is certainly a superset of Dev-C++'s functionality!
The Express Edition of VC++ will do at least as much as Dev-C++ and a lot more. As far as support for standard C++ is concerned it is not cut-down at all - it is the peripheral tools that are restricted. What it does not have is all the corporate/enterprise development stuff and legacy support for MFC - you don't get that with Dev-C++ in any case. Out of the box it does not have legacy support for Win32 either, but on the IDE start page there is a link with clear instructions for downloading and installing the PSDK to support that. As an ISO C++ compiler it is very good. In addition it supports C++/CLI extensions, the .NET Framework and Windows Forms - but to be honest if these last technologies interest you, use C# (there's an express edition for that too). Note that in C# (and .NET in general) all characters are wide (even if teh console fails to display those outside the ANSI or local code-page set).
One problem with it is that it does not come with an install/deployment tool (neither does Dev), and to deploy native Win32 apps on machines without VC++ installed you will need to download vcredist_x86.exe which is an installer for the runtime library DLLs needed by VC++2005 apps. Running CLI code (which can be pure ISO code but compiled to the CLI), you need the .NET framework installed on machines you'll deploy on. The older C runtime used by Dev-C++ (or rather MinGW) is already installed as part of Windows. If you used C#EE however, it does support deployment packaging.
The big plus of VC++EE is that it comes with a best in class debugger. Unlike Dev-C++'s dismal effort.
>> any more comments about your developing experiences with wide characters[...]?
Ha again! I am an embedded systems developer, my experience with wide characters is minimal. This is perhaps the blind leading the blind. What I know I know from researching answers for other people. To be honest it takes some getting your head around.
>> I was wondering if it would be a too huge effort to create new traits myself for the wchar_t
In the header file <iosfwd> it is a single line! Unfortunately it is disabled by conditional compilation. I am not sure where simply enabling it or copying the line to your own code would really work - I assume it is disabled for a reason, just because the header supports it, does not mean the library will. The underlying C runtime (MSVCRT.DLL) supports wide character functions (even wprintf) but as I said the console is determinedly 8bit.
>> it would me a private implementation of it and not the standard one available in some compilers.
So use a different name or namespace and use your code everywhere rather than the standard. Nothing wrong wuith that if you have this source code and it is portable.
Soma might be able to add some clarity to this, it sounds like the kind of voodoo he'd have got his head around. I think you say his name three times and he'll appear. ;-)
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
big wonder Clifford.
just found this by having a look at that file header you've just named <iosfwd>.
I went there and found: #ifdef _GLIBCXX_USE_WCHAR_T what led me to follow where I could find
_GLIBCXX_USE_WCHAR_T what led me to many header files that seem to define all we need for wstringstream support and I found this file C++configure.h with this line:
// Define if code specialized for wchar_t should be used.
/ #undef _GLIBCXX_USE_WCHAR_T /
if you have a close look at it, it is not defined nor undefined there since it is commented and there is even a message: Define if code specialized for wchar_t should be used.
so what?
does this mean that I may define that in my application and everything's gonna be fine and I'll be happy. I hope so. I guess I'll give it a try and let you know if something good came out of it.
Thanks in advance for the hint that made me find that. I was starting to think of upgrading my mingW installation (even with only a flimsy hope that it would be of any avail) but now I'll give this a shot first.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
sorry, I guess I had gotten everything wrong lol
first, you'r right, it does hides support for some wide character things: cout, cerr, ...
second, I was thinking, from the beginning, it didn't support any wstringstream feature.
I guess this is why in the answers I got always that thing about console window and my answering that I didn't intend to send to the console what I really don't.
but I couldn't even figure out a way to use
wostringstream oss;
oss << L"I need some help here" :)
because the compiler would not recognize that
now, though
by defining _GLIBCXX_USE_WSTRING like this:
define _GLIBCXX_USE_WSTRING 1
the same way they define _GLIBCXX_USE_WSTRING somewhere :)
it seems I manage to make the wostringstream available.
thank you so much for leading me to this find. at least it was a find for me :)
I'm so happy now. If I'm not hugely mistaken, now I'll be able to play with it a bit longer till the next big hurdle at least :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
using std::wcout;
using std::wcin;
using std::wcerr;
using std::wclog;
endif
provided that you define the flag with value 1 because of the wostringstream thing
by the by: I could not find the name "wostringstream" in the files inside any of the folders even though now the compiler accepts it. I wonder where in the computer they are stored.
:P
hidden files?
system files?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This isn't true for many installations of many versions of Windows. It requires a bit of tooling around with default console font and font page. As always, google is your friend.
"I was [...] of the basic streams."
That will not work with the libstdc++ version I am familiar with... the logic is problematic elsewhere.
"I wonder [...] in some compilers."
Well, as only defining a new trait will not work for what you need it would be a small waste of effort. You would learn a lot... so do it anyway.
"I think [...] appear."
Nope. I need more foreplay.
"Does this [...] I'll be happy."
Don't do that. The headers have been specialized as part of MGW by AutoTools. Something is missing, but with intent. The problem is with libstdc++ as usually built for MGW, but not with libstdc++ or MGW.
"I wonder [...] they are stored."
Files without an extension which are not searched for by most people. How are you searching?
For the record, what your using will almost certainly not be actually working. Write a small test to check the stored result byte by byte against what you know the contents should be.
Also, it is simple to write any Unicode character to the console with the right font and the right codepage using the Windows API. I blame the ISO standard for not defining more locales.
Soma
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-08-11
>> I wonder where in the computer they are stored.
Uh? <iosfwd> - you were looking at it!
As I suggested (perhaps vaguely) the library to which the header pertains will probably have been compiled without _GLIBCXX_USE_WCHAR_T. By changing the header you may be exposing features that don't exist or are not supported by the library.
That said, most of libstdc++ is presented as template code in the headers rather than in the library archive file as such so it may I suppose work, but if Soma doubts it so do I. Accepting and compiling is not the same as supporting and working.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well, time for some feedback here.
just read what you both wrote and got a bit saddened now :)
I started some conversion. things even seem working.
I don't care for sending character to the DOS console window if this is what you mean now and again. But my intention was too make changes in my programs so that:
1. everywhere where I previously used char or char would become wchar_t or wchar_t by using TCHAR. that seems to be standard C and work fine.
2. create a tstring like function for stringstreams and other streams by declaring inside a class: typedef std:ostringstream<TCHAR> tstringstream
and I would do the same to all stream types I would need. I even did that for ostringstream already and my Unicodeclass defines some functions according to the state of UNICODE/_UNICODE is defined or not.
As you say: don't do that :) I'd ask. What would you advise? work with char inside every stream I use and use the C functions to convert between multibyte and wide character functions only when I'm to pass the string to windows function calls?
It may sound plausible but a bit farther away from the desirable thing, isn't it?
even with some lack of information in the conversion. While conversion from char to wchar_t is theoretically lossless the other way round seems to imply in something far from ideal.
:)
Yeah, you'r right slocombe. it is there in <iosfwd>. I had even the impression I had seen it. Weirdly enough windows couldn't find it when I made a search with the word: owstringstream. Some optmization of its search engine may have left it out. :(
Thank you all and I'll try and make a test to see what is coming out of the stringstreams. I wonder if the results are right I should feel more comfortable to use it though :) now that I've heard from you :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did that thing. I mean, I tried to use the wide stringstreams by defining _GLIBCXX_USE_WCHAR_T and ...
it compiled beautifully
now I'm getting linkage errors :( every time I try to compile with the option defined and no error otherwise :( (provided that I don't try wide streams but ok for wstring)
I would paste the log here but as it was too big I isolated part of the suspicious thing in a different project and got this smaller set of lines in the log error:
Compiler: Default compiler
Building Makefile: "C:\Dev-Cpp\myownprograms\WinProjectTest\Makefile.win"
Finding dependencies for file: C:\Dev-Cpp\myownprograms\WinProjectTest\main.cpp
Executing make...
make.exe -f "C:\Dev-Cpp\myownprograms\WinProjectTest\Makefile.win" all
g++.exe -c main.cpp -o main.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include"
main.o:main.cpp:(.text+0x155): undefined reference to std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string()'
main.o:main.cpp:(.text+0x272): undefined reference tostd::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_string()'
main.o:main.cpp:(.text+0x389): undefined reference to std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_string()'
main.o:main.cpp:(.text+0x3c7): undefined reference tostd::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_string()'
collect2: ld returned 1 exit status
make.exe: *** [WinProjectTest.exe] Error 1
Execution terminated
the suspect code being:
std::wstring ws1;
for this log just above.
that is, even wstring, that compiles well with the variable undefined, gets this linkage error when _GLIBCXX_USE_WCHAR_T is defined to 1.
the same seems to hold true when I try both:
std::wstring ws1;
std::basic_ostringstream<TCHAR> wo1;
having then, a longer error log as expected:
Compiler: Default compiler
Building Makefile: "C:\Dev-Cpp\myownprograms\WinProjectTest\Makefile.win"
Finding dependencies for file: C:\Dev-Cpp\myownprograms\WinProjectTest\main.cpp
Executing make...
make.exe -f "C:\Dev-Cpp\myownprograms\WinProjectTest\Makefile.win" all
g++.exe -c main.cpp -o main.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include"
main.o:main.cpp:(.text+0x45b): undefined reference to std::basic_ostringstream<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_ostringstream()'
main.o:main.cpp:(.text+0x488): undefined reference tostd::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_string()'
collect2: ld returned 1 exit status
make.exe: *** [WinProjectTest.exe] Error 1
Execution terminated
summary:
_GLIBCXX_USE_WCHAR_T defined to 1 :
wstring compiles
wide streams compile
none of them link
_GLIBCXX_USE_WCHAR_T undefined:
wstring compiles and links
wide streams don't compile let alone link
any suggestios how to use wide streams with mingw???
is there a way?
did I miss something by now I knew before? :P
I'm completely dizzy now after this huge disappointment. I could use some help here :)
all that I want:
wostringstream support in mingw
is this asking too much? :P
does any of the newer versions of mingw comtemplate that properly? does anybody know? how do I check the correct version of my mingw32? is it the same as the name in the path? 3.4.2???
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can get the newest build of STLPort or libstdc++. Both should support most wide character parts of the standard. You could also select any of a dozen higher level libraries that mimic the standard.
"Did I [...] before?"
Apparently you can't read my posts; could you read before?
"Does [...] that properly?"
See above; neither libstdc++ or MGW is broken. It is simply the way that libstdc++ is built with MGW. It is very likely that any newer combination of libstdc++ and MGW you might find will also exhibit broken behavior.
Soma
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
by what I read in some posts here I came to understand that I cannot use wide streams like
wstringstream, wostringstream, etc with MingW, is that true.
If so, what's the best solution for that?
use another compiler?
if so, which one gives support to that?
I wonder what you think of Digital Mars compiler for Windows that I heard it is free and very conformant.
the thing is I wonder if it is a good thing to change compiler as soon as one meets with the first hurdle and whether would be too hard to change my dev-c++ environment to use the new compiler.
please, I'd appreciate some enlightenment here ;)
is there an alternative still using mingw without having to define my own wide char traits?
do you find the task of doing that a fine one or a desperate measure? :)
thanks for your suggestions in advance :)
(please: tell me that I'm mistaken and that mingw does support wide streams :) and then tell me what header I'm missing :)
>> ...by using TCHAR. that seems to be standard C and work fine.
It is standard Win32 API not standard C.
Whatever you are doing, be aware that Windows console apps cannot display wide characters.
Visual C++ 2005 supports is wstringstream etc. There is a free Express Edition. Frankly teh IDE and debugger are better that Dev-C++, but if you are married to Dev-C++ you would need to switch to teh derivitive wxDev-C++ which apparently now supports VC++ toolchain as a back-end.
Clifford
well, I'm not really willing to send wide characters to the console window. Not that I'm married to it. I've been using it for just a while and so far so good. I like the idea that it is not visual. at least at this stage of my learning when I want to understand the way things happen in Windows though I might eventually move to a visual tool if I feel appropriate. what's the difference between this free Express Edition to the standard version? Isn't it a too small subset of the real thing?
any more comments about your developing experiences with wide characters together with streams and your way to deal with it? does anyone here keeps with dev and works with wide streams by any means?
I was wondering if it would be a too huge effort to create new traits myself for the wchar_t template versions of the basic streams. I think this might solve the problem. But even if I do so, I wonder if that would be the sensible thing to do since it would me a private implementation of it and not the standard one available in some compilers.
Any new insights are welcome. Thank you very much for yours Clifford. ;)
>>Isn't it a too small subset of the real thing?
Ha! It depends what you want I guess, but it is certainly a superset of Dev-C++'s functionality!
See for yourself: http://msdn2.microsoft.com/en-us/vstudio/aa700921.aspx
The Express Edition of VC++ will do at least as much as Dev-C++ and a lot more. As far as support for standard C++ is concerned it is not cut-down at all - it is the peripheral tools that are restricted. What it does not have is all the corporate/enterprise development stuff and legacy support for MFC - you don't get that with Dev-C++ in any case. Out of the box it does not have legacy support for Win32 either, but on the IDE start page there is a link with clear instructions for downloading and installing the PSDK to support that. As an ISO C++ compiler it is very good. In addition it supports C++/CLI extensions, the .NET Framework and Windows Forms - but to be honest if these last technologies interest you, use C# (there's an express edition for that too). Note that in C# (and .NET in general) all characters are wide (even if teh console fails to display those outside the ANSI or local code-page set).
One problem with it is that it does not come with an install/deployment tool (neither does Dev), and to deploy native Win32 apps on machines without VC++ installed you will need to download vcredist_x86.exe which is an installer for the runtime library DLLs needed by VC++2005 apps. Running CLI code (which can be pure ISO code but compiled to the CLI), you need the .NET framework installed on machines you'll deploy on. The older C runtime used by Dev-C++ (or rather MinGW) is already installed as part of Windows. If you used C#EE however, it does support deployment packaging.
The big plus of VC++EE is that it comes with a best in class debugger. Unlike Dev-C++'s dismal effort.
>> any more comments about your developing experiences with wide characters[...]?
Ha again! I am an embedded systems developer, my experience with wide characters is minimal. This is perhaps the blind leading the blind. What I know I know from researching answers for other people. To be honest it takes some getting your head around.
>> I was wondering if it would be a too huge effort to create new traits myself for the wchar_t
In the header file <iosfwd> it is a single line! Unfortunately it is disabled by conditional compilation. I am not sure where simply enabling it or copying the line to your own code would really work - I assume it is disabled for a reason, just because the header supports it, does not mean the library will. The underlying C runtime (MSVCRT.DLL) supports wide character functions (even wprintf) but as I said the console is determinedly 8bit.
>> it would me a private implementation of it and not the standard one available in some compilers.
So use a different name or namespace and use your code everywhere rather than the standard. Nothing wrong wuith that if you have this source code and it is portable.
Soma might be able to add some clarity to this, it sounds like the kind of voodoo he'd have got his head around. I think you say his name three times and he'll appear. ;-)
Clifford
big wonder Clifford.
just found this by having a look at that file header you've just named <iosfwd>.
I went there and found: #ifdef _GLIBCXX_USE_WCHAR_T what led me to follow where I could find
_GLIBCXX_USE_WCHAR_T what led me to many header files that seem to define all we need for wstringstream support and I found this file C++configure.h with this line:
// Define if code specialized for wchar_t should be used.
/ #undef _GLIBCXX_USE_WCHAR_T /
if you have a close look at it, it is not defined nor undefined there since it is commented and there is even a message: Define if code specialized for wchar_t should be used.
so what?
does this mean that I may define that in my application and everything's gonna be fine and I'll be happy. I hope so. I guess I'll give it a try and let you know if something good came out of it.
Thanks in advance for the hint that made me find that. I was starting to think of upgrading my mingW installation (even with only a flimsy hope that it would be of any avail) but now I'll give this a shot first.
sorry, I guess I had gotten everything wrong lol
first, you'r right, it does hides support for some wide character things: cout, cerr, ...
second, I was thinking, from the beginning, it didn't support any wstringstream feature.
I guess this is why in the answers I got always that thing about console window and my answering that I didn't intend to send to the console what I really don't.
but I couldn't even figure out a way to use
wostringstream oss;
oss << L"I need some help here" :)
because the compiler would not recognize that
now, though
by defining _GLIBCXX_USE_WSTRING like this:
define _GLIBCXX_USE_WSTRING 1
the same way they define _GLIBCXX_USE_WSTRING somewhere :)
it seems I manage to make the wostringstream available.
thank you so much for leading me to this find. at least it was a find for me :)
I'm so happy now. If I'm not hugely mistaken, now I'll be able to play with it a bit longer till the next big hurdle at least :)
weird: it seems it does even support wcout ...
am I wrong?
ifdef _GLIBCXX_USE_WCHAR_T
using std::wcout;
using std::wcin;
using std::wcerr;
using std::wclog;
endif
provided that you define the flag with value 1 because of the wostringstream thing
by the by: I could not find the name "wostringstream" in the files inside any of the folders even though now the compiler accepts it. I wonder where in the computer they are stored.
:P
hidden files?
system files?
"I read in [...] is that true."
No.
"Is [...] wide char traits?"
Several.
"Whatever you [...] wide characters."
This isn't true for many installations of many versions of Windows. It requires a bit of tooling around with default console font and font page. As always, google is your friend.
"I was [...] of the basic streams."
That will not work with the libstdc++ version I am familiar with... the logic is problematic elsewhere.
"I wonder [...] in some compilers."
Well, as only defining a new trait will not work for what you need it would be a small waste of effort. You would learn a lot... so do it anyway.
"I think [...] appear."
Nope. I need more foreplay.
"Does this [...] I'll be happy."
Don't do that. The headers have been specialized as part of MGW by AutoTools. Something is missing, but with intent. The problem is with libstdc++ as usually built for MGW, but not with libstdc++ or MGW.
"I wonder [...] they are stored."
Files without an extension which are not searched for by most people. How are you searching?
For the record, what your using will almost certainly not be actually working. Write a small test to check the stored result byte by byte against what you know the contents should be.
Also, it is simple to write any Unicode character to the console with the right font and the right codepage using the Windows API. I blame the ISO standard for not defining more locales.
Soma
>> I wonder where in the computer they are stored.
Uh? <iosfwd> - you were looking at it!
As I suggested (perhaps vaguely) the library to which the header pertains will probably have been compiled without _GLIBCXX_USE_WCHAR_T. By changing the header you may be exposing features that don't exist or are not supported by the library.
That said, most of libstdc++ is presented as template code in the headers rather than in the library archive file as such so it may I suppose work, but if Soma doubts it so do I. Accepting and compiling is not the same as supporting and working.
Clifford
well, time for some feedback here.
just read what you both wrote and got a bit saddened now :)
I started some conversion. things even seem working.
I don't care for sending character to the DOS console window if this is what you mean now and again. But my intention was too make changes in my programs so that:
1. everywhere where I previously used char or char would become wchar_t or wchar_t by using TCHAR. that seems to be standard C and work fine.
2. create a tstring like function for stringstreams and other streams by declaring inside a class: typedef std:ostringstream<TCHAR> tstringstream
and I would do the same to all stream types I would need. I even did that for ostringstream already and my Unicodeclass defines some functions according to the state of UNICODE/_UNICODE is defined or not.
As you say: don't do that :) I'd ask. What would you advise? work with char inside every stream I use and use the C functions to convert between multibyte and wide character functions only when I'm to pass the string to windows function calls?
It may sound plausible but a bit farther away from the desirable thing, isn't it?
even with some lack of information in the conversion. While conversion from char to wchar_t is theoretically lossless the other way round seems to imply in something far from ideal.
:)
Yeah, you'r right slocombe. it is there in <iosfwd>. I had even the impression I had seen it. Weirdly enough windows couldn't find it when I made a search with the word: owstringstream. Some optmization of its search engine may have left it out. :(
Thank you all and I'll try and make a test to see what is coming out of the stringstreams. I wonder if the results are right I should feel more comfortable to use it though :) now that I've heard from you :)
is this what I should expect from my attempts?
I did that thing. I mean, I tried to use the wide stringstreams by defining _GLIBCXX_USE_WCHAR_T and ...
I would paste the log here but as it was too big I isolated part of the suspicious thing in a different project and got this smaller set of lines in the log error:
Compiler: Default compiler
Building Makefile: "C:\Dev-Cpp\myownprograms\WinProjectTest\Makefile.win"
Finding dependencies for file: C:\Dev-Cpp\myownprograms\WinProjectTest\main.cpp
Executing make...
make.exe -f "C:\Dev-Cpp\myownprograms\WinProjectTest\Makefile.win" all
g++.exe -c main.cpp -o main.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include"
g++.exe main.o WinProjectTest_private.res -o "WinProjectTest.exe" -L"C:/Dev-Cpp/lib" -mwindows
main.o:main.cpp:(.text+0x155): undefined reference to
std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string()' main.o:main.cpp:(.text+0x272): undefined reference tostd::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_string()'main.o:main.cpp:(.text+0x389): undefined reference to
std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_string()' main.o:main.cpp:(.text+0x3c7): undefined reference tostd::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_string()'collect2: ld returned 1 exit status
make.exe: *** [WinProjectTest.exe] Error 1
Execution terminated
the suspect code being:
std::wstring ws1;
for this log just above.
that is, even wstring, that compiles well with the variable undefined, gets this linkage error when _GLIBCXX_USE_WCHAR_T is defined to 1.
the same seems to hold true when I try both:
std::wstring ws1;
std::basic_ostringstream<TCHAR> wo1;
having then, a longer error log as expected:
Compiler: Default compiler
Building Makefile: "C:\Dev-Cpp\myownprograms\WinProjectTest\Makefile.win"
Finding dependencies for file: C:\Dev-Cpp\myownprograms\WinProjectTest\main.cpp
Executing make...
make.exe -f "C:\Dev-Cpp\myownprograms\WinProjectTest\Makefile.win" all
g++.exe -c main.cpp -o main.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include"
g++.exe main.o WinProjectTest_private.res -o "WinProjectTest.exe" -L"C:/Dev-Cpp/lib" -mwindows
main.o:main.cpp:(.text+0x155): undefined reference to
std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string()' main.o:main.cpp:(.text+0x175): undefined reference tostd::basic_ostringstream<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_ostringstream(std::_Ios_Openmode)'main.o:main.cpp:(.text+0x2b3): undefined reference to
std::basic_ostringstream<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_ostringstream()' main.o:main.cpp:(.text+0x2c8): undefined reference tostd::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_string()'main.o:main.cpp:(.text+0x3f7): undefined reference to
std::basic_ostringstream<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_ostringstream()' main.o:main.cpp:(.text+0x40c): undefined reference tostd::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_string()'main.o:main.cpp:(.text+0x45b): undefined reference to
std::basic_ostringstream<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_ostringstream()' main.o:main.cpp:(.text+0x488): undefined reference tostd::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_string()'collect2: ld returned 1 exit status
make.exe: *** [WinProjectTest.exe] Error 1
Execution terminated
summary:
_GLIBCXX_USE_WCHAR_T defined to 1 :
wstring compiles
wide streams compile
none of them link
_GLIBCXX_USE_WCHAR_T undefined:
wstring compiles and links
wide streams don't compile let alone link
any suggestios how to use wide streams with mingw???
is there a way?
did I miss something by now I knew before? :P
I'm completely dizzy now after this huge disappointment. I could use some help here :)
all that I want:
wostringstream support in mingw
is this asking too much? :P
does any of the newer versions of mingw comtemplate that properly? does anybody know? how do I check the correct version of my mingw32? is it the same as the name in the path? 3.4.2???
I did warn you. O_o
"Any [...] with MGW?"
You can get the newest build of STLPort or libstdc++. Both should support most wide character parts of the standard. You could also select any of a dozen higher level libraries that mimic the standard.
"Did I [...] before?"
Apparently you can't read my posts; could you read before?
"Does [...] that properly?"
See above; neither libstdc++ or MGW is broken. It is simply the way that libstdc++ is built with MGW. It is very likely that any newer combination of libstdc++ and MGW you might find will also exhibit broken behavior.
Soma