cpp-netlib-devel — Developers Mailing List

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

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

On Tue, Oct 26, 2010 at 11:50 PM, Nelson, Erik - 2
<eri...@ba...> wrote:
>>Dean Michael Berris wrote:
>>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
>
> Does gcc have any requirements on the usage of precompiled headers?  I
> thought I remembered that no compilable code could appear before the
> precompiled header, which seems like it could lead to strange
> requirements like 'cpp-netlib headers need to be included first in a
> file' in order to get the pch benefit.
>

Well, there's also the single PCH per compilation unit requirement.
This would be perfect for 'boost/network/include/http/client.hpp' and
similar files.

http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html explains it
in great detail.

For the most part, these are easy -- and actually painless -- to
follow in case you really want to get the advantage of PCH. Otherwise,
that's not really a big burden having PCHs around if they're just
there to help -- I mean, if they aren't used, the normal headers are
used.

> I might be mistaken, just wanted to bring it up.

No worries. Thanks for bringing it up. :)

>
> Clang you don't have to worry about, since it's so fast already, right?
> ;)
>

Hah! Touche. :)

-- 
Dean Michael Berris
deanberris.com

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

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

[Nelson, E. - 2 <eri...@ba...>]

>Dean Michael Berris wrote:
>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

Does gcc have any requirements on the usage of precompiled headers?  I
thought I remembered that no compilable code could appear before the
precompiled header, which seems like it could lead to strange
requirements like 'cpp-netlib headers need to be included first in a
file' in order to get the pch benefit.

I might be mistaken, just wanted to bring it up.

Clang you don't have to worry about, since it's so fast already, right?
;)

Erik

----------------------------------------------------------------------
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. 
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. 

References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: 
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.

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

[Glyn M. <gly...@gm...>]

On 26 October 2010 06:33, Dean Michael Berris <mik...@gm...>wrote:

> On Tue, Oct 26, 2010 at 2:59 AM, Glyn Matthews <gly...@gm...>
> wrote:
> > Including the compile time
> > problem and making cpp-netlib strictly being header-only has very few
> > benefits.  I would suggest a better use of our focus should be on
> > portability.
>
> 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.  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).


>
> > Additionally, I have been doing a lot of development in embedded systems,
> > where the long compile times and large binaries that are generated pretty
> > much rules out using cpp-netlib.  This is a shame, because this is an
> area
> > where cpp-netlib can provide a lot of benefits to developers.
> >
>
> Are you not stripping the binaries created by cpp-netlib? In Debug
> mode, yes you will have problems with the debugging symbols eating up
> the output binary.
>
> Also, since we still depend on Boost.Lexical_cast that does depend on
> the STL io streams library, that will cause the binaries to be pretty
> large. We might want to try using Jeroen's construe_cast in places
> where we use lexical_cast.
>
> 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?
 Will this affect design decisions?

>> > I'm nearing the completion of the asynchronous server that invokes
> >> > request handlers in a thread pool and although the compile times have
> >> > been reduced in the HTTP client side of things I would really
> >> > appreciate some CMake kung-fu from people on the list to incorporate
> >> > precompiled-headers (so that we can make that part of the install step
> >> > in 0.8).
> >> >
> >>
> >> Compile time *is* an important issue, but the beauty of a header library
> >> is that there is no install step- you just copy the files into your
> >> directory tree.
> >
> > But there is an install step, because of the dependencies that cpp-netlib
> > has - and will have: in developing the XMPP client I'll be linking to an
> XML
> > parser library and TLS library.  Other protocol implementations will
> bring
> > other dependencies and we'll have to deal with those too.
>
> Yeah, this is going to be the test of having an install step. :D
>
> > Regards,
>
> 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.

Glyn

Re: [cpp-netlib-devel] cpp-netlib 0.8 Target Deliverables

[Glyn M. <gly...@gm...>]

Dean,

On 26 October 2010 06:04, Dean Michael Berris <mik...@gm...>wrote:

