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
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
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 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 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 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 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 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/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 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 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
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
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
13 matches
Mail list logo
