Re: [cpp-netlib-devel] Compile-time Reduction Effort

[Dean M. B. <mik...@gm...>]

On Tue, Oct 26, 2010 at 11:41 PM, Glyn Matthews <gly...@gm...> wrote:
>
>
> On 26 October 2010 06:33, Dean Michael Berris <mik...@gm...>
> wrote:
>>
>> Yeah, the compile time problem is really brought in by Boost.Spirit's
>> Qi (and consequently Boost.Fusion and Boost.Proto). Although it is
>> portable already as it is now, right?
>
> Maybe I need to clarify what I meant "portable"... I mean that with each
> version upgrade of cpp-netlib we don't preserve backward compatibility
> either with older versions of Boost or of compilers.

Hmmm... That threw me off. I thought you mean portable to different
platforms, not backward compatible with older compilers or Boost
versions.

> This pretty much rules
> it out for most embedded systems who have to rely on older compilers (for
> one project not so long ago I was still using gcc 2.95).  I think there is a
> strong argument in favour of preferring this kind of stability than to using
> the latest and greatest from Boost (fun though it might be for the
> developers).
>

I think stability could be achieved in a different way.

There are two ways I know of that allows us to go ahead and support
more platforms+compilers:

1. Do a fork of the project that specifically addresses older
compilers or specific platforms. This will mean porting to an older
version of Boost and older version of compilers and fixing specific
things that break for those compilers. You mention GCC 2.95 and that
compiler version has the most compiler bugs and creates really bad
code -- not to mention is not fully C++98 compliant IIRC. I've dealt
with GCC 2.95 for an extended period of time early in my career and
it's really frustrating having to work around its deficiencies when it
comes to C++.

2. We do a branch that specifically addresses, for every release, the
embedded platforms that we'd like to support. I can imagine for
example porting cpp-netlib for meego or Symbian, but I'm really not
prepared to take on that effort. ;)

There might be other ways, but it's largely dependent on the available
time/resource/expertise of contributors. :D

>>
>> The long compile times can really be addressed by precompiled headers
>> especially if you're using GCC. Clang, well not so much because
>> precompiled headers support is still a little ... well... iffy at this
>> time. :D
>
> and MSVC?  I know it supports PCH of course but how does it differ from GCC?

MSVC has better support for PCH than GCC last time I checked. I didn't
think it was worth mentioning because MSVC is also considerably faster
than GCC IMO. ;)

>  Will this affect design decisions?

Nope, not one bit. Just deployment/development strategies. :D

>>
>> Thanks for the comments Glyn, hope mine help convince you that
>> precompiled headers and changes to cpp-netlib will be good for users
>> (and embedded systems). :)
>
> I am not going to argue too forcefully for shipping cpp-netlib as a library,
> since we've already been marketing it as header-only since it's inception
> and I think it does have merits.  My main motivation is for better
> stability.

I haven't been paying attention to stability at all lately because I
still really just want to complete the features. It might be good to
drop back to the requirement on Boost version -- going back to 1.41
would be a good idea by removing the dependency on Boost.Range
extensions.

Also, I have this (bad) habit of developing against Boost's trunk. My
rationale is that it's easier to get acceptance to Boost if the
library stays up to breast with the latest in the repository. Once
things get to 1.0 though I really would like to focus on keeping the
requirements on the Boost version low -- and by that time 1.45 might
be the new "low stable" version given the Serialization SNAFU. ;)

HTH

-- 
Dean Michael Berris
deanberris.com