> On Tue, Oct 26, 2010 at 3:17 AM, Glyn Matthews <gly...@gm...>
> wrote:
> > Hi Dean,
> >
> > On 18 October 2010 19:12, Dean Michael Berris <mik...@gm...>
> > wrote:
> >>
> >> As always, thanks again for the support and I look forward to your
> >> contributions to release 0.8.
> >>
> >
> > Do you think we're still on schedule for the 1st week of November? :)  I
> can
> > tell you now that the XMPP client won't be ready...
>
> Ah, that's alright.
>
> The server parts will be ready by 1st week of November. I'm getting to
> the end of the asynchronous server refactoring as well as the thread
> pool implementation. Some of the enhancements may not be ready by
> then.
>
> I'll be perfectly happy with releasing an improved server for 0.8 or
> just calling it 0.7.1 might be better. I really want to see both the
> improved MIME and XMPP implementations in cpp-netlib before we submit
> for review/inclusion in Boost for December.
>
>
Will MIME be part of cpp-netlib?  As I understood it, it was being developed
separately.

Also, for 0.8 I'd like to push for an effort fixes to #18 and #15:

http://github.com/cpp-netlib/cpp-netlib/issues/#issue/18
http://github.com/cpp-netlib/cpp-netlib/issues/#issue/15

Maybe I ought to take this on if there are no other volunteers ...
G

[cpp-netlib-devel] Compile-Time Reduction

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

In the same line as my previous message, I have made a simple step
that also greatly reduces compile times now with the tag dispatch
mechanism. With my recent change: http://goo.gl/4A5I I was able to
reduce the compile time of the tests with just using a simple
technique for compile-time "type erasure" to avoid the excessive
template instantiations throughout the library with regards to tags.
In the commit message I explain what I did and how it affects compile
times immensely. I'm copying the commit message here for posterity and
feedback:

--8<---

Compile-time Reduction Techniques

This commit hilights the effect of hiding the MPL details into the
base class instead of a typedef. Instead of just a typedef, use
Boost.MPL metafunctions as base classes. i.e. instead of:

  typedef typename mpl::inherit_linearly<...>::type tag_name;

Do this instead:

  struct tag_name : mpl::inherit_linearly<...>::type {};

This then makes the tag back into an opaque type that the
compiler doesn't have to keep instantiating over and over again
in the cases where the tag is used.

Also because all the metafunctions deal with opaque tags and whether
they inherit from specific root/base tags, then the compile times are
greatly reduced. You can call this type erasure at compile-time using
OOP facilities.

--8<---

Let me know if this helps, if anybody can measure the difference
between 0.7 and the latest in 0.8-devel, that would greatly be
appreciated as well. :)

Have a good one guys!

-- 
Dean Michael Berris
deanberris.com

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

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

On Tue, Oct 26, 2010 at 2:59 AM, Glyn Matthews <gly...@gm...> wrote:
> Hi,
>
> On 25 October 2010 16:32, Nelson, Erik - 2 <eri...@ba...>
> wrote:
>>
>> > Dean Michael Berris wrote on Monday, October 25, 2010
>>
>> > Now there are still a lot of other things I can do to start reducing
>> > compile-times. One is incorporating precompiled headers into the
>> > build, and start pre-compiling almost every single header in the
>> > library.
>>
>> Pre-compiled headers seem like they are going to be a mess, and
>> conceptually similar to going to a non-header-only implementation.  I
>> like the idea of header-only, but maybe a more library-based one would
>> help the compile time.
>
> I agree with this point.  IMO, although I agree that the header-only
> approach has merits, it seems that since we're already requiring that users
> link against Boost's system, regex and date_time libraries, we don't seem to
> be gaining much from this approach anyway.

Actually, I'll work on removing the dependency on Boost.Regex soon and
use Boost.Xpressive instead to remove the link-time requirement to it.
Date_time also has an option to inline everything (IIRC) while
Boost.System will get a macro option to "inline" it.

So pretty soon cpp-netlib can really be header-only depending on Boost.

> Including the compile time
> problem and making cpp-netlib strictly being header-only has very few
> benefits.  I would suggest a better use of our focus should be on
> portability.

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?

> Additionally, I have been doing a lot of development in embedded systems,
> where the long compile times and large binaries that are generated pretty
> much rules out using cpp-netlib.  This is a shame, because this is an area
> where cpp-netlib can provide a lot of benefits to developers.
>

Are you not stripping the binaries created by cpp-netlib? In Debug
mode, yes you will have problems with the debugging symbols eating up
the output binary.

Also, since we still depend on Boost.Lexical_cast that does depend on
the STL io streams library, that will cause the binaries to be pretty
large. We might want to try using Jeroen's construe_cast in places
where we use lexical_cast.

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

>>
>> > Has anyone played around with CMake and how to make precompiled
>> > headers part of the build process? I have seen some Google results on
>> > the matter but I currently have no time/patience to muck around with
>> > that.
>> >
>>
>> Nothing else in Boost requires CMake, as far as I know.  Boost-devel has
>> had some rumblings about a change, but right now Boost.Build is the
>> Boost standard.
>
> Sadly ;)
>

