I guess the phrasing is a bit weak, "some users" obviously has to refer
to a significant proportion of users, "easy to avoid" cannot have too
many drawbacks (in particular, generated code should be of equivalent
quality), etc.
-Wclass-memaccess fits the "easy to avoid" quite well, since a simp
Not sure how kosher it is to address several replies in one email, but
I'm going to attempt it as there are overlapping topics:
Martin:
Simply because a struct has a constructor does not mean it isn't a
viable target/source for use with memcpy/memmove/memset.
As the documentation that Seghe
On Mon, 9 Jul 2018, Martin Sebor wrote:
My point to all of this (and I'm annoyed that I'm having to repeat it
again, as it my first post wasn't clear enough - which it was) was that
any programmer using memcpy/memmove/memset is going to know what they're
getting into.
No, programmers don't alw
On Tue, 10 Jul 2018, 02:22 Soul Studios wrote:
> My point to all of this (and I'm annoyed that I'm having to repeat it
> again, as it my first post wasn't clear enough - which it was) was that
> any programmer using memcpy/memmove/memset is going to know what they're
> getting into.
It was clear
On 07/09/2018 07:22 PM, Soul Studios wrote:
On 07/05/2018 05:14 PM, Soul Studios wrote:
Simply because a struct has a constructor does not mean it isn't a
viable target/source for use with memcpy/memmove/memset.
As the documentation that Segher quoted explains, it does
mean exactly that.
Some
On 07/05/2018 05:14 PM, Soul Studios wrote:
Simply because a struct has a constructor does not mean it isn't a
viable target/source for use with memcpy/memmove/memset.
As the documentation that Segher quoted explains, it does
mean exactly that.
Some classes have user-defined copy and default c
On Sun, 8 Jul 2018, Jason Merrill wrote:
On Sun, Jul 8, 2018 at 6:40 PM, Marc Glisse wrote:
On Fri, 6 Jul 2018, Martin Sebor wrote:
On 07/05/2018 05:14 PM, Soul Studios wrote:
Simply because a struct has a constructor does not mean it isn't a
viable target/source for use with memcpy/memmove
On Sun, Jul 8, 2018 at 6:40 PM, Marc Glisse wrote:
> On Fri, 6 Jul 2018, Martin Sebor wrote:
>> On 07/05/2018 05:14 PM, Soul Studios wrote:
>>>
>>> Simply because a struct has a constructor does not mean it isn't a
>>> viable target/source for use with memcpy/memmove/memset.
>>
>>
>> As the docume
On Fri, 6 Jul 2018, Martin Sebor wrote:
On 07/05/2018 05:14 PM, Soul Studios wrote:
Simply because a struct has a constructor does not mean it isn't a
viable target/source for use with memcpy/memmove/memset.
As the documentation that Segher quoted explains, it does
mean exactly that.
Some cl
On 07/05/2018 05:14 PM, Soul Studios wrote:
Simply because a struct has a constructor does not mean it isn't a
viable target/source for use with memcpy/memmove/memset.
As the documentation that Segher quoted explains, it does
mean exactly that.
Some classes have user-defined copy and default c
On 07/06/2018 12:14 AM, Soul Studios wrote:
> Having benchmarked the alternatives memcpy/memmove/memset definitely makes a
> difference in various scenarios.
That sounds like a missing optimization in the compiler. If you have valid
testcases, I think it would be a good idea to file them in bugz
On Fri, Jul 06, 2018 at 11:14:41AM +1200, Soul Studios wrote:
> Simply because a struct has a constructor does not mean it isn't a
> viable target/source for use with memcpy/memmove/memset.
> Having benchmarked the alternatives memcpy/memmove/memset definitely
> makes a difference in various scen
Simply because a struct has a constructor does not mean it isn't a
viable target/source for use with memcpy/memmove/memset.
Having benchmarked the alternatives memcpy/memmove/memset definitely
makes a difference in various scenarios.
The bypass of littering code with needless reinterpret_cast's i
13 matches
Mail list logo
