cppcms-users

[Cppcms-users] cppcms unclear issues and philosophy

[Ovanes M. <om_...@ke...>]

Hello *,

I am fairly new to CppCMS and currently evaluate web frameworks to
build scalable website. CppCMS looks very promising to me. I also like
the idea of using modern C++ design in design of CppCMS. Please
forgive my next nasty questions... My main consideration is the faked
boost lib: booster and dependencies to some C stuff like PCRE... 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. 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. The same applies to faked
booster::function. What if I want to use C++11 lambdas, are they going
to nicely play with them? 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.

Could you please explain what is the benefit in faking 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?

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?

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.

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.

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.


With Kind Regards,
Ovanes

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

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

[Ovanes M. <om_...@ke...>]

Artyom,

thanks for your time answering my long email. I have some more comments.

>>________________________________
>> From: Ovanes Markarian <om_cppcms@...>
>>To: cppcms-users@...
>>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
>
Yes, I did it. Waited for about 15 mins to get a reply from the
mailing list... Nothing happened, so I assumed my subscription was OK
and sent the email. Got from the mailing list the OK after about 1
day. Don't know why...

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

Just looked up Clang 3.0 libc++ has it (3.1 respectively as well)
http://llvm.org/svn/llvm-project/libcxx/tags/libcpp-30/include/regex
http://llvm.org/svn/llvm-project/libcxx/tags/libcpp-31/include/regex

GCC 4.6.3 has it (4.7.x respectively as well)
http://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a01192.html

Did not lookup if earlier versions of gcc have the regex support as well.

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

I somehow do not understand how the bugs are now easily fixed? You
still need to issue a new version (or patch) of an internal regex lib.
If PCRE has bugs, why are they easier to fix as the regex in the
boost?

At that point I would like to point out another solution without any regex lib:

I understand your objections, but there would be another workaround...
To let users implement the url dispatcher theirselves. This might
violate DRY, since many users will implement the same class again and
again... May be, it makes sense to introduce the cppcms corelib and
cppcms helper lib for those who wish stability. I personally would
like to use boost::xpressive at all.

>Another goodies you get with PCRE are:
>
>1. Very fast copy (as fast as memcpy)
>2. Support of JIT (yeah...)

And now I came along as a C++ developer and ask: "What happens if PCRE
was unable to internally use heap?" Will cppcms throw a bad_alloc or
what kind of error should I expect. Sure it might be a hypothetical
issue, but how are PCRE errors generally reported. What if regex
compilation failed, since I provided a bad regex, how is that
reported? I did not find the answer in the docs. I know for example
that xpressive will issue a compilation error ;)

Now to the JIT. It seems like being a nice feature, which is executed
once at start up. How much slower is the start up of my application if
JIT is going to be used? According to the first table:

http://sljit.sourceforge.net/pcre.html

JIT seems to make the initial regex compilation on average 20 times
slower. So if I really going to have many URLs or locations, my app
might start 20 times slower. But if all my regex patterns are known at
compile time I prefer xpressive ;)

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

Ok, but as far as I can see boost thread lib tries to catch up with
the standard. On the other hand. Clang 3.1 and GCC 4.7 have support
for major threading features. But here I must agree, if boost catches
up with C++11 the ABI is not going to be stable.

>
>
>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

Ok, I partially agree. But it might be possible to introduce a generic
interface? Ok, compilation times will get longer, but I can personally
live with it. On the other hand, users are free than which lib should
be used. They can use a cppcms helper lib or 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.

Sorry I typed to fast. The sentence should be "I can see some benefit
for boostER in embedded world,..."

How portable are booster interfaces??? What if I decide to use really
strange compiler with a great hardware intended to run my site
infrastructure really efficiently. I known that boost does not provide
the insurance as well, but is there a guarantee, that boost is going
to support at least the same majority of compilers that boost
supports?

>
>You probably know that I'm Boost developer and the author of Boost.Locale.
Yes, I know that. Congratulations, that your lib was accepted! ;)

>
>As boost developer I know its "dark" sides and believe me they aren't pretty.
Yes, I heard about them at BoostCont 2010.