Yeah, it is sad. :D

>>
>> > I'm nearing the completion of the asynchronous server that invokes
>> > request handlers in a thread pool and although the compile times have
>> > been reduced in the HTTP client side of things I would really
>> > appreciate some CMake kung-fu from people on the list to incorporate
>> > precompiled-headers (so that we can make that part of the install step
>> > in 0.8).
>> >
>>
>> Compile time *is* an important issue, but the beauty of a header library
>> is that there is no install step- you just copy the files into your
>> directory tree.
>
> But there is an install step, because of the dependencies that cpp-netlib
> has - and will have: in developing the XMPP client I'll be linking to an XML
> parser library and TLS library.  Other protocol implementations will bring
> other dependencies and we'll have to deal with those too.

Yeah, this is going to be the test of having an install step. :D

> Regards,

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). :)

-- 
Dean Michael Berris
deanberris.com

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

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

On Mon, Oct 25, 2010 at 10:32 PM, Nelson, Erik - 2
<eri...@ba...> wrote:
>> Dean Michael Berris wrote on Monday, October 25, 2010
>> ... I've made some steps to start
>> reducing the compile-times of release 0.8. One of the first casualties
>> in the compile-time reduction effort is the Boost.Concept_check stuff
>> on the fundamental accessors/wrappers.
>>
>
> Just to throw it out there, maybe some of this could be controlled with
> a BOOST_CPP_NETLIB_COMPILE_FAST macro, enabling it to be optional.
>

Actually there's already a way to disable the concept checking parts
with a Macro. My objection to yet another preprocessor macro is that
the code gets pretty ugly -- look at the client switching for
BOOST_NETWORK_ENABLE_HTTPS to see what I mean.

The reason also that these concept checks are removed from the
fundamental accessors is that because the concept checks are meant to
be applied to algorithms. In my head the only algorithms that can be
applied to messages at the moment are:

1. Rendering
2. Transformations
3. Adaptations

Algorithms for Rendering are still embedded in the client
implementations. I'm seeing a need for a render(...) algorithm that
deals with concepts instead so that we can abstract out the rendering
of messages based on their protocol/domain.

I haven't removed the concepts, I just removed the concept checks on
the fundamental accessors -- like source, destination, headers, and
body -- because they tend to be recursive and introduce all kinds of
header include ordering hell. :D

>> Now there are still a lot of other things I can do to start reducing
>> compile-times. One is incorporating precompiled headers into the
>> build, and start pre-compiling almost every single header in the
>> library.
>
> Pre-compiled headers seem like they are going to be a mess, and
> conceptually similar to going to a non-header-only implementation.  I
> like the idea of header-only, but maybe a more library-based one would
> help the compile time.
>

Well, not really. Let me explain why.

First, the precompiled headers will only be built if the compiler
supports it. This means for compilers that don't support precompiled
headers, there's no effect.

Second, the precompiled headers will be placed in the same directory
as where the original header is placed.

Third, this helps a lot in development mode. Having precompiled
headers while developing a header-only library is a good way to cut
down compile times immensely.

Having precompiled headers around is not the same as building
something and linking against it. The reason I didn't want to build
external libraries is so that there's no ABI compatibility issues to
take care of when doing releases. Precompiled headers don't impose
this problem.

>> Has anyone played around with CMake and how to make precompiled
>> headers part of the build process? I have seen some Google results on
>> the matter but I currently have no time/patience to muck around with
>> that.
>>
>
> Nothing else in Boost requires CMake, as far as I know.  Boost-devel has
> had some rumblings about a change, but right now Boost.Build is the
> Boost standard.
>

Well there is a Boost mirror where everything is in CMake -- it's
hosted on GitHub, maintained by the ryppl folks.

The reason I'm using CMake for development is because it's just way
faster to start building things compared to using bjam and
Boost.Build. Having to wait 1 minute before anything gets compiled is
not a good way of spending that time. ;)

Of course at this time Boost.Build is still supported. I just like to
use CMake locally for testing.

>> I'm nearing the completion of the asynchronous server that invokes
>> request handlers in a thread pool and although the compile times have
>> been reduced in the HTTP client side of things I would really
>> appreciate some CMake kung-fu from people on the list to incorporate
>> precompiled-headers (so that we can make that part of the install step
>> in 0.8).
>>
>
> Compile time *is* an important issue, but the beauty of a header library
> is that there is no install step- you just copy the files into your
> directory tree.
>

