Main  /  Edit version 4  /  Edit version 5  /   /  Users Area

Difference "What is new in 2.0.0" ver. 4 versus ver. 5


## 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
## Breaking Changes
- All references to `std::auto_ptr` were replaced by `std::unique_ptr` since `auto_ptr` was deprecated and removed in C++17.
- Booster API become alias for std equivalents
- `shared_ptr`, `weak_ptr`, `enable_shared_from_this`
- `static_pointer_cast`, `dynamic_pointer_cast`, `const_pointer_cast`
- all `booster::system` now refers to std system library: `error_category`, `system_category`, `error_code`, `system_error`
- `function`
- `thread`, `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_cc` now uses `std::begin/end`, `std::rbegin/rend` to iterate over containers
- Now it is possible to use `std::regex` instead 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.
- `zlib` dependency optional it does not remove file based session storage.
- Atomic counter now uses `std::atomic`
- Many (but not all) APIs that require dynamic parameters size moved 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::regex` there were several reasons:
1. 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`.
2. `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.
3. Performance of PCRE is much better
4. It was impossible to use `std::smatch`/`std::cmatch` with 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 standard `std::cmatch`. This is significant limitation of the standard C++ library.
Also I added an option to use `std::regex` engine inside `booster::regex` to simplify build on some environments and reduce dependency on external libraries.
Also I added an option to use `std::regex` engine inside `booster::regex` to simplify build on some environments and reduce dependency on external libraries. But outside the API of `booster::regex` remained exactly the same.
- `std::shared_mutex`, `std::recursive_shared_mutex` - also C++14 provides `std::shared_mutex` it lacks support of recursive one. So I decided to keep existing implementation and stick to C++11
- Use of variadic templates in `url_mapper` and `url_dispatcher`. Also C++11 variadic templates are fantastic feature some of the tasks remained quite complicated, for example implementing `sum(int... args)` isn't something simple at all (`url_dispatcher` need 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


CppCMS is a web development framework for performance demanding applications.

Support This Project Logo

Поддержать проект

CppCMS needs You


Main Page

Valid CSS | Valid XHTML 1.0