What is new in 2.0.0
General
This is CppCMS future proofing release:
- CppCMS moved to C++11 by default and now requires a compiler that supports it
- Templates compiler and unit-tests support both python 2.7 and python >= 3.5
- Lots of booster API had become an alias to C++11 libraries
Improved HTTP support - now it is first class citizen and not a debugging tool over CGI protocol. The improvements include:
- HTTP/1.1
- keep-alive support
- Request pipelining
- Chunked transfer encoding
- HTTP response now generated directly rather than being converted from CGI output stream.
- Performance improvement in environment variables handling and HTTP general
Breaking Changes
- All references to
std::auto_ptrwere replaced bystd::unique_ptrsinceauto_ptrwas deprecated and removed in C++17. Booster API become alias for std equivalents
shared_ptr,weak_ptr,enable_shared_from_thisstatic_pointer_cast,dynamic_pointer_cast,const_pointer_cast- all
booster::systemnow refers to std system library:error_category,system_category,error_code,system_error functionthread,mutex,recursive_mutex,conditional_variable,unique_lock
Since some interfaces of C++ standard library functions may differ from ones appear in booster these changes may break some code
Additional Changes
cppcms_tmpl_ccnow usesstd::begin/end,std::rbegin/rendto iterate over containers- Now it is possible to use
std::regexinstead of PCRE, it has some performance penalty and lack UTF-8 support but it is good option to eliminate some dependencies - for example on Windows. zlibdependency optional it does not remove file based session storage.atomic_counter- usesstd::atomicinternally- Many (but not all) APIs that require dynamic parameters size are now using to C++11 variadic templates
Requirements Updates
- C++11 enabled compiler, tested on gcc>=4.8, clang >=3.8, msvc 2017 (2015 probably will work as well)
- Python 2.7 or >= 3.5
- Relaxed requirement of PCRE
- Relaxed requirement of zlib
Things Not Taken from Standard Library and C++11
booster::regexthere were several reasons:- CppCMS uses PCRE that allows to refer to a string as UTF-8, for example matching "." with code point rather than byte. It is a useful functionality that absent from
std::regex. std::regex- level of implementation is still quite poor on some older C++11 compilers, for example gcc-4.8 does not support them at all, clang-4.0/libc++ fails to match properly some patterns.- Performance of PCRE is much better
- It was impossible to use
std::smatch/std::cmatchwith custom regex engine since they do not provide an API to build them externally so I couldn't just create PCRE based regular expression with standardstd::cmatch. This is significant limitation of the standard C++ library.
Also I added an option to use
std::regexengine insidebooster::regexto simplify build on some environments and reduce dependency on external libraries. But outside the API ofbooster::regexremained exactly the same.- CppCMS uses PCRE that allows to refer to a string as UTF-8, for example matching "." with code point rather than byte. It is a useful functionality that absent from
std::shared_mutex,std::recursive_shared_mutex- also C++14 providesstd::shared_mutexit lacks support of recursive one. So I decided to keep existing implementation and stick to C++11Use of variadic templates in
url_mapperandurl_dispatcher. Also C++11 variadic templates are fantastic feature some of the tasks remained quite complicated, for example implementingsum(int... args)isn't something simple at all (url_dispatcherneed ints)Performing some per-parameter operations and passing them as pack to another function is complex as well. It was somewhat addressed in C++17 but still the benefit of re-implementing existing and working solution is minute in comparison to complexity of implementation and finally the code readability and maintainability