Yeah, but... if you get the best of both worlds with precompiled
headers -- you just copy them along with the files when you "install"
-- then I don't see why trying precompiled headers would be a bad
thing for a header-only library.

Having precompiled headers is really going to be transparent to the
users of the library, because if the compiler they're using supports
them then there's an advantage. Otherwise, no disadvantage.

Also, Boost has an "install" step which places the headers and all
other built libraries into certain places. Integrating with the
"install" step of Boost will have to be done in the Boost.Build files
anyway. ;) Just sayin'... precompiled headers make sense for
header-only libraries. :D

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] cpp-netlib 0.8 Target Deliverables

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

On Tue, Oct 26, 2010 at 3:17 AM, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean,
>
> On 18 October 2010 19:12, Dean Michael Berris <mik...@gm...>
> wrote:
>>
>> As always, thanks again for the support and I look forward to your
>> contributions to release 0.8.
>>
>
> Do you think we're still on schedule for the 1st week of November? :)  I can
> tell you now that the XMPP client won't be ready...

Ah, that's alright.

The server parts will be ready by 1st week of November. I'm getting to
the end of the asynchronous server refactoring as well as the thread
pool implementation. Some of the enhancements may not be ready by
then.

I'll be perfectly happy with releasing an improved server for 0.8 or
just calling it 0.7.1 might be better. I really want to see both the
improved MIME and XMPP implementations in cpp-netlib before we submit
for review/inclusion in Boost for December.

Worst case scenario is we push the release back by mid-November, but
something should be released in November for the December submission
to Boost. :)

-- 
Dean Michael Berris
deanberris.com

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

[Glyn M. <gly...@gm...>]

On 25 October 2010 21:20, Nelson, Erik - 2
<eri...@ba...>wrote:

