Hartmut Kaiser wrote:
Pavel Vozenilek wrote:
I think Wave should become part of Boost.
I agree. It is an invaluable tool. This would especially be the case if: 1. There is a wave.jam toolset for BBv2. 2. It is easy to chain wave in the build process. That is: exe demo : main.cpp ; # compiler preprocessor exe demo : main.cpp : <preprocessor>wave ; # wave preprocessor
1. Some parts may be separated:
- flex_string may be standalone library
(flex_string.hpp: the link to CUJ HTML page should be replaced to link to Andrei's website, CUJ is accessible to subscribers only).
This was discussed already on this list in conjunction with the dicussion about the const_string library. I don't know, what's the current status, but IIRC there were some people interested in putting together several different string implementations compatible with std::string et.el.
I have been working on this using a variant of flex_string for my fixed_string class because flex_string does not handle the way I am implementing flex_string. One issue I have with flex_string is that it is too big. Granted, that is because the std::string definition is big as well. Given this, I have been factoring out the various methods into groups (iterator, element access, etc.) The new approach makes use of the CRTP technique, with the helper macro: #define BOOST_CRTP_IMPL(T)\ T & derived(){ return *static_cast<T *>(this); }\ const T & derived() const{ return *static_cast<const T *>(this); } This is more in line with the approach for iterators and can be expanded to include common patterns for container implementations (e.g. with iterators/reverse iterators). This would make it easier to use subsets of the std::string interface. For example, Maxim's const_string doesn't use the mutating methods. I have also made several modifications to Andrei's flex_string: using Boost's reverse_iterator (for msvc-6.0 support) and the strings char_traits for copy/move/etc. vs using the pod_* methods. Regards, Reece