- Boost - lists.boost.org

Re: [boost] New Library Proposal: dual_state
by Jost, Andrew 14 Jul '05

14 Jul '05

<clip> > > Adapters don't have to require copyable objects. A > specialization can deal with noncopyable objects by replacing > requirement to underlying type to be copyable with > requirement to client code to accept const references and > don't require identity semantic. Also, the adapter should > live until it's default value is used somewhere. > > Here is pseudo-code: > > ------- > const T & adapter<T>::adapter(<constructor_parameters>) : > default_value_member(<constructor_parameters>) > { > } > > const T & adapter<T>::adapt(const T & value_to_adapt) { > return value_to_adapt ? value_to_adapt : default_value_member; } > ------- > > I think because this flavour of adapter manages the lifetime > of contained default value, it's possible to build a version > which would manage a container of multiple "default" objects > and would enable identity semantic and remove const > requirement. I don't think if this exotic case will be useful though. > I agree. Difficult as it was to find real cases that could use even a simple adapter, a multi-default adapter would seem to be a rare thing. > Also it's possible to decouple the adapter from its managed > default value object by using > > MO managed_object; > // accepts, stores and returns a reference adapter<MO> > f(managed_object); > > Also default values don't have to be constants. Default > objects can be generated by a generator object (which > produces values) or by a factory (which produces identities > and may allocate memory). For example, sometimes a random or > "next free" default value can be useful. Like in case of > bind() TCP socket function with optional port number. > Yes, a generator or factory would help if it decouples the adapter's interaction with the optional object. > And finally, it's possible to relax the requirements to both > underlying objects (T) and client code (loadPoint) by storing > a reference to an inplace factory inside of Optional objects, > but as a price for this improvement we are back to that > "metadata binding sin" then. Sorry, I don't fully understand. > > Or we can allow adapters simply to modify underlying objects: > > adapter<MO> f(<inplace factory for default values>); > > What do you think about all these proposed adapter designs? > > Andrey > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Boost regression notification (2005-07-13)
by Douglas Gregor 14 Jul '05

14 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-13T15:12:24Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 365 failures in 9 libraries: date_time (2) io (1) parameter (22) program_options (3) random (2) serialization (321) spirit (1) test (6) wave (7) |date_time| testlocal_time_input_facet: cw-9_4 testtime_input_facet: cw-9_4 |io| ios_state_unit_test: intel-win32-8_1 |parameter| basics: gcc-3.2.3-linux gcc-3_3-darwin intel-win32-8_1 intel-win32-8_1 vc-8_0 macros: gcc-3.2.3-linux gcc-3_3-darwin intel-win32-8_1 intel-win32-8_1 sfinae: borland-5_6_4 cw-8_3 cw-9_4 cw-9_4 gcc-3.2.3-linux gcc-3_3-darwin gcc-3_4_3-sunos intel-win32-8_1 intel-win32-8_1 msvc vc-6_5 vc-6_5-stlport vc-7_0 |program_options| unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_3-darwin |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: msvc vc-6_5 test_demo_pimpl_dll: msvc vc-6_5 vc-7_0 test_demo_portable_archive: intel-win32-8_1 intel-win32-8_1 vc-7_0 vc-7_1 vc-8_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr: cw-9_4 cw-9_4 cw-9_5-darwin test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-7_0 test_diamond_binary_archive: cw-8_3 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_map_binary_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_warchive_dll: msvc vc-6_5 vc-7_0 test_mult_archive_types: cw-9_4 cw-9_4 cw-9_5-darwin test_mult_archive_types_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 test_non_default_ctor2_binary_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_binary_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_text_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_text_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_text_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux vc-7_1 test_non_default_ctor2_text_warchive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_xml_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_xml_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_xml_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 test_non_default_ctor2_xml_warchive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_binary_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_binary_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_text_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_text_archive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_text_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux vc-7_1 test_non_default_ctor_text_warchive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_xml_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_xml_archive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_xml_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_binary_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_binary_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_text_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_text_archive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_text_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux vc-7_1 test_non_intrusive_text_warchive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_xml_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_xml_archive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_xml_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 test_non_intrusive_xml_warchive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_polymorphic_xml_archive: vc-8_0 test_shared_ptr_132_binary_archive: borland-5_6_4 test_shared_ptr_132_binary_archive_dll: borland-5_6_4 test_shared_ptr_132_text_archive: borland-5_6_4 test_shared_ptr_132_text_archive_dll: borland-5_6_4 test_shared_ptr_132_text_warchive: borland-5_6_4 test_shared_ptr_132_text_warchive_dll: borland-5_6_4 test_shared_ptr_132_xml_archive: borland-5_6_4 test_shared_ptr_132_xml_archive_dll: borland-5_6_4 test_shared_ptr_132_xml_warchive: borland-5_6_4 test_shared_ptr_132_xml_warchive_dll: borland-5_6_4 |spirit| owi_mt_tests: gcc-3_3-darwin |test| errors_handling_test: cw-9_5-darwin vc-8_0 test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |wave| test_re2c_lexer: cw-9_4 test_slex_lexer: cw-9_4 testwave: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux

2 1

Re: [boost] [regex and string algo] again strange split behaviour
by Jan Hermelink 13 Jul '05

13 Jul '05

> The only reasonable thing is for split to return N+1 pieces for a string > with N separators, if you ask me. :-) This is lossless in the sense that it > allows you to reconstruct the original string. The non-reasonable behavior > can easily be implemented on top of that, but not vice versa. In fact you can implement the "non-reasonable behavior" on top the "reasonable behavior" with help of boost::sub_match : std::vector<std::string> result; std::string s = "abc/abc/"; boost::regex sep = "/"; boost::sregex_token_iterator tok(s.begin(), s.end(), sep, -1); boost::sregex_token_iterator last; boost::sub_match<boost::sregex_token_iterator> sm; for (; tok != last; ++tok) { sm = *tok; result.push_back(sm); } if (sm.second != s.end()) result.push_back(std::string()); But in the meantime I'm thinking too this should be the default behaviour. Jan

1 0

[string algo] again strange split behaviour
by Stefan Slapeta 13 Jul '05

13 Jul '05

hi, I assume the behaviour of boost::split not to return the last token has been changed (in CVS). However, a side effect seems to be that there is also one token returned for _empty_ strings, which is very questionable IMO! summary (if '/' is the separator): boost 1.32: "" -> 0 tokens "abc/abc" -> 2 tokens "abc/abc/" -> 2 tokens CVS: "" -> 1 token (!) "abc/abc" -> 2 tokens "abc/abc/" -> 3 tokens should be IMO: "" -> 0 tokens "abc/abc" -> 2 tokens "abc/abc/" -> 3 tokens Thoughts? Stefan

4 6

Thread->join() deadlock
by Gili 13 Jul '05

13 Jul '05

FYI: The limitation page (http://www.boost.org/doc/html/threads/implementation_notes.html#threads.imp…) does not mention that one may not invoke thread.join() from within DLLMain because this too will lead to a deadlock (due to ExitThread()'s behavior). Can someone please document this? Thanks, Gili -- http://www.desktopbeautifier.com/

1 0

[serialization] Proposal to add support for lexical_cast
by Martin Wille 13 Jul '05

13 Jul '05

Hi, I propose the addition of a lexical_cast wrapper to Boost.Serialization. Motivating example: Suppose you have several UDTs for which you already have defined insertion/extraction operators, and you want to use Boost.Serialization to read/write values of these UDTs, preferably in a non-intrusive way. Problem: Boost.Serialization doesn't make use of existing insertion/extraction operators for the UDTs. Proposed addition: A Serialization Wrapper (similar to those described in http://tinyurl.com/e46v5 [1]) that performs on-the-fly conversion of an UDT value to some serializable type, usually a std::string. Code is attached. The proposed wrapper allows to specify a conversion that will be used during serialization/deserialization operations. During serialization, a value will get converted to a different type; the converted value is written to the archive. During deserialization, the value is converted back to the original type. The proposed wrapper uses boost::lexical cast for the conversion. Usage example: // udt.hpp struct udt { }; std::ostream &operator<<(std::ostream &, udt const &); std::istream &operator>>(std::istream &, udt const &); // someclass.hpp #include "udt.hpp" #include <boost/serialization.hpp> struct someclass { template<typename Archive> void serialize(Archive &ar, const unsigned int version) { ar & boost::serialization::lexical_cast<std::string>(my_udt); } private: udt my_udt; }; Pros: - very easy to use - non-intrusive Cons: - not very fast Questions: - Would you consider this a useful addition? - Would the name boost::serialization::lexical_cast be acceptable? - Do you see a use case for using an "external" type other than std::string with this wrapper, e.g ar & boost::serialization::lexical_cast<int>(my_udt); // ? (The code could be simplified, otherwise) - Similar wrappers could be written for the C++ cast operations, too. Would such wrappers be useful? - Would it be desirable to extend this to a general conversion-on-the-fly framework? - Assuming there are some positive responses about the usefulness of the lexical_cast wrapper, would this addition be suitable for a fast-track review (it is very tiny)? (I'd say no if this evolves into a general conversion-on-the-fly framework) - other comments? Thanks to Robert who helped me to understand my own code better. Regards, m [1] http://boost.org/libs/serialization/doc/wrappers.html // (C) Copyright Martin Wille 2005. Distributed under the Boost // Software License, Version 1.0. (See http://www.boost.org/LICENSE_1_0.txt) #ifndef BOOST_SERIALIZATION_LEXICAL_CAST_HPP #define BOOST_SERIALIZATION_LEXICAL_CAST_HPP #include <boost/lexical_cast.hpp> #include <boost/serialization/traits.hpp> #include <boost/serialization/split_member.hpp> namespace boost { namespace serialization { template <class T, class Intermediate = std::string> struct lexical_cast_wrapper : traits <lexical_cast_wrapper<T, Intermediate> ,object_serializable , track_never > { explicit lexical_cast_wrapper(T &t) : value(t) {} template <class Archive> void save(Archive &ar, unsigned int) const { Intermediate tmp((boost::lexical_cast<Intermediate>(value))); ar << tmp; } template <class Archive> void load(Archive &ar, unsigned int) const { Intermediate tmp; ar >> tmp; value = boost::lexical_cast<T>(tmp); } BOOST_SERIALIZATION_SPLIT_MEMBER(); private: T &value; }; template <class Intermediate, class T> lexical_cast_wrapper<T, Intermediate> lexical_cast(T &value) { return lexical_cast_wrapper<T, Intermediate>(value); } template <class T> lexical_cast_wrapper<T> lexical_cast(T &value) { return lexical_cast_wrapper<T>(value); } }} #endif