> >>Erik Nelson wrote:
> >>Compile time *is* an important issue, but the beauty of a header library
> >>is that there is no install step- you just copy the files into your
> >>directory tree.
>
> >Glyn Matthews wrote:
> >But there is an install step, because of the dependencies that cpp-netlib
> has - and will have: in developing the XMPP client I'll be linking to an XML
> parser >library and TLS library.  Other protocol implementations will bring
> other dependencies and we'll have to deal with those too.
>
> Right now, the only required dependency that cpp-netlib has is boost,
> right?  All I did to start using it was to copy it into my boost
> distribution.  Granted, boost has an install step, but incrementally adding
> cpp-netlib (or updating to a newer version) just means copying header files
> right now.  That makes it very easy to install/upgrade (unless you don't
> have boost yet).
>
>
Right now, yes.  And that's OK if you're already familiar with Boost (which
is not always the case).  But my main objection was motivated by trying to
use dependencies outside Boost such as XML or cryptography libraries (I'd
love to see Boost.XML or Boost.Crypto but we can't wait for these).  CMake
helps a lot here but it's easy to imagine that as the project grows the
install/upgrade procedure needs to be managed very carefully too.  IMO,
libraries ought to be preferred to PCHs in this case.

As a side note, maybe I can advertise what I've started for the XMPP
client: http://github.com/glynos/cpp-netlib/tree/xmpp to let others know
what kind of issues I am facing, and maybe I ought to start a new discussion
to make progress on this.

G

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

[Nelson, E. - 2 <eri...@ba...>]

>>Erik Nelson wrote:
>>Compile time *is* an important issue, but the beauty of a header library
>>is that there is no install step- you just copy the files into your
>>directory tree.

>Glyn Matthews wrote:
>But there is an install step, because of the dependencies that cpp-netlib has - and will have: in developing the XMPP client I'll be linking to an XML parser >library and TLS library.  Other protocol implementations will bring other dependencies and we'll have to deal with those too.

Right now, the only required dependency that cpp-netlib has is boost, right?  All I did to start using it was to copy it into my boost distribution.  Granted, boost has an install step, but incrementally adding cpp-netlib (or updating to a newer version) just means copying header files right now.  That makes it very easy to install/upgrade (unless you don't have boost yet).

Erik

----------------------------------------------------------------------
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. 
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. 

References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: 
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.

Re: [cpp-netlib-devel] cpp-netlib 0.8 Target Deliverables

[Glyn M. <gly...@gm...>]

Hi Dean,

On 18 October 2010 19:12, Dean Michael Berris <mik...@gm...>wrote:

> Hi Guys!
>
> To those new on the mailing list, welcome -- and to those who have
> been lurking or wanting to contribute to the effort but find it really
> hard this lack of direction, then here's your chance.
>
> As most of you already know I'm working on cpp-netlib full-time now.
> No I still don't have work, so I'm making use of my time in between
> finding work to work on cpp-netlib and move it closer to something
> worth submitting into Boost by December this year (yes, 2010). So I'm
> sending my Google Task list for cpp-netlib to the list so everyone
> knows what to expect from 0.8.
>
> I'll also be creating issues and Wiki pages on the official project
> repository at http://github.com/cpp-netlib/cpp-netlib. From now on,
> only experimental "work-in progress" stuff goes onto my repository
> (and those pull requests from others who want to join the effort
> should still be sent to my repository) while the "stable" and
> "milestone" achievements get pushed to the official repo as soon as
> they are done.
>
> If you have any questions or would like clarifications, please feel
> free to send them in through the mailing list. :D
>
> --8<-----------
>
> Release 0.8 -- Target is 1st Week of November
>        Integrate XMPP Implementation from Glyn
>        Refactor HTTP Client Constructor to use Boost.Parameter
>        Callback thread pool
>                Configurable number of threads
>                Taken in as constructor parameter to asynchronous HTTP
> clients
>        Implement Callback-based HTTP Client API
>        Streaming HTTP Client API
>                Implement a basic_response<> which has a
> boost::asio::iostream bound
> to a socket for the body
>                Implement a basic_request<> which has a stream for the body
>                client.get(request, callback) where callback is of signature
> void(basic_response<Tag>)
>                client.put(request) where body(request) models an
> InputStream
>        Server Handler Facade
>                CRTP to provide default implementation for PUT, POST, GET,
> and HEAD handlers
>                Simplify parameter and header parsing
>                Simplify parameter validation and requirement specification
>        Web Service Framework
>                Dynamic Handler Registration
>                Path Routing (regex)
>                Request Normalization
>        HTTP Server Handler Work Pool
>                Implement a work pool to handle requests
>                Implement a basic_request<> that has a stream for the body
>                Implement a http_connection<> that exposes asynchronous
> routines for output
>                        Expose a set_headers function that takes a range of
> pair<string,string> elements and writes that out through the HTTP
> connection
>                        Expose a write function that takes a range as input
> and
> asynchronously sends the data through the HTTP connection
>                        Expose a close function that closes the connection
> from the server's end
>        Implement a basic_server<> that requires the handler type to
> override
> the function call operator and take a basic_request<> and an
> http_connection<> as parameters
>
> --8<-----------------
>
> As always, thanks again for the support and I look forward to your
> contributions to release 0.8.
>
>
Do you think we're still on schedule for the 1st week of November? :)  I can
tell you now that the XMPP client won't be ready...
G



> --
> Dean Michael Berris
> deanberris.com
>
>
> ------------------------------------------------------------------------------
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich applications that run
> across multiple browsers and platforms. Download your free trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

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

[Glyn M. <gly...@gm...>]

On 25 October 2010 20:59, Glyn Matthews <gly...@gm...> wrote:

> Hi,
>
> <snip />

> Regards,
> Glyn
>
>
P.S. this is related to an issue that was created on Github:
http://github.com/cpp-netlib/cpp-netlib/issues#issue/20

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

[Glyn M. <gly...@gm...>]

Hi,

On 25 October 2010 16:32, Nelson, Erik - 2
<eri...@ba...>wrote:

> > Dean Michael Berris wrote on Monday, October 25, 2010
> > ... I've made some steps to start
> > reducing the compile-times of release 0.8. One of the first casualties
> > in the compile-time reduction effort is the Boost.Concept_check stuff
> > on the fundamental accessors/wrappers.
> >
>
> Just to throw it out there, maybe some of this could be controlled with
> a BOOST_CPP_NETLIB_COMPILE_FAST macro, enabling it to be optional.


> > Now there are still a lot of other things I can do to start reducing
> > compile-times. One is incorporating precompiled headers into the
> > build, and start pre-compiling almost every single header in the
> > library.
>
> Pre-compiled headers seem like they are going to be a mess, and
> conceptually similar to going to a non-header-only implementation.  I
> like the idea of header-only, but maybe a more library-based one would
> help the compile time.
>

I agree with this point.  IMO, although I agree that the header-only
approach has merits, it seems that since we're already requiring that users
link against Boost's system, regex and date_time libraries, we don't seem to
be gaining much from this approach anyway.  Including the compile time
problem and making cpp-netlib strictly being header-only has very few
benefits.  I would suggest a better use of our focus should be on
portability.

Additionally, I have been doing a lot of development in embedded systems,
where the long compile times and large binaries that are generated pretty
much rules out using cpp-netlib.  This is a shame, because this is an area
where cpp-netlib can provide a lot of benefits to developers.


>
> > Has anyone played around with CMake and how to make precompiled
> > headers part of the build process? I have seen some Google results on
> > the matter but I currently have no time/patience to muck around with
> > that.
> >
>
> Nothing else in Boost requires CMake, as far as I know.  Boost-devel has
> had some rumblings about a change, but right now Boost.Build is the
> Boost standard.
>

Sadly ;)


>
> > I'm nearing the completion of the asynchronous server that invokes
> > request handlers in a thread pool and although the compile times have
> > been reduced in the HTTP client side of things I would really
> > appreciate some CMake kung-fu from people on the list to incorporate
> > precompiled-headers (so that we can make that part of the install step
> > in 0.8).
> >
>
> Compile time *is* an important issue, but the beauty of a header library
> is that there is no install step- you just copy the files into your
> directory tree.
>

But there is an install step, because of the dependencies that cpp-netlib
has - and will have: in developing the XMPP client I'll be linking to an XML
parser library and TLS library.  Other protocol implementations will bring
other dependencies and we'll have to deal with those too.

Regards,
Glyn

Re: [cpp-netlib-devel] Boost-Version

[Glyn M. <gly...@gm...>]

Hi Richard,

On 25 October 2010 18:45, Richard Klemm <kle...@gm...> wrote:

> Hey List,
>
> I'm trying to update to Version 0.7, but it's giving me:
> #include <boost/range/algorithm/transform.hpp> missing.
>
> Looking at
> http://www.boost.org/doc/libs/1_42_0/libs/range/doc/headers.html
> (or /usr/include/boost/range )
>
> and
>
>
> http://www.boost.org/doc/libs/1_43_0/libs/range/doc/html/range/library_headers/algorithm.html
>
> , it seems that header has been introduced with Boost 1.43.
>
> However, http://cpp-netlib.github.com/getting_started.html#getting-boost
> states that 1.41+ should be fine.
>
> I'm assuming the docs are out of date, otherwise a hint at what I could
> be doing wrong is appreciated.
>
>
Yeah, the docs weren't sufficiently proof-read before the release...

Can you create an issue: http://github.com/cpp-netlib/cpp-netlib/issues ?

Thanks,
Glyn

Re: [cpp-netlib-devel] Boost-Version

[Steve O. <st...@so...>]

Hey Richard, I suggest you get the latest Boost version which is 1.44. Probably the documentation 
for cpp-netlib should be updated accordingly.

Steve Obbayi
Software  Developer

----- Original Message -----
From: "Richard Klemm" <kle...@gm...>
To: "rking Library Developers Mailing List" <cpp...@li...>
Sent: Monday, October 25, 2010 12:45:27 PM GMT -05:00 US/Canada Eastern
Subject: [cpp-netlib-devel] Boost-Version

Hey List,

I'm trying to update to Version 0.7, but it's giving me:
#include <boost/range/algorithm/transform.hpp> missing.

Looking at
http://www.boost.org/doc/libs/1_42_0/libs/range/doc/headers.html
(or /usr/include/boost/range )

and

http://www.boost.org/doc/libs/1_43_0/libs/range/doc/html/range/library_headers/algorithm.html

, it seems that header has been introduced with Boost 1.43.

However, http://cpp-netlib.github.com/getting_started.html#getting-boost
states that 1.41+ should be fine.

I'm assuming the docs are out of date, otherwise a hint at what I could
be doing wrong is appreciated.

Thanks for the good work,

Richard




------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Cpp-netlib-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel

[cpp-netlib-devel] Boost-Version

[Richard K. <kle...@gm...>]

Hey List,

I'm trying to update to Version 0.7, but it's giving me:
#include <boost/range/algorithm/transform.hpp> missing.

Looking at
http://www.boost.org/doc/libs/1_42_0/libs/range/doc/headers.html
(or /usr/include/boost/range )

and

http://www.boost.org/doc/libs/1_43_0/libs/range/doc/html/range/library_headers/algorithm.html

, it seems that header has been introduced with Boost 1.43.

However, http://cpp-netlib.github.com/getting_started.html#getting-boost
states that 1.41+ should be fine.

I'm assuming the docs are out of date, otherwise a hint at what I could
be doing wrong is appreciated.

Thanks for the good work,

Richard

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

[Nelson, E. - 2 <eri...@ba...>]

> Dean Michael Berris wrote on Monday, October 25, 2010
> ... I've made some steps to start
> reducing the compile-times of release 0.8. One of the first casualties
> in the compile-time reduction effort is the Boost.Concept_check stuff
> on the fundamental accessors/wrappers.
> 

Just to throw it out there, maybe some of this could be controlled with
a BOOST_CPP_NETLIB_COMPILE_FAST macro, enabling it to be optional.

> Now there are still a lot of other things I can do to start reducing
> compile-times. One is incorporating precompiled headers into the
> build, and start pre-compiling almost every single header in the
> library.

Pre-compiled headers seem like they are going to be a mess, and
conceptually similar to going to a non-header-only implementation.  I
like the idea of header-only, but maybe a more library-based one would
help the compile time.

> Has anyone played around with CMake and how to make precompiled
> headers part of the build process? I have seen some Google results on
> the matter but I currently have no time/patience to muck around with
> that.
> 

Nothing else in Boost requires CMake, as far as I know.  Boost-devel has
had some rumblings about a change, but right now Boost.Build is the
Boost standard.

> I'm nearing the completion of the asynchronous server that invokes
> request handlers in a thread pool and although the compile times have
> been reduced in the HTTP client side of things I would really
> appreciate some CMake kung-fu from people on the list to incorporate
> precompiled-headers (so that we can make that part of the install step
> in 0.8).
> 

Compile time *is* an important issue, but the beauty of a header library
is that there is no install step- you just copy the files into your
directory tree.

Erik

----------------------------------------------------------------------
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. 
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. 

References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: 
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.

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

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

Hi Guys,

So I'm on a meagerly-powered machine and I cannot buy a new one until
I get a job (my wife insists :D) so I've made some steps to start
reducing the compile-times of release 0.8. One of the first casualties
in the compile-time reduction effort is the Boost.Concept_check stuff
on the fundamental accessors/wrappers.

Now there are still a lot of other things I can do to start reducing
compile-times. One is incorporating precompiled headers into the
build, and start pre-compiling almost every single header in the
library.

Has anyone played around with CMake and how to make precompiled
headers part of the build process? I have seen some Google results on
the matter but I currently have no time/patience to muck around with
that.

I'm nearing the completion of the asynchronous server that invokes
request handlers in a thread pool and although the compile times have
been reduced in the HTTP client side of things I would really
appreciate some CMake kung-fu from people on the list to incorporate
precompiled-headers (so that we can make that part of the install step
in 0.8).

Thanks in advance and I hope to hear your comments/feedback.

The relevant change in 0.8-devel to remove the Boost.Concept_check
stuff on the fundamental message accessors is here:

  http://goo.gl/orfM

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] FW: body copies on http::client::post (was:RE: Poll: Next Features to Implement)

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

Hi Mark,

On Mon, Oct 25, 2010 at 7:41 AM, Mark Wright
<mar...@in...> wrote:
> Hi,
>
> flex_string included in Loki, and hidden away in the implementation
> of one of the Boost libraries, is a policy based design string class
> described in Modern C++ Design by Alexandrescu:
>
> http://www.drdobbs.com/184403784
>

Cool, thanks for the link.

I myself have some issue with policy-based design as it puts too much
of a burden on the user and implementer in case:

1) The user wants to choose a different policy or mix of policies from
the default.
2) The implementer wants to add new policies and/or change the
internal details of the implementation.

The reason why cpp-netlib has just a tag dispatch mechanism and has
all traits/metafunctions deal with the tags is to put the burden on
the implementers/extenders instead of the users. This is a different
tradeoff, and even if we do use policy-based design internally, the
users don't ever have to see these policies -- they just choose which
tag or combination of tags they want.

> Its neat as the user can choose whether they want thread locking
> or not, as well as the copy semantics.
>

Yeah, but that's overkill really for what I want to do -- I just want
a string that's immutable. :)

> Thanks, Mark

Thank you too Mark. :)

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] FW: body copies on http::client::post (was:RE: Poll: Next Features to Implement)

[Mark W. <mar...@in...>]