>
>
>>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...
Actually, boost cross-compilation worked like a charm, because it is
self-contained. Once I defined the user.jam everything worked. But
after starting to deal with cppcms, I had one error after another with
the requirement: to introduce more and more C libs into the
cross-compilation toolset and finally after some download sessions and
compilations I got cppcms.



>
>
>
>>
>>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.
Mhh... I use boost since 2004 and as I counted more than 50 libs are
used in the project, we never had these problems. On the other hand, I
don't understand your statement, since boost features Unit Tests. Are
those broken than?

>
>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
>

Thanks for your great answers,
Ovanes

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

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

----- Original Message -----
> From: Ovanes Markarian <om_...@ke...>

>>>  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!
>> Good point:
>>
>> [Snip]
>> 
>> There is no a single mainstream C++11 compiler that actually implements
>> 
>> C++11 regex! (neither gcc nor msvc-10)
> 
> Just looked up Clang 3.0 libc++ has it (3.1 respectively as well)
> http://llvm.org/svn/llvm-project/libcxx/tags/libcpp-30/include/regex
> http://llvm.org/svn/llvm-project/libcxx/tags/libcpp-31/include/regex
> 

libc++ is far from being production ready.... It currently
works only on Mac OS X. I tried to compile it on Linux recently
I did enormous tricks to do it. And still got some problems.


> GCC 4.6.3 has it (4.7.x respectively as well)
> http://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a01192.html
> 
> Did not lookup if earlier versions of gcc have the regex support as well.
> 

Ok... gcc-4.5 had not supported it (it was the last time I checked)
also it seems that gcc-4.6 does supports it. Older version allowed me to compile
the code but the "match result" was always false.

It is good news but I can't relay on it as I support many compilers,
so I'll need to keep PCRE.

Also note... ABI stability - this exactly gives me an ability
to switch the implementation. If I want to I can replace
pcre with std::regex or other engine without affecting ABI!

Anything I need is to replace an opaque class booster::regex::data.

So I can easily remove the dependency on PCRE if the compiler
supports regex.

Actually this may be an action item for next version...

>> 
>> 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.
> 
> I somehow do not understand how the bugs are now easily fixed? You
> still need to issue a new version (or patch) of an internal regex lib.
> If PCRE has bugs, why are they easier to fix as the regex in the
> boost?
> 

Because booster::regex uses pimpl ideom. The implementation details
are hidden. 

every booster class looks like

  class foo {
  public:
     foo();
     ~foo();
     void bar(baz const &);
  private:
     struct data;
     copy_ptr<data> d;
  };

Where data keeps the actual members, this gives me a great flexibility
to fix bugs or even switch implementation without affecting API or ABI.

This is something can't be done with Boost.

This makes the huge difference between two libraries.



> At that point I would like to point out another solution without any regex lib:
> 
> I understand your objections, but there would be another workaround...
> To let users implement the url dispatcher theirselves. This might
> violate DRY, since many users will implement the same class again and
> again... May be, it makes sense to introduce the cppcms corelib and
> cppcms helper lib for those who wish stability. I personally would
> like to use boost::xpressive at all.
> 

Ohhh please don't talk to me about xpressive. It is SLOW to compile
hard to understand to _AVERAGE_ C++ programmer and what is more
important hard to debug.

Also **nothing** prevents from you to create your own dispatcher...

I don't tell my users how to write the code.

>> Another goodies you get with PCRE are:
>> 
>> 1. Very fast copy (as fast as memcpy)
>> 2. Support of JIT (yeah...)
> 
> And now I came along as a C++ developer and ask: "What happens if PCRE
> was unable to internally use heap?" Will cppcms throw a bad_alloc or
> what kind of error should I expect.
> Sure it might be a hypothetical
> issue, but how are PCRE errors generally reported

Take a look on the code, and yes, you'll get bad alloc.

> compilation failed, since I provided a bad regex, how is that
> reported? I did not find the answer in the docs. 

Then you didn't read them...

http://cppcms.com/cppcms_ref/latest/classbooster_1_1regex.html#a7e6af85360eada29c9058621a859edbd

>I know for example
> that xpressive will issue a compilation error ;)
> 
> Now to the JIT. It seems like being a nice feature, which is executed
> once at start up. How much slower is the start up of my application if
> JIT is going to be used? According to the first table:
> 
> http://sljit.sourceforge.net/pcre.html
> 
> JIT seems to make the initial regex compilation on average 20 times
> slower. So if I really going to have many URLs or locations, my app
> might start 20 times slower. But if all my regex patterns are known at
> compile time I prefer xpressive ;)
> 


So create your own dispatcher... Don't ask an average C++ user to use xpressive.


>>>  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.
> 
> Ok, but as far as I can see boost thread lib tries to catch up with
> the standard. On the other hand. Clang 3.1 and GCC 4.7 have support
> for major threading features. But here I must agree, if boost catches
> up with C++11 the ABI is not going to be stable.
> 

std::thread does not include two critical parts:

- shared_mutex
- thread local storage support

This is major drawback for me. I uses it intensively. Also booster
has recursive_shared_mutex that neither boost not std provide.

So no I can't switch booster::thread with std::thread

Also boost - by definition can't be ABI stable and in fact is not ABI 
or API stable.

For example boost.locale was broken in trunk for some period due
to API changes.


>> 
>> 
>> 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
> 
> Ok, I partially agree. But it might be possible to introduce a generic
> interface? 
> Ok, compilation times will get longer, but I can personally
> live with it. On the other hand, users are free than which lib should
> be used. They can use a cppcms helper lib or boost.
> 

No, because if I use boost under the hood user will still have
ABI incompatibilities. For example I use some boost code
under hidden cppcms_boost namespace (boost with renamed namespace)
but it is not exposed and I have to use alternative namespace

Even if boost is not in interface you will have ABI problems
if somebody accidentally uses for example boost.1.46.1 instead
of boost.1.46 that cppcms is compiled with...

Also entire point of ABI stability fails.


>> 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.
> 
> Sorry I typed to fast. The sentence should be "I can see some benefit
> for boostER in embedded world,..."
> 
> How portable are booster interfaces??? What if I decide to use really
> strange compiler with a great hardware intended to run my site
> infrastructure really efficiently. I known that boost does not provide
> the insurance as well, but is there a guarantee, that boost is going
> to support at least the same majority of compilers that boost
> supports?
> 


  http://cppcms.com/files/nightly-build-report.html

And Boost? Boost is not as portable as you may think.

For example boost.thread does not work on SunStudio...
for a loooong time.

Booster is portable if there some problems report
or send patches. In these terms I don't think there is
a big difference between boost and booster +/- some

CppCMS works with gcc>=3.4, MSVC >= 2005 clang >= 2.9
SunStudio >=5.11 and Intel 11

So if you want to tell me that boost is more portable?
I'm not so sure. Most of boost libraries support only
recent compilers, many do not support gcc 3.4

>> 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...
> Actually, boost cross-compilation worked like a charm, because it is
> self-contained. Once I defined the user.jam everything worked. But
> after starting to deal with cppcms, I had one error after another with
> the requirement: to introduce more and more C libs into the
> cross-compilation toolset and finally after some download sessions and
> compilations I got cppcms.
> 

Boost is not self contained and can't be.

Boost.Locale uses ICU
Boost.Iostreams uses zlib.

More than that the 3rd part library detection of Boost is total
crap in comparison to CMake (I know it...)

The only difference between "booster" and "boost" in "cppcms"  context
would be is PCRE and it is not a big deal to compile it
(if it is not already done for you)

>> 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.
> Mhh... I use boost since 2004 and as I counted more than 50 libs are
> used in the project, we never had these problems. On the other hand, I
> don't understand your statement, since boost features Unit Tests. Are
> those broken than?

And I had problems to upgrade from 1.38 to 1.42 of a small project that
used shared_ptr becuase they broken an interface with auto_ptr.

I had to do version dependent compilation in days back to cppcms - 0 that
used boost to use boost.thread with both 1.33.1 and 1.35