2 2

Filesystem i18n mini-review
by Martin 13 Jul '05

13 Jul '05

Been on vacation for a couple of weeks and missed the filesystem mini-review deadline. Here are som quick comments anyway: - What is your evaluation of the design? I think that the general design is very nice but I have a few issues: 1. The basic_path template parameter "String" defines the type used to store the path internally but at the same time it also defines the type used for construction and operator/. Consider the following example: I want to store the path in shared memory and therefore use a flex_string type with a 200 character internal buffer. Problem here is that now the path can only be created from this 200 character flex_string and not from std::string. One solution might be to let the constructor and operator/ work with ranges but it might create problems with copy constructor. template <typename RangeT> explicit basic_path(const RangeT& str) { append(begin(str), end(str)) } 2. All operations work with std::(w)string. When the internal string type is not std::string a conversion is necessary. In most cases the charcater conversion should be trivial but since a std::string is required a copy can't be avoided. In the example I used above, the flex_string must be copied into a std::string for each operation even if the character string is identical. Why not base operations on null terminated strings (const char*) or a pair of iterators instead. 3. Comparison between paths doesn't use locale. The paths are not treated as plain characters since a lexicographical compare is made. But the individual elements are treated as plain characters and the internal string type's operator< is used. This is a bit contradicting. I think the comparison operators should compare the elements in a locale dependent way. - What is your evaluation of the implementation no comment - What is your evaluation of the documentation? Very good. - Did you try to use the library? With what compiler? Did you have any problems? Haven't tried the i18n version yet. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have used the original filesystem library for approx 1 year and I have followed the i18n development closly. - Are you knowledgeable about the problem domain? yes, but I have only used the windows part (i.e. no portability). - Do you think the library should be accepted as a Boost library? yes.

2 2

VC8 type traits documentation
by Carl Daniel 13 Jul '05

13 Jul '05

Peter Dimov asked, and I don't recall seeing an answer posted (back on May 5): "Where is the instrinsic support documented, BTW?" Here: http://msdn2.microsoft.com/library/ms177194(en-us,vs.80).aspx -cd

3 3

Interest in a binary_int template for binary literals?
by Scott Schurr 13 Jul '05

13 Jul '05

Greetings, Prompted by some discussion on comp.sdt.c++.moderated, I have a small template that allows the user to declare an integer literal in binary. Usage looks like: #include "binary_int.hpp" unsigned int binary = binary_int<1001,0011,1011,0000>::b; The template is written to support up to 64 bits, although my compiler only allows me test up to 32 bits. I intend to use it for programming hardware registers in the language of the hardware folk at my company. The template is only about 150 lines and doesn't really deserve a library, but it could potentially be tucked into another library if it is deemed useful. Thanks. Scott Schurr

6 6

BOOST_NO_RESULT_OF
by David Abrahams 13 Jul '05

13 Jul '05

I want this macro for the parameters library. Currently, result_of uses #if !defined(BOOST_NO_SFINAE) && !defined(BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION) And otherwise, gives an #error That makes it hard to use portably, because the criteria under which result_of will be supported are not encapsulated, and I couldn't even define it in that file usefully (I'd still get an #error when it isn't supported). Shouldn't there be a generalized way to handle this sort of situation? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 5