pon., 27 mar 2023 o 09:17 Phil Bouchard via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
>
>
> On 2/21/23 00:05, Thiago Macieira wrote:
> > On Monday, 20 February 2023 19:31:16 PST Phil Bouchard wrote:
> >>> Don't suspect. Prove it.
> >>
> >> Prove what? Windows' code is proprietary.
> >
> > You don't need access to the source to prove the point. You just have to have
> > a working application that, when run, shows the problem and has no reasonable
> > other reason for having the behaviour in question than what your hypothesis
> > is.
> >
> >>> This is the entire problem with this thread: you're suspecting a problem
> >>> and jumped to a conclusion that is unwarranted by the facts presented.
> >>> We've already twice shown that the problem was not where you thought it
> >>> was, meaning it's very hard to take any argument you're making on trust
> >>> alone now. You're oh-for-two now; you want a "third time is the charm"
> >>> case, not "strike three" (mixing my metaphors here).
> >>
> >> I just explained it crashes on both Windows 10 and 11 with 28x and 16x
> >> Intel Core i9 using Visual Studio 2019 in 64 bits Release mode.
> >
> > And as your later email has just shown, the problem wasn't the allocator; it
> > was that your application exhausted the address space of a 32-bit application
> > (which on Windows is 2 GB; on 32-bit Linux it used to be 3 GB and in a 64-bit
> > Linux kernel, the 32-bit application gets all 4 GB).
> >
> > You've twice now shown an application that fails to run for a reason that was
> > not what you thought it was. Your hypothesis remains unproven.
>
> So I did try all form of optimizations of OpenCV on Windows (TBB, Intel
> IPP, OCL, ...) running just 3 intermittent threads synced every 33
> milliseconds and the same cv::threshold function crashes before 3 hours.
> The function is readonly also except from the resulting object!
>

And how is this related to "set_new_handler extension"?
Besides, if a program "crashes" then in 99.99% cases it is the fault
of the programmer.
Especially again you did not check how exactly it "crashes".
I suggest cleaning the CPU fan on your PC because it could overheat.


> Under Linux I run the exact same code more aggressively with no
> optimization and using 12 continuous threads and it never crashes.
>

And this is a problem as lack of optimization can change endresults.
Besides if starve system resources then Win and Linux can behave differently.

> Unfortunately there is no big time memory sanitizer under Windows so I
> still don't have a proof but if it looks and quacks like a duck then it
> must be a duck.
>

it must be nastal demons.

And even in 1 of 100000000 cases you did find a bug in Windows,
how can it even be related to ISO C++ standard??
You could have same behavior in C, Rust, Python, C#, Pascal or any other
language that is used on windows.

Go to Microsoft and ask them to fix it.

> I don't want to reopen this debate, but I was definitely on the right track.
>
> --
> Logo <https://www.fornux.com/>
> *Phil Bouchard* facebook icon
> <https://www.linkedin.com/in/phil-bouchard-5723a910/>
> CTO
> T: (819) 328-4743
> E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com>
> 8 rue de la Baie| Gatineau (Qc), J8T 3H3 Canada
>
> Banner <https://goglobalawards.org/> Le message ci-dessus, ainsi que les
> documents l'accompagnant, sont destinés uniquement aux personnes
> identifiées et peuvent contenir des informations privilégiées,
> confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce
> message par erreur, veuillez le détruire.
> This communication (and/or the attachments) is intended for named
> recipients only and may contain privileged or confidential information
> which is not to be disclosed. If you received this communication by
> mistake please destroy all copies.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals