Re: [Cppcms-users] cppcms unclear issues and philosophy

[Artyom B. <art...@ya...>]

>________________________________
> From: Ovanes Markarian <om_...@ke...>
>To: cpp...@li... 
>Sent: Sunday, June 10, 2012 9:41 PM
>Subject: [Cppcms-users] cppcms unclear issues and philosophy
> 
>Hello *,

First of all please register to cppcms-users mailing list so I don't
have to moderate comments


>
> My main consideration is the faked
> boost lib: booster and dependencies to some C stuff like PCRE...


I'll explain.

booster is not "fake" boost library it is a subset of essential
C++0x/Boost like interface needed for CppCMS.

You can use freely any Boost or C++11 library with it
without any problem.

Why? ABI Stability

I can't use Boost with CppCMS because it breaks its interfaces 

every 3 months - both ABI and what is even harder API!

This is something I can't afford. There are dozens of cases
where programs become broken because some 3rd part library
used different version of boost then the main program and more 

and more


Read this discussion for more details:

  http://thread.gmane.org/gmane.comp.lib.boost.devel/204117



Stable ABI allows a user for example update a CppCMS library
with a hostfix problem or just update to new version without
recompiling anything.



> My
> main point, is that the project will be written in C++11. Using Clang
>3.0 I was unable to compile CppCMS with C++11 enabled, the main
>problems were in the booster lib.


1. You don't need to compile libcppcms/libbooster with C++11 enabled to use
   it with C++11 enabled.
2. Clang still crashes on some trivial stuff in C++11 mode!



> Another question is why PCRE was
> used here, when boost has a regex lib, which was used as a base for
> C++11 regex lib? Here one could easily exchange the namespaces and use
> a multi-platform regexes implemented by the new C++ standard without
> any need to have PCRE or use boost again.

Good point:

There is no a single mainstream C++11 compiler that actually implements 

C++11 regex! (neither gcc nor msvc-10)

Boost.Regex is great library but it is not ABI friendly... So
if I just "copy" boost.regex to booster I will not be able
to fix bugs easily.

Another goodies you get with PCRE are:

1. Very fast copy (as fast as memcpy)
2. Support of JIT (yeah...)


> The same applies to faked
>booster::function. What if I want to use C++11 lambdas, are they going
>to nicely play with them?

Yes of course, you can even assign (std/boost)::function to booster::function
and vise versa


> I know that boost::function is the base of
> std::function which really greatly plays with lambdas etc. The same
> applies to threading lib and asio, which is now proposed for C++ TR2.
>

What was proposed to TR2 is very different from ASIO, so the
thread is different from boost.thread - very different.


Long story short I can tell you a long story about Asio (I use it on dayly basis)
and it is good library but it was hard decision and correct one, small
problems list: fork, detach native socket, stream-socket for TCP!=UNIX
ones, loooooooooooooooooooooooooooong compilation times and more.


>Could you please explain what is the benefit in faking boost

It is not faking. It is taking good interfaces and exposing
them. Booster does not replace boost and not intended to.

But it allows me to create ABI and ABI stable applications which
is impossible to do with Boost


>and let
>the users find out what incompatibilities between booster and boost
>might be there instead of using well established, greatly tested and
>documented boost libs. What is going to happen for example with locale
>lib? Now it is part of boost, will you have a spin off branch of that
>lib in CppCMS or just reference the boost distro?
>

Booster.Locale = Boost.Locale - and it was **designed** with ABI
stability so Booster.Locale would be updated as regularly as Boost.Locale.

Actually Booster.Locale generated from Boost.Locale using a small automatic 

script.



>I can see some benefit for boost in embedded world, but doing web
>development when having unlimited resources on server side, I clearly
>prefer to use boost. Can I somehow disable booster and rely on boost
>where I really feel to be at home?
>

No, you can't because Booster!=Boost. Booster is "fat-free" version
of some boost interfaces, it is much smaller and you can use them both.

You probably know that I'm Boost developer and the author of Boost.Locale.

As boost developer I know its "dark" sides and believe me they aren't pretty.


>I also see that you are some guys going to develop part of boost libs.
>This has IMO implications:
>o It might slow down development of CppCMS if you are always going to
>catch up boost features
>o If you are not going to catch up boost features in booster libs,
>they will diverge and make uses read some more help, what differs
>where.

No. I'm not going to "catch up" Booster needs less then Boost.


>
>I already had a problem building CppCMS when using a cross-compiler. I
>had to cross-compile a bunch of C libs nowhere else used in the
>project.

Give me a favor...

libpcre and zlib are the basic libraries available anywhere.
I'm boost developer and I know how crappy
it is to "cross-compile" and to do _anything_ with Boost.Build
system...



>
>Many thanks for your attention, please don't be insulted by my mail. I
>just want to understand your intentions and see where CppCMS might go
>in the future, since my decision might really make the entire
>development in the company much harder/slower etc.
>


I think this should go to some FAQ. So it is ok.

I'll add few things. The greatest thing about boost and the most
horrible thing about it is that it is cutting edge library.

I have a great experience of having code broken between different
releases of Boost. If you do not limit you project to very narrow
range of Boost libraries and always synchronize yourself
with the latest version you will soon discover that it is 

impossible to upgrade.

I love Boost and and develop for Boost but it does not suit
for stable library development.


So having stable API and ABI helps, and does not make problems
harder.

>

>With Kind Regards,
>Ovanes
>

Regards,
  Artyom