On 6/29/2015 7:45 PM, Glenn Burkhardt wrote:
I've read the "quirks" page, and I think you have a good sense of humor. All of the
"quirks" seem like sensible decisions to me, and fit in well with how I like to run my
life. Thanks for the tip - I've downloaded the latest builds, and am testing
Stop screaming, man.
0) You don't know what 'ASCII' really means (Hint: 'Extended ASCII' is not
ASCII.). C and C++ can handle multibyte file names well, no matter whether they
are ASCII or not. The way how the runtime handles file names is simply
implementation-defined (see WG14 N1570 (Programmi
On 6/24/2015 8:16 PM, Glenn Burkhardt wrote:
What's the status of MinGW64 w.r.t. multilib? The latest build with
multilib that I can find in the files section on SourceForge is from
2011-02-22.
Is it just hard to get it to work, or is there simply a lack of interest?
It's hard enough to get it
It seems like you're not passing -lwinmm to the linker. I use this:
LDFLAGS := -Wl,--as-needed -lgdi32 -lcomdlg32 -lws2_32 -lwinmm
-Wl,--no-as-needed
to selectively link these libraries. I'm not sure if the "as-needed" logic
is required on windows, but it works for me™.
What it does is only ref
The latest MinGW64 complains about this code:
#include
#include
#include
bool abc::Sound::PlayIt(){
//return !!sndPlaySoundW(Soundfile.c_str(), SND_FILENAME);
return !!PlaySoundW(Soundfile.c_str(), NULL, SND_FILENAME/*SND_ASYNC*/);
}
It says
In function `abc::Sound::PlayIt()':
C:/Win32
2015-06-29 19:16 GMT+02:00 :
> The standard C++ has major, and I mean MAJOR draw-back!!
> It cannot handle any other stream format that ASCII. 1988 standards in
> 2015? I cannot believe it!!
> I am sure that there are 3rd or 4th party libraries that can handle this
> issue, but than again, that
The standard C++ has major, and I mean MAJOR draw-back!!
It cannot handle any other stream format that ASCII. 1988 standards in 2015? I
cannot believe it!!
I am sure that there are 3rd or 4th party libraries that can handle this issue,
but than again, that is that... a 3rd || 4th party library.
I
Hi Martell,
On 06/29/15 12:45, Martell Malone wrote:
>
> It shouldn't be based on readdir, because it can't be made
> reentrant this way. I'd suggest changing the existing
> implementation to
> have reentrant semantic and reimplement readdit on top of that.
>
>
> Forgive my ignoran
>
> I'm not fun of adding more extensions like that. However I can see that
> we already provide readdir that is not present in MSVC, so it may make
> sense to provide _r variant as well.
Yes this is the reason I added it
Please compile test your code before asking for review :P
> Anyway, beside
Nice, thank you, I took your advice. I have now modify the code. I have other
problems, though.
This code:
std::wifstream infile;
infile.open( getFileName().c_str() );
error: no matching function for call to
'std::basic_ifstream::open(const wchar_t*)'
I found this discussion
http://stackoverfl
Hi Martell,
On 06/27/15 18:02, Martell Malone wrote:
> Attached is a patch for adding readdir_r
>
> I would like to ask should I make this __forceinline ?
> like the localtime_r and gmtime_r functions?
I'm not fun of adding more extensions like that. However I can see that
we already provide read
2015-06-29 9:54 GMT+02:00 :
> Thanks Ruben for the help.
> To answer your question, yes, I am.
> I was also using -std=gnu++14. However, I am now compiling only with
> –std::c++11, but to no avail. [image: Sad smile]
>
This is a microsoft extension, as Clang informs us:
http://coliru.stacked-cr
Thanks Ruben for the help.
To answer your question, yes, I am.
I was also using -std=gnu++14. However, I am now compiling only with
–std::c++11, but to no avail.
From: Ruben Van Boxem
Sent: Monday, June 29, 2015 2:27 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] th
13 matches
Mail list logo