Hi, 
 
flex_string included in Loki, and hidden away in the implementation 
of one of the Boost libraries, is a policy based design string class 
described in Modern C++ Design by Alexandrescu: 
 
http://www.drdobbs.com/184403784 
 
Its neat as the user can choose whether they want thread locking 
or not, as well as the copy semantics. 
 
Thanks, Mark 
 
 

Re: [cpp-netlib-devel] FW: body copies on http::client::post (was: RE: Poll: Next Features to Implement)

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

Hi Kim,

Sorry it took me a while to respond, I've been wrestling with OS
upgrade issues in my quest to try out GCC 4.5. See some of my thoughts
below.

On Fri, Oct 22, 2010 at 1:59 PM, Kim Gräsman <kim...@gm...> wrote:
> Hi Dean,
>
> On Fri, Oct 22, 2010 at 07:50, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>> Someday when my development machine, time, and other things permit, I
>> might work on an immutable string class -- similar to what the D
>> programming language has -- as a replacement to std::string. Although
>> std::string is the standard, I don't mind writing a better string
>> class at some point that "does the right thing".
>
> I went looking a couple of months ago and found two -- one STL-style
> and one less idiomatic:
>

Cool, thanks!

> - http://conststring.sourceforge.net/

This one looks interesting. I wonder if it uses a shared_ptr
underneath though. I'll take a look at that implementation to see if
it fits with what I was thinking about.

