[haiku-commits] Re: haiku: hrev52133 - src/apps/mediaconverter

  • From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Fri, 27 Jul 2018 08:37:35 +0200

Hi,

On Fri, Jul 27, 2018 at 8:13 AM Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
wrote:

On Thu, Jul 26, 2018 at 11:25:50PM +0200, Stephan Aßmus wrote:
Thanks for the info. Isn't a "private:" declaration just a compile time
thing? If so, that would leave "overload of assignment" as a potential
reason for why media_format may not be "trivially copyable". I don't
really
see how, though, i.e. why that would affect object storage. But I
probably
just don't know enough about C++ implementation details. Or is there more
hiding in that "etc"?

Again, thanks for all the info, I've learned a lot. I guess that's what I
get for being mostly self-taught. IIRC, I even learned about unions
mostly
from seeing how media_format works. What I don't understand is how code
in
one place can even know which union member has been initialized in
another
place of the code. It would seem to make it necessary to always have
fields
in unions wich carry this information (such as media_format::type). But I
don't mean for you to keep digging, I should do that myself.

In any case, in my previous mails, I think more than once, I was asking
the
honest question if memset() may have unwanted side-effects, or be
ineffective at fully initializing the union. A simple "Yes, please google
it" would have been fine for me. And in fact I did google it, but only
found
stuff that confirmed what I learned before. (In essence, that
media_format
should be "trivially copyable".) Alter I saw that media_format also has
the
meta_data stuff, which makes it not trivially copyable, but that was
taken
into account where memset() was used, although not always in the correct
way.

There are two ways to look at this, in fact.

One is what the standard says. Since C++ is a "design by committee"
language, there are a lot of people involved in the discussion and they
tend to overthink things with a lot of "what if?" cases. They are also
trying to let compiler implementations decide how exactly they implement
things.

As a result, the definition of POD in the standard has become very
restrictive. For example, as soon as a field is private, the compiler
knows that nothing outside the class would try to play dirty things like
memsetting it or so. As a result, they could lift the requirement that
the public and private members of the class are stored side by side.


In reality in C++11 the concept of POD has been deprecated and split into
the concepts of standard layout object and trivial object.

-- 
Saluti,
Dario

Other related posts: