> What if the object being constructed has only POD-type members with constant
> initializers but is declared volatile
I don't understand really... but it doesn't matter, I give up.
Quoting Daniel Marjamäki :
Yes. It sounds unlikely. But not impossible of course. I could also
make sure the member variables are POD types before I inhibit the
warning. I just have no idea how I check if a member is POD. But I
could investigate this.
You could check if it has a constructor, u
>
> If the initializer is constant, but the member value that's being
> initialized has a
> non-trivial constructor with a side effect, your patch will inhibit the
> warning
> but the program will not behave the same as if reordering had not happened.
>
> Peter
>
Yes. It sounds unlikely. But not
2011/7/29 Daniel Marjamäki :
> Hello!
>
>> Why doesn't it matter in this case but it matters when the initializer
>> are non-constant?
>
> It doesn't matter because the program will behave the same no matter
> if the initializations are reordered or not. Logically it will behave
> just as the user
2011/7/30 Joern Rennecke :
> Quoting Jonathan Wakely :
>
>> I would object to changing the behaviour, or if it changes then it
>> should be controllable so I can continue to get the current behaviour,
>> e.g. -Wreorder=0 does what you propose, -Wreorder=1 does what we have
>> now, and -Wreorder is
On 30 July 2011 15:56, Joern Rennecke wrote:
> Quoting Jonathan Wakely :
>
>> I would object to changing the behaviour, or if it changes then it
>> should be controllable so I can continue to get the current behaviour,
>> e.g. -Wreorder=0 does what you propose, -Wreorder=1 does what we have
>> now,
Quoting Jonathan Wakely :
I would object to changing the behaviour, or if it changes then it
should be controllable so I can continue to get the current behaviour,
e.g. -Wreorder=0 does what you propose, -Wreorder=1 does what we have
now, and -Wreorder is equivalent to -Wreorder=1
That sounds
2011/7/29 Daniel Marjamäki :
> Hello!
>
>> Why doesn't it matter in this case but it matters when the initializer
>> are non-constant?
>
> It doesn't matter because the program will behave the same no matter
> if the initializations are reordered or not. Logically it will behave
> just as the user
2011/7/29 Richard Guenther :
> 2011/7/29 Daniel Marjamäki :
>> Hello!
>>
>>> Why doesn't it matter in this case but it matters when the initializer
>>> are non-constant?
>>
>> It doesn't matter because the program will behave the same no matter
>> if the initializations are reordered or not. Logica
2011/7/29 Daniel Marjamäki :
> Hello!
>
>> Why doesn't it matter in this case but it matters when the initializer
>> are non-constant?
>
> It doesn't matter because the program will behave the same no matter
> if the initializations are reordered or not. Logically it will behave
> just as the user
Hello!
> Why doesn't it matter in this case but it matters when the initializer
> are non-constant?
It doesn't matter because the program will behave the same no matter
if the initializations are reordered or not. Logically it will behave
just as the user expects no matter if he expects reorderin
On Fri, Jul 29, 2011 at 11:53:08AM +0200, Richard Guenther wrote:
> 2011/7/29 Daniel Marjamäki :
> Why doesn't it matter in this case but it matters when the initializer
> are non-constant?
Plus the documentation of -Wreorder even uses constants:
`-Wreorder (C++ and Objective-C++ only)'
Warn
2011/7/29 Daniel Marjamäki :
> Hello!
>
> In my humble opinion the -Wreorder has noise. When the order doesn't
> matter I would prefer that warnings are not issued.
>
> In this email I include a patch that I would like to get comments
> about. The patch will suppress warnings if all members are ini
13 matches
Mail list logo
