This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Fwd: RE: PODs vs memset (please forward)



----- Forwarded message from Alisdair.Meredith@uk.renaultf1.com -----
    Date: Thu, 5 Apr 2007 11:23:06 +0100
    From: "Meredith, Alisdair" <Alisdair.Meredith@uk.renaultf1.com>
Reply-To: "Meredith, Alisdair" <Alisdair.Meredith@uk.renaultf1.com>
 Subject: RE: PODs vs memset (please forward)
      To: gdr@cs.tamu.edu

Rats!  I forgot my email at work cannot access the fsf mailing lists -
our automatically injected disclaimer makes sure of that.

Could you forward my original reply to the list? - I won't have access
to a more usable account until I get home tonight.

Thanks
AlisdairM

> -----Original Message-----
> From: Meredith, Alisdair
> Sent: 05 April 2007 11:18
> To: libstdc++@gcc.gnu.org
> Cc: 'gdr@cs.tamu.edu'
> Subject: RE: PODs vs memset
>=20
> > -----Original Message-----
> > From: gdr@cs.tamu.edu [mailto:gdr@cs.tamu.edu]
> > Sent: 05 April 2007 01:38
> > To: Meredith, Alisdair
> > Cc: libstdc++@gcc.gnu.org
> > Subject: Re: PODs vs memset
>=20
> > I believe Paolo clearly said he was intending to use memset for
> > objects of *scalar types*, not POD.  So, I don't think there is
> > anything there to alert the world about.
>=20
> Sorry - the message at the start of this thread referred to using
isPOD, I
> probably picked the wrong message to reply to.
>=20
> > libstdc++ being the GNU implementation of the ISO C++ runtime, we
must
> > indeed be careful about the GCC ABI --  and we should take advantage
> > of that ABI when beneficial.  Would you mind pointing me at
> > the ABI where GCC is permitted to  reuse the tail of a base class
that
> > is POD?
>=20
> I freely admit I know nothing of the GCC ABI or other internals.
>=20
> The issue was brought to my attention a few years ago by Nathan
Sidwell,
> when he was with Code Sorcery.  I assumed (probably incorrectly) that
GCC
> was taking advantage of this, perhaps in an aggressive optimizing
mode.
> If it is not a problem for GCC (now or in the future) then great!  I
just
> didn't it to be ignored by accident rather than design <g>
>=20
> AlisdairM
---------------------------------------------------------------------


----- End forwarded message -----


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]