Boost logo

Boost :

Subject: Re: [boost] Proposal: Add Loki Library's SafeFormat to Boost:
From: Joel de Guzman (joel_at_[hidden])
Date: 2009-01-01 23:07:35


Robert Ramey wrote:
> Joel de Guzman wrote:
>> Robert Ramey wrote:
>>> I wish you guys could appreciate how all this name changing makes
>>> things much more difficult for us poor library users.
>>>
>>> The fact that names are in no way descriptive is another huge time
>>> waster.
>> Just curious. How much time did you waste before you realize
>> that Boost.Spirit was a parser? Can you explain why it is a
>> "huge time waster"? IMO, it takes a second to know, while
>> browsing http://www.boost.org/doc/libs, that Spirit is a parser.
>
> Here are examples where time has been wasted.
>
> All of a sudden, one some platform the serialization library fails
> to build. After a time, an investigation reveals that the
> #include <boost/spiritsomefile>
> get redirected in some baroque non-obvious way to
> something like boost/spirit/class.. or something like that.
> OK - I'll just tweak the library so that it includes the "classic"
> targets directly.
> Now, the library won't build for borland compilers. Turns

Spirit 1.8 never ever worked on Borland.

> out that this compiler needs spirit 1.6x - which I have on

Yes, you need 1.6 for that.

> my machine but the directory structure is different. To

Not true! The directory structure was never changed. The old
headers will be deprecated (after a couple of releases [2, I think,
starting from 1.37]), but not without warning.

> top it off, there isn't enough information - or its not sufficiently
> obvious to find - to conditionally include the right stuff.

Not true! If you use a deprecated include and the warning starts to
kick in (after Boost 1.38 I think), it will warn you and point you
to the right file. Example:

#if BOOST_VERSION >= 103800
#if defined(_MSC_VER) || defined(__BORLANDC__) || defined(__DMC__)
# pragma message ("Warning: This header is deprecated. Please use:
boost/spirit/include/classic_dynamic.hpp")
#elif defined(__GNUC__) || defined(__HP_aCC) || defined(__SUNPRO_CC) ||
defined(__IBMCPP__)
# warning "This header is deprecated. Please use:
boost/spirit/include/classic_dynamic.hpp"
#endif
#endif

> Now, it looks like spirit is going to be "upgraded" how
> will this effect the current code?

You do not have to lift a finger. The new code is 100% backward
compatible.

No way to know. How

No need to know. Unless you want to stay current. In which case
you have various ways. 1) Simply tweak the paths 2) port to Spirit2.

> much time have I wasted on this? I didn't keep track.

Does not have anything to do with naming. I see no connection.
What you say above are totally different issues.

> Not that it matters since we're not apparently done yet.
>
> Here's a suggestion.
>
> for your latest/greatest, put in the namespace boost::spirit and in
> directory boost/sprit
>
> For your old version, with an incompatible API, put it in namespace
> boost::spririt_1_8 and directory boost/spririt_1_8.
>
> and for your older version put it in
> boost::spririt_1_6 and directory boost/spririt_1_6
>
> And include a macro BOOST_SPIRIT_VERSION with the version string or number
>
> Leave the tests in the previous versions even though they are no longer
> being tested.
>
> This would be really helpful and I don't think it would create much work for
> you.

It seems you haven't really tried to know more beyond the name(s).
Except for spririt 1.6, our recipe is similar to what was done.
"Classic" Spirit will not, I repeat: will not, go away anytimne soon.
It is, and will be, in the namespace "classic". This is the technical
rationale behind the "baroque" include paths. We want 100% backward
compatibility while at the same time usher in the new generation.
It's not an easy task, mind you. A lot of neurons were employed until
we came up with the best practical approach.

Then again, all these does not have anything to do with naming.

Regards,

-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net

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