Date: Fri, 7 Apr 2023 13:53:53 -0400
On 4/7/23 13:41, Tom Honermann wrote:
> On 4/7/23 1:24 PM, Phil Bouchard wrote:
>>
>>
>> On 4/7/23 12:57, Tom Honermann wrote:
>>>
>>> Microsoft offers some useful and free tools for diagnosing such
>>> problems. See GFlags and PageHeap
>>> <https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/gflags-and-pageheap> and the related references there for example.
>>>
>>> I recommend exercising more restraint with regard to the veracity of
>>> the criticism you post to this list; it might just be the case that
>>> you have more to learn.
>>
>> These tools or the Address Sanitizer don't work with CUDA so you
>> require a better implementation of the STL or some run-time bounds
>> checker.
>
> They are, unsurprisingly, tied to use of heaps created by Windows. If
> you are using heaps created in other ways, then, yes, you'll need to use
> tools that work with those heaps. I don't see how that justifies the
> criticism that you have been posting to this list.
Well if you read the title of the thread, my initial goal was to clean
up this mess with a virtual table-based heap allocator so any client
could implement their own implementations for better safety or better
low latency algorithms.
But it turns out people don't understand the importance, try to
intimidate (BTW sometimes I intentionally say stupid things to trigger
the "bullies", this way I sort them out easily) or just don't want to
have to deal with Microsoft (funny de-facto influence here).
>>
>> Oh wait, C++ Superset already integrates that at compile-time. Never
>> mind.
>
> Yet it didn't suffice to identify the issue in your own code. Interesting.
Because this is not my own code but I did waste 1 month recompiling
OpenCV over and over trying to pinpoint the problem under Windows.
But that basically gives even more weight to the importance of C++ Superset.
> On 4/7/23 1:24 PM, Phil Bouchard wrote:
>>
>>
>> On 4/7/23 12:57, Tom Honermann wrote:
>>>
>>> Microsoft offers some useful and free tools for diagnosing such
>>> problems. See GFlags and PageHeap
>>> <https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/gflags-and-pageheap> and the related references there for example.
>>>
>>> I recommend exercising more restraint with regard to the veracity of
>>> the criticism you post to this list; it might just be the case that
>>> you have more to learn.
>>
>> These tools or the Address Sanitizer don't work with CUDA so you
>> require a better implementation of the STL or some run-time bounds
>> checker.
>
> They are, unsurprisingly, tied to use of heaps created by Windows. If
> you are using heaps created in other ways, then, yes, you'll need to use
> tools that work with those heaps. I don't see how that justifies the
> criticism that you have been posting to this list.
Well if you read the title of the thread, my initial goal was to clean
up this mess with a virtual table-based heap allocator so any client
could implement their own implementations for better safety or better
low latency algorithms.
But it turns out people don't understand the importance, try to
intimidate (BTW sometimes I intentionally say stupid things to trigger
the "bullies", this way I sort them out easily) or just don't want to
have to deal with Microsoft (funny de-facto influence here).
>>
>> Oh wait, C++ Superset already integrates that at compile-time. Never
>> mind.
>
> Yet it didn't suffice to identify the issue in your own code. Interesting.
Because this is not my own code but I did waste 1 month recompiling
OpenCV over and over trying to pinpoint the problem under Windows.
But that basically gives even more weight to the importance of C++ Superset.
-- 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.
Received on 2023-04-07 17:53:55