> - http://www.codeproject.com/KB/string/fix_str.aspx
>

Yeah, this one isn't so idiomatic. I like the first one better.

> Maybe you can get some ideas from there.
>

Definitely, thanks for the pointers! :)

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] FW: body copies on http::client::post (was: RE: Poll: Next Features to Implement)

[Kim G. <kim...@gm...>]

Hi Dean,

On Fri, Oct 22, 2010 at 07:50, Dean Michael Berris
<mik...@gm...> wrote:
>
> Someday when my development machine, time, and other things permit, I
> might work on an immutable string class -- similar to what the D
> programming language has -- as a replacement to std::string. Although
> std::string is the standard, I don't mind writing a better string
> class at some point that "does the right thing".

I went looking a couple of months ago and found two -- one STL-style
and one less idiomatic:

- http://conststring.sourceforge.net/
- http://www.codeproject.com/KB/string/fix_str.aspx

Maybe you can get some ideas from there.

Cheers,
- Kim

Re: [cpp-netlib-devel] FW: body copies on http::client::post (was: RE: Poll: Next Features to Implement)

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

On Fri, Oct 22, 2010 at 3:17 AM, Kim Gräsman <kim...@gm...> wrote:
> Hi Dean,
>
> On Thu, Oct 21, 2010 at 06:34, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>>> So, I think there's merit to not expecting COW from std::string.
>>>
>>
>> Yup, but I haven't been writing cpp-netlib to expect COW. I just think
>> that removing copies can be done later on. ;)
>
> Right, I just wanted to make sure you were aware of the reputation of
> std::string with COW. It's not great ;-)
>

Yeah, I've been bitten by those bugs too. :D

> That said, maybe it's not such a bad idea. Multiple threads make it
> harder to get right, but perhaps not intrinsically worse than heap
> allocation + copy. I'll have to mull on that for a while.
>

Yup, it's no worse than an allocation + copy. You can't do the
allocation and copy atomically either, which means the overhead of
locking and things like that may be higher than the cost of COW.

Someday when my development machine, time, and other things permit, I
might work on an immutable string class -- similar to what the D
programming language has -- as a replacement to std::string. Although
std::string is the standard, I don't mind writing a better string
class at some point that "does the right thing".

Alas, I'm dealing with the SNAFU that is upgrading Ubuntu 10.04 to
10.10. nvidia+xorg-1.9 do not play nice yet. :(

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] FW: body copies on http::client::post (was: RE: Poll: Next Features to Implement)

[Kim G. <kim...@gm...>]

Hi Dean,

On Thu, Oct 21, 2010 at 06:34, Dean Michael Berris
<mik...@gm...> wrote:
>
>> So, I think there's merit to not expecting COW from std::string.
>>
>
> Yup, but I haven't been writing cpp-netlib to expect COW. I just think
> that removing copies can be done later on. ;)

Right, I just wanted to make sure you were aware of the reputation of
std::string with COW. It's not great ;-)

That said, maybe it's not such a bad idea. Multiple threads make it
harder to get right, but perhaps not intrinsically worse than heap
allocation + copy. I'll have to mull on that for a while.

Cheers,
- Kim