- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-1238243 ] shared_ptr/weak_ptr tests are not C++ spec compliant
by SourceForge.net 14 Jul '05

14 Jul '05

Bugs item #1238243, was opened at 2005-07-14 07:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1238243&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Peter Dimov (pdimov) Summary: shared_ptr/weak_ptr tests are not C++ spec compliant Initial Comment: Please refer to the latest C++ spec (Second edition, 2003-04-01), section 12.8.15, "Copying class objects". Look at your source code in test/weak_ptr_test.cpp. 1. You cannot assume the reference count of the shared_ptr going into the copy_assignment function is one. The spec says that compilers are allowed to make an optimization to eliminate a copy, but not mandated to do so. This means that the effective reference count upon entry to the function may be two, not one. To correct your unit tests, forcibly create a local object that you pass by value to guarantee the reference count is two upon entry for all compilers. To respond to the following email address, remove all capital Z's. rZoZbZeZrZt.bZuZcZk(a)mathworks.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1238243&group_… ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Web page with compiler macros and versions
by Edward Diener 14 Jul '05

14 Jul '05

I want to create a web page for Boost in which each compiler supported by Boost is listed with the name of the preprocessor which needs to be examined to determine the compiler version, and the numbers, in hex or decimal, which correspond to each version. The web page would be in the form of a simple table, but any good CSS expert can spruce it up. Currently I have on my Windows machine, Microsoft VC6, VC7, VC7.1, Borland BCB3, BCB4, BCB5, and BCB6, and Comeau 4.3.3. I need information about any other Windows compiler/versions which Boost supports as well as information about any Linux compilers and other compilers. Responses from those who do regression tests for other compilers would certainly be helpful, or perhaps the reuslts of indivbidual regression tests, such as config_info.cpp, which I believe tells that information, are available.

2 4

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

14 Jul '05

<Jan.Hermelink(a)metalogic.de> wrote: >> It looks more like a bug than by design if you ask me. >I don't think so - this behaviour is specified in the standardization >proposal. >To quote from >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1429.htm, >Chapter "RE.8.2 Template class regex_token_iterator": > >"If the end of sequence is reached (regex_search returns false), the >iterator becomes equal to the end-of-sequence iterator value, unless the >sub-expression being enumerated has index -1: In which case the iterator >enumerates one last string that contains all the characters from the end >of the last regular expression match to the end of the input sequence >being enumerated, provided that this would not be an empty string." > >!!! "provided that this would not be an empty string" !!! > How about this string: "/abc/abc". > Would this result in "", "abc", "abc"? Yes > Yet "abc/abc/" would result in "abc", "abc"? Yes > That seems terribly unbalanced to me, and this is not the behavior I would expect. Yes, you may have a point here. Or is it somewhat modeled after the C++ initializer syntax: { a, b, } is the same as { a, b } but { , a, b } isn't the same ... Maybe John can commence? Jan

4 3

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