Boost.Locale was broken in Boost trunk (!)
because "header-only" part of boost.thread started requiring
boost.system

I can count much more and it was in 1 minute I thought.


> 
> Thanks for your great answers,
> Ovanes
> 

Regards,

Artyom Beilis

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

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

>> GCC 4.6.3 has it (4.7.x respectively as well)
>> http://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a01192.html
>> 
>> Did not lookup if earlier versions of gcc have the regex support as well.
>> 
>
>Ok... gcc-4.5 had not supported it (it was the last time I checked)
>also it seems that gcc-4.6 does supports it. Older version allowed me to compile
>the code but the "match result" was always false.
>

After a little check gcc-4.7 does not support regular expressions yet...

a simple

       regex r("foo");
       char const *b="xfooz";
       char const *e=b+strlen(b);
       std::cout << regex_search(b,e,r) << std::endl;

Prints 0 (of course with boost::regex it prints expected result 1)

So it is too early to remove PCRE

Artyom

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

[Markus R. <us...@ma...>]

Hi!

Artyom Beilis wrote:
> No, because if I use boost under the hood user will still have
> ABI incompatibilities. For example I use some boost code
> under hidden cppcms_boost namespace (boost with renamed namespace)
> but it is not exposed and I have to use alternative namespace

Could you explain why this hidden cppcms_boost namespace is needed? In which
situation does it differ to static linkage?

> Even if boost is not in interface you will have ABI problems
> if somebody accidentally uses for example boost.1.46.1 instead
> of boost.1.46 that cppcms is compiled with...

Of course, but is changing the namespace needed to tackle this issue?

Do you use tools/rename.py for the renaming?

best regards
Markus

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

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

----- Original Message -----
> From: Markus Raab <us...@ma...>
> To: cpp...@li...
> Cc: 
> Sent: Monday, June 18, 2012 11:48 PM
> Subject: Re: [Cppcms-users] cppcms unclear issues and philosophy
> 
> Hi!
> 
> Artyom Beilis wrote:
>>  No, because if I use boost under the hood user will still have
>>  ABI incompatibilities. For example I use some boost code
>>  under hidden cppcms_boost namespace (boost with renamed namespace)
>>  but it is not exposed and I have to use alternative namespace
> 
> Could you explain why this hidden cppcms_boost namespace is needed? In which
> situation does it differ to static linkage?
> 

It is very different. Even if I for example link statically with some boost::foo
it symbol would appear in the code (even if it is not in interface) and if the
application uses boost::foo as well and their ABI is different you would get
a crash because the linker would resolve it to one of the boost::foo's and
the other would be broken.

Same valid for ELF dynamic linking as well.

So the only way to make things safe is to change the namespace name.

Also it does not 100% save you as sometimes in Boost there are
some symbols not-previxed with boost (they are removed from cppcms_boost explicitly)

That is for example what ICU does. All ICU classes are put into icu_xx_yy namespace
with alias namespace icu = icu_xx_yy. All ICU C functions are postfixed with
_xx_yy for example u_foo goes to u_foo_1_49.

This saved me not once when headers were different from the actual library
versions - happens when you tinker with multiple versions.

>>  Even if boost is not in interface you will have ABI problems
>>  if somebody accidentally uses for example boost.1.46.1 instead
>>  of boost.1.46 that cppcms is compiled with...
> 
> Of course, but is changing the namespace needed to tackle this issue?
> 

Unfortunately, Yes. Even boost provides a tool for that - BCP.

> Do you use tools/rename.py for the renaming?
> 

Yes - it is the primary tool. Also its most common use
is to rename boost::locale to booster::locale.

(Also note rename.py predates boost BCP namespace renaming support,
and it works smarter than BCP)

Note, internal cppcms_boost is boost 1.39 with some bug fixes
back-ported from the latest versions.

And because It is not exposed such fixes are not hard.

> best regards
> Markus
>  

Best,

Artyom Beilis
--------------
CppCMS - C++ Web Framework:   http://cppcms.com/
CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/