Re: [Audacity-devel] Thank you David Bailes for MSVC fix...

[David B. <drb...@gm...>]

On 15 January 2018 at 16:50, Paul Licameli <pau...@gm...> wrote:

>
>
> On Mon, Jan 15, 2018 at 11:36 AM, David Bailes <drb...@gm...> wrote:
>
>> On 13 January 2018 at 19:51, Paul Licameli <pau...@gm...>
>> wrote:
>>
>>> ... at commit 6ca8cef34a8f431f5bd506cbd241107c5e772b6f
>>>
>>> I made misbehavior in the Windows build, but I think this is again
>>> another case where the MSVC 2013 compiler is not implementing all the
>>> niceties of the C++11 standard as it should, so I can shift blame :-)
>>>
>>> I am curious to know if this would have been an adequate alternative fix:
>>>
>>> Explicitly generate the default-default constructors in structs
>>> FoundTrack, FoundClip, and FoundClipBoundary.  That is, add the declaration
>>>
>>> FoundTrack() = default;
>>>
>>> and similarly for the other two.
>>>
>>> See commit 5302dacf3de926fe50ee2ccb8dd4efcf58de7855 for another example
>>> where I shouldn't need to default the constructor explicitly, and yet doing
>>> so changes MSVC 2013 behavior -- in that case, suppressing a bogus compiler
>>> warning.
>>>
>>>
>>> Language lawyerly details:
>>>
>>> The standard stipulates a subtle difference between generated default
>>> constructors that are trivial (as these should be), and default
>>> constructors defined with empty body {}.
>>>
>>> In the former case only, there is then a difference in behavior between
>>> default initialization http://en.cppreference.com/w/cpp/language/def
>>> ault_initialization and other initializations.  I haven't read all the
>>> details, but I understand that default initialization of a stack variable
>>> will make unspecified values for int and pointer other members, but
>>> initialization (as you do in FindNextClip()) with {} will cause
>>> zero-initialization of those members.
>>>
>>> Buf if you define a default constructor with empty body, then there is
>>> no distinction, and non-static variables of the type will always get
>>> unspecified values (assuming no in-class member initializers).  Yet, I did
>>> not do that.
>>>
>>> On the other hand, you mention in commit comments, POD types.  I don't
>>> know what alerted you to the POD "concept" as relevant, but there is a
>>> difference between POD and, less strictly, trivial structs (trivially
>>> copyable and trivially default-constructible):  POD also implies "standard
>>> layout"  http://en.cppreference.com/w/cpp/concept/StandardLayoutType
>>> and FoundClip is not that.
>>>
>>> I think the initialization rules I alluded to were amended so as not to
>>> require strict POD-ness, but only since C++11, and MSVC might yet be
>>> following C++03 rules that were explicitly about needing POD.
>>>
>>> PRL
>>>
>>
>> I think you're right, it's the MSVC 2013 compiler. I think the POD stuff
>> is pre c++11, so my explanation was wrong.
>>
>> I wrote a small test program and found that:
>> 1. using the default keyword has no effect.
>> 2. In MSVC 2013, if there is no inheritance involved, then things are
>> zero initialized. So it was your addition of inheritance that changed
>> things.
>>
>
> Yes, when there is inheritance, and more than one class in the hierarchy
> defines non-static data members, then that disqualifies the class as POD.
> POD requires "standard layout":
>
> http://en.cppreference.com/w/cpp/concept/StandardLayoutType
>
> Somewhere in the complicated rules for initializations at cppreference.com,
> I can't find where now -- I read that the POD criterion was relevant to
> initializations before C++11, and MSVC2013, with its incomplete C++11 core
> language implementation, might still be following old rules on this point.
>
> 3. In MSVC 2017, things are zero initialized with or without inheritance
>> being present.
>>
>
> WIth what source code exactly?
>

I tested with this code:

struct fred {
int a;
}

struct sue : public fred {
int b;
}

struct sue temp{};


David.


> I think that is what C++11 would require, if no constructors are declared
> at all, or if default constructors are declared with =default and not empty
> body.
>
> PRL
>
>
>
>>
>> David.
>>
>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> audacity-devel mailing list
>>> aud...@li...
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>