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