Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2001-03-16 08:21:59


>Maybe you could take the approach of using a .ipp file, where if
> the
> > >user wants a minimal header they just include the .hpp, but if
> they want
> > >speed, to have things inlined they include the .hpp and
> the .ipp. Thus
> > >the user has the option to choose.
> >
> > There may come a time when 15% difference is a big number. But
> right now
> > we need to focus first on the interface issues and functionality.
> Is this
> > an interface we feel comfortable with? Ditto functionality. Have
> known
> > safety issues been addressed? Then there are issues of correct
> > implementation.
> >
> > Eventually, after all those hurdles are passed, we can bother the
> > developers about 15% performance gains. But for now let's try to
> keep
> > focused on the larger questions.
> > Just my opinion, of course, and not meant to be critical of Dan's
> comments.
>
> Good point on top of those I tried to make myself. Considering this
> point, debate about the implementation detail of the pimpl idiom will
> no longer be considered by myself at this time. It's easily enough
> addressed later if found to be important. Let's focus on the design
> and the implementation bugs.
>
> Bill Kempf

I know you have already closed the discussion on this, but if you look
in the vault you will find documentation and an implementation of the .ipp
idiom Dan mentions in the compressed stream library I recently uploaded.

http://groups.yahoo.com/group/boost/files/compressed_streams/

This allows the library user to select the inlining option at compile time,
effectively allowing the user to decide the performance versus dependency
tradeoff. The design.html file describes the idiom and provides references.
It is my opinion that you will need do this to support high performance
applications and it will be easier to do it now rather than wait and
convert all the code later...

Jeff


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk