On Mon, 28 Nov 2022, 08:08 Jan Beulich via Gcc, wrote:
> On 26.11.2022 20:04, Pali Rohár wrote:
> > On Monday 21 November 2022 08:24:36 Jan Beulich wrote:
> >> But then, with you replying to
> >> me specifically, perhaps you're wrongly assuming that I would be
> >> planning to look into addressin
On Sun, 24 Jan 2021 at 08:15, Liu Hao wrote:
>
> 在 2021-01-24 02:05, Hannes Domani via Mingw-w64-public 写道:
> > Am Samstag, 23. Januar 2021, 16:46:18 MEZ hat Jeroen Ooms
> > Folgendes geschrieben:
> >
> >> A user of the R programming language has reported that std::regex
> >> causes a hang for c
On 02/07/19 12:15 +0200, Jacek Caban wrote:
On 02/07/2019 12:12, Jacek Caban wrote:
On 02/07/2019 11:57, Liu Hao wrote:
在 2019/7/2 下午5:19, Eric Botcazou 写道:
It seems inappropriate to use handles as thread identifiers
(as handles
imply resource ownership and are not unique identifiers);
thre
On 02/07/19 20:14 +0800, Liu Hao wrote:
在 2019/7/2 下午8:00, Jonathan Wakely 写道:
The C++ standard says:
"The library may reuse the value of a thread::id of a terminated
thread that can no longer be joined."
So that's not a reason to use a handle.
According to MSDN [1] a thr
On 25 October 2017 at 12:24, Liu Hao wrote:
> On 2017/10/25 18:35, Jonathan Wakely wrote:
>>
>> Is this because -std=c99 sets __STRICT_ANSI__?
>> > The C++ runtime is not built with -std=c99, of course.
>
>
>>
>
>
> No. It will not compile despite th
On 25 October 2017 at 02:50, Liu Hao wrote:
> On 2017/10/24 23:55, Jonathan Wakely wrote:
>>
>> On 23 October 2017 at 15:55, David Gressett wrote:
>>>
>>> gcc needs some substantial patching to to build on Windows.
>>> The details depend on whether
On 16 May 2017 at 11:09, Jonathan Wakely wrote:
> On 16 May 2017 at 11:01, Liu Hao wrote:
>> On 2017/5/16 17:35, Jonathan Wakely wrote:
>>>
>>> On 11 May 2017 at 17:55, David Grayson wrote:
>>>>
>>>> Hello, gcc-help.
>>>>
>>>
On 16 May 2017 at 11:01, Liu Hao wrote:
> On 2017/5/16 17:35, Jonathan Wakely wrote:
>>
>> On 11 May 2017 at 17:55, David Grayson wrote:
>>>
>>> Hello, gcc-help.
>>>
>>> There is an incompatibility between libstdc++ and the headers provided
>
On 11 May 2017 at 17:55, David Grayson wrote:
> Hello, gcc-help.
>
> There is an incompatibility between libstdc++ and the headers provided
> by Microsoft and mingw-w64, because libstdc++ uses __in as a parameter
> name in several places while the Microsoft headers define __in as a
> preprocessor m
On 18 April 2016 at 10:57, Jonathan Wakely wrote:
> On 18 April 2016 at 10:18, lh_mouse wrote:
>>> I don't see why it has to be a struct, it just has to be suitable as
>>> an argument to the relevant __gthread functions.
>>
>> The type __gthread_time_t is refe
On 18 April 2016 at 10:18, lh_mouse wrote:
>> I don't see why it has to be a struct, it just has to be suitable as
>> an argument to the relevant __gthread functions.
>
> The type __gthread_time_t is referenced in
> gcc/libstdc++-v3/include/std/mutex:157
> __gthread_time_t __ts = {
>
On 18 April 2016 at 08:39, lh_mouse wrote:
> I have added a thread model and added its corresponding header files. But it
> failed the linker.
>
> The file 'gcc/libgcc/config/i386/t-mingw-pthread' which contained two lines:
> SHLIB_PTHREAD_CFLAG = -pthread
> SHLIB_PTHREAD_LDFLAG = -Wl,-lpthrea
On 17 April 2016 at 17:56, lh_mouse wrote:
> A glance over gthr.h reminds me __gthread_time_t. There seem few requirements
> documented in gthr.h.
> I discussed this with Adrien Nader on mingw-w64's mailing list a few days ago.
>
> Specifically, here are the two questions:
> 0) Should __gthread_t
On 13 April 2016 at 10:17, lh_mouse wrote:
> Hi all,
>
> The 'win32' thread model of gcc has been there since long long ago, being
> compatible with very old Windows versions, also having a number of drawbacks:
> 0) its implementation is very inefficient, and
> 1) its mutexes and condition var
On 30 June 2015 at 23:58, wrote:
> I would like to write a function to capitalize letters, say...
> std::wstring toUpper(const std::wstring wstr){
> for ( auto it = wstr.begin(); it != wstr.end(); ++it){
>global_wapstr.append(std::towupper(&it));
>
> }
> }
>
> This doesn’t work, but doesn
On 28 May 2015 at 18:22, Martin Sebor wrote:
> [*] The Feature Testing Recommendations For C++ proposal (N4440
> being the latest I could find) tries to alleviate it by providing
> test macros for individual features. I know Clang implements parts
> of it but don't know what its status is in GCC.
>
On 28 May 2015 at 16:51, Martin Sebor wrote:
> The standard specifies that implementations conforming to C++
> 11 must define the __cplusplus macro to 201103L, and recommends
> that non-conforming compilers (presumably those that aim to be
> C++11 conforming but whose support is incomplete) should
On 28 May 2015 at 16:24, Hotmail (ArbolOne) wrote:
> If I am not mistaken _MSC_VER >= 1600 is the version that started
> implementing C++11. So, I test for that version of the compiler in my code,
> i.e.
> #ifdef _MSC_VER >= 1600
>
> #endif
> I would like to do the same for __GNUG__, but w
On 28 May 2015 at 00:15, Hotmail (ArbolOne) wrote:
> I know, I know, this is not a C++ question, but, as I said, I am in a
> in-path, I don't know what to do in this case.
I have no idea what an in-path is (impasse?) but you've sent another
off-topic post that is not about GCC.
For general progra
On 10 May 2012 15:03, K. Frank wrote:
>
> Neither of these shows --enable-threads of any flavor (in gcc -v), but both
> show "Thread model: win32" in the gcc -v output.
Yep, if you don't explicitly configure with --enable-threads then the
configure script picks a suitable default, which is "win32"
On 9 May 2012 20:49, Kai Tietz wrote:
>
> The issue about critical-sections and gthread (and also pthread) API
> is, that not all locking-kinds can be modelled by it. The difference
> on Windows for it is, that a critical section object provides
> synchronization similar to that provided by a mute
On 9 May 2012 20:06, K. Frank wrote:
> However, as noted in my previous post, I have happily done some
> (limited) windows-api threading programming with Ruben's build
> (and also did the windows-api threading programming necessary
> to implement ),
If you use GCC built with --enable-threads=posix
On 9 May 2012 17:28, Earnie Boyd wrote:
> On Wed, May 9, 2012 at 11:58 AM, K. Frank wrote:
>> Again, I'm not all that big on backward compatibility, and, as noted
>> above, I don't understand what --enable-threads=win32 is for. But
>> my gut reaction is if that the gcc implementation (with
>> -
On 9 May 2012 16:58, K. Frank wrote:
> Hello Jonathan!
>
> I've taken the liberty of cross-posting this to the mingw list
> (a separate project from mingw-w64), as they are the other
> big windows-focused "downstream" consumer of gcc.
>
> On Wed, May 9, 201
On 7 May 2012 18:28, K. Frank wrote:
> Hello Gabriel (and Ruben)!
>
> By the way, I'm the guy Ruben mentioned in his subsequent post.
>
> On Sat, May 5, 2012 at 11:20 PM, Gabriel Dos Reis
> wrote:
>> Including the mingw64 project about this.
>>
>> On Sat
On 7 May 2012 18:35, K. Frank wrote:
> Hello Ruben and Gabriel!
N.B. I'm not on the mingw lists, so please keep me CC'd if you want
responses or any help from me in enhancing libstdc++ to work better on
Windows.
> And my P.S.: As I mentioned in my earlier post, I have been using Ruben's
> -enab
On 27 June 2011 20:50, Ruben Van Boxem wrote:
> (If it is liked here, I see no reason not to also propose it to LLVM's
> libc++).
Why? libc++ only supports Mac OS X, so adding Windows-only extensions
seems pointless.
How does the Rogue Wave / Apache stdcxx support whar_t filenames on Windows?
N.
On 26 June 2011 16:26, Jonathan Wakely wrote:
> On 26 June 2011 16:06, Ruben Van Boxem wrote:
>>
>> No extra #includes are necessary, and for now I #ifdef'ed the extra
>> code with #if _WIN32. Perhaps cleaner would be a configure check for
>> OS or CRT used and a
On 26 June 2011 16:06, Ruben Van Boxem wrote:
> Hi,
>
> I have implemented a small patch that mirrors Microsoft's STL
> extension, where one can use wide strings as an argument to
> std::(w)fstream. This is very useful on Windows, where, without this
> extension, there is no way to open an fstream
29 matches
Mail list logo
