.. I don't have much to add to the various informative replies. Only, a
general recommendation. Let's not use in any "official" document the
term "STL": it does *not* exist in any ISO standard, basically dates
back to early nineties HP / SGI code.
Paolo.
On Thu, Feb 07, 2008 at 03:18:19PM -0500, Daniel Jacobowitz wrote:
> On Thu, Feb 07, 2008 at 12:08:33PM -0800, Joe Buck wrote:
> > It doesn't need to know that. Any compiler that follows the ABI, whether
> > gcc,
> > icc, or SGI's compiler, will produce the same data members on a GNU/Linux
> > or
On Thu, Feb 07, 2008 at 12:08:33PM -0800, Joe Buck wrote:
> It doesn't need to know that. Any compiler that follows the ABI, whether gcc,
> icc, or SGI's compiler, will produce the same data members on a GNU/Linux
> or BSD platform. It's a portable specification.
I don't believe that the multi-v
On Fri, Feb 08, 2008 at 08:28:21AM +1300, Nick Roberts wrote:
>
> > > I would say they are pretty stable, because we have a stable ABI which
> > > we are not going to break until C++0x: that means we can only implement
> > > limited span changes, we cannot add data members, for example neither
> > I would say they are pretty stable, because we have a stable ABI which
> > we are not going to break until C++0x: that means we can only implement
> > limited span changes, we cannot add data members, for example neither
> > change the memory layout of the classes.
Probably an ignorant que
> > However, _M_impl, _M_start etc are gcc internals and it might be risky for
> > Emacs to rely on them. Can anyone say how likely these internals are to
> > change? I'm not asking for a guarantee. It would be helpful just to know
> > when they last changed as an indication of how volatile thi
Hi,
> However, _M_impl, _M_start etc are gcc internals and it might be risky for
> Emacs to rely on them. Can anyone say how likely these internals are to
> change? I'm not asking for a guarantee. It would be helpful just to know
> when they last changed as an indication of how volatile this cod
