July 2005 - Boost - lists.preview.boost.org

Proposal: Add build output types to Boost.Config
by Jason Hise 26 Jul '05

26 Jul '05

If there is not currently a set of macros provided by config.hpp which detect the type of output the compiler is generating, is there interest in adding one? I am thinking something along the lines of: BOOST_CAN_DETECT_BUILDING_EXE BOOST_BUILDING_EXE BOOST_CAN_DETECT_BUILDING_SLL BOOST_BUILDING_SLL BOOST_CAN_DETECT_BUILDING_DLL BOOST_BUILDING_DLL -Jason

1 0

singleton_ptr
by Jason Hise 25 Jul '05

25 Jul '05

Background: Since the first version of my singleton library was rejected, I have been designing a new singleton library from the ground up. I feel that this is necessary because the first version was not designed with the concerns of threading in mind, and such concerns cannot easily be addressed efficiently as an afterthought. The new design should hopefully be able to handle threading effectively without introducing any overhead for the single threaded model. Question: With the new design, I am adding a policy to control exactly what happens if creation is attempted while the singleton instance exists. The options thus far include throwing an exception, doing nothing, or destroying and recreating the singleton, depending on the policy used. Does it make sense to have a similar policy for what happens when attempting to destroy an already destroyed instance? I can think of a few options that would make sense, such as doing nothing, throwing an exception, asserting, or creating the instance so that it can be re-destroyed, but I do not know if these would actually be useful enough to justify a point of customization. Thoughts? -Jason

8 16

singleton and dlls
by Jason Hise 25 Jul '05

25 Jul '05

To make my singleton work with dlls, I have determined that I need to export/import certain global lifetime management objects so that they are visible across dll boundaries. To keep the library header-only, I want to use the preprocessor to detect whether a windows dll, windows exe, or other is being built. If it is a windows exe I want to export the object. If it is a windows build and not an exe, I want to import the object. And if it is not a windows build I just want to define the object normally. A couple questions since this is unfamiliar territory for me: Can I export from an exe and import into a dll? It seems like normally the reverse would be done, but this seems like a good way to ensure that the object is only exported once. What boost macros would I use to detect which type of build is occurring? Is there any type of exporting or importing that should occur with the Linux equivalent of dlls? If so, is there some uniform interface provided by boost that wraps things like __declspec(dllexport) and __declspec(dllimport) for most platforms? -Jason

1 0

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

25 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-25T15:39:19Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 318 failures in 9 libraries: filesystem (4) graph (1) multi_index (1) program_options (4) python (4) random (2) serialization (287) test (5) wave (10) |filesystem| operations_test_dll: borland-5_6_4 mingw-3_4_2 path_test_dll: borland-5_6_4 mingw-3_4_2 |graph| graphviz_test: intel-win32-8_1 |multi_index| test_capacity: vc-8_0 |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin |python| iterator: vc-7_1 map_indexing_suite: vc-7_1 pointer_vector: vc-7_1 vector_indexing_suite: vc-7_1 |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 vc-7_1 test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 vc-7_1 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_contained_class_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_contained_class_binary_archive_dll: cw-9_4 cw-9_5-darwin test_contained_class_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_contained_class_text_archive_dll: cw-9_4 test_contained_class_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_contained_class_text_warchive_dll: cw-9_4 test_contained_class_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_contained_class_xml_archive_dll: cw-9_4 test_contained_class_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_contained_class_xml_warchive_dll: cw-9_4 test_cyclic_ptrs_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_cyclic_ptrs_binary_archive_dll: cw-9_4 cw-9_5-darwin test_cyclic_ptrs_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_cyclic_ptrs_text_archive_dll: cw-9_4 test_cyclic_ptrs_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_cyclic_ptrs_text_warchive_dll: cw-9_4 test_cyclic_ptrs_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_cyclic_ptrs_xml_archive_dll: cw-9_4 test_cyclic_ptrs_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_cyclic_ptrs_xml_warchive_dll: cw-9_4 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_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_derived_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_binary_archive_dll: cw-9_4 cw-9_5-darwin test_derived_class_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_binary_archive_dll: cw-9_4 cw-9_5-darwin test_derived_class_ptr_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_ptr_binary_archive_dll: cw-9_4 cw-9_5-darwin test_derived_class_ptr_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_ptr_text_archive_dll: cw-9_4 test_derived_class_ptr_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_ptr_text_warchive_dll: cw-9_4 test_derived_class_ptr_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_ptr_xml_archive_dll: cw-9_4 test_derived_class_ptr_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_ptr_xml_warchive_dll: cw-9_4 test_derived_class_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_text_archive_dll: cw-9_4 test_derived_class_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_text_warchive_dll: cw-9_4 test_derived_class_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_xml_archive_dll: cw-9_4 test_derived_class_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_xml_warchive_dll: cw-9_4 test_derived_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_text_archive_dll: cw-9_4 test_derived_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_text_warchive_dll: cw-9_4 test_derived_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_xml_archive_dll: cw-9_4 cw-9_5-darwin test_derived_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_xml_warchive_dll: cw-9_4 test_diamond_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_4 cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_4 cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_4 cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_4 cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_4 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_mi_binary_archive_dll: intel-win32-8_1 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_no_rtti_xml_archive: vc-8_0 test_non_default_ctor_text_archive_dll: cw-9_5-darwin test_non_default_ctor_text_warchive_dll: cw-9_5-darwin test_non_default_ctor_xml_archive_dll: cw-9_5-darwin test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin test_non_intrusive_text_archive_dll: cw-9_5-darwin test_non_intrusive_text_warchive_dll: cw-9_5-darwin test_non_intrusive_xml_archive_dll: cw-9_5-darwin test_non_intrusive_xml_warchive_dll: cw-9_5-darwin test_null_ptr_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_null_ptr_binary_archive_dll: cw-9_4 cw-9_5-darwin test_null_ptr_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_null_ptr_text_archive_dll: cw-9_4 test_null_ptr_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_null_ptr_text_warchive_dll: cw-9_4 test_null_ptr_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_null_ptr_xml_archive_dll: cw-9_4 test_null_ptr_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_null_ptr_xml_warchive_dll: cw-9_4 test_nvp_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_nvp_binary_archive_dll: cw-9_4 cw-9_5-darwin test_nvp_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_nvp_text_archive_dll: cw-9_4 test_nvp_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_nvp_text_warchive_dll: cw-9_4 test_nvp_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_nvp_xml_archive_dll: cw-9_4 test_nvp_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_nvp_xml_warchive_dll: cw-9_4 test_recursion_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_recursion_binary_archive_dll: cw-9_4 cw-9_5-darwin test_recursion_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_recursion_text_archive_dll: cw-9_4 test_recursion_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_recursion_text_warchive_dll: cw-9_4 test_recursion_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_recursion_xml_archive_dll: cw-9_4 test_recursion_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_recursion_xml_warchive_dll: cw-9_4 |test| errors_handling_test: cw-9_5-darwin test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |wave| test_re2c_lexer: vc-7_1 vc-8_0 test_slex_lexer: vc-7_1 vc-8_0 testwave: cw-8_3 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-7_1 vc-8_0

1 0

To:John Maddock about the extention of the Boost.Regex
by leecky 25 Jul '05

25 Jul '05

John Maddock, Hi, I'm writing codes for my corporation,and I am faced with an challenge that how can I do a wrap for the Boost.Regex according to our libarary which has used in our programs. firstly, the string type in our library is differ from the std::string, so how can I do a template partial version toward the basic_regex? many thanks for inconvenient! 　　　　　　　　Sincerely:leecky 　　　　　　　　liwenli08(a)163.net 　　　　　　　　　　2005-07-25

2 1

Re: [boost] Call for interest for native unicode character and string support in boost
by Graham 25 Jul '05

25 Jul '05

Message: 14 Date: Sun, 24 Jul 2005 20:14:29 +0200 From: Erik Wien <wien(a)start.no> Subject: Re: [boost] Call for interest for native unicode character and string support in boost To: boost(a)lists.boost.org Message-ID: <dc0lpu$ej0$1(a)sea.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Dear Erik, I have done extensive Unicode work, and would be very interested to see what you have done. I apologise if I ask a lot of questions but these are the questions that immediately spring to mind on any Unicode implementation. How have you organised the Unicode 4.1 data ? Optimising this is itself a project and I have gone through a number of iterations. Unfortunately I have no definitive answer as you ultimately trade off speed against data size. Have you allowed for updating against the current Unicode standard from the Unicode data files? Have you made any trade-off of border [grapheme etc] detection for a simplification of character data ? Have you given access to the character properties? Have you added Unicode sorting and done it in such a way as to not get a high performance hit, e.g. having a separate pair<sort data, string> class? Have you stopped equivalence or equality on a Unicode string? What was your trade off on canconical decomposition? How have you hooked in dictionary word break support for languages like Thai or have you just built in support for adding private characters so that you can support force work break, force no word break, and detected word break [to name just three necessary private characters - in this case for Thai]. How far have you gone? Do you have support for going from logical to display on combined ltor and rtol ? Customised glyph conversion for Indic Urdu? Should these discussions be in a separate mailing group? How can we ensure that other boost projects understand the implication of Unicode support and the subtle changes required, e.g. hooks to allow for canonical decomposition on string data portions of regular expressions in the regexpr project? I am open to suggestions as to the best way to proceed as I feel that there are so many factors that can be traded against each other that there must be some flexibility in the design to allow for speed or memory optimised designs and this will need a lot of careful thought from different informed view points. My feeling is that the first step must be to agree the organisation of the data tables that are parsed from the Unicode data to allow for character tests, upper/ lower case conversion, sort conversion etc. There must be agreement on how best to organise these for speed or size, and what character tests are required. Until we can perform test on Unicode characters and have the basics, getting into Unicode strings is jumping the gun ! We will need to create a utility to take the 'raw'/ published unicode data files along with user defined private characters to make these tables which would then be used by the set of functions that we will agree such as isnumeric, ishangul, isstrongrtol, isrtol etc. I think that this would allow us to progress in a way where we can build the foundations and then build everything else on top of them, and which would then allow the standard to be directly related to and updated from the Unicode standard itself. What do you think? Yours, Graham Barnett BEng, MCSD/ MCAD .Net, MCSE/ MCSA 2003, CompTIA Sec+

2 1

Call for interest in a buffer container
by Andrey Tarantsov 25 Jul '05

25 Jul '05

Hello! I've got a relatively simple queue-like container which can be efficiently used as a buffer. It allocates memory in chunks, and reuses these chunks without deallocating them. (Unused chunks are deallocated based on a simple heuristic.) It's generic (with element type and allocator as parameters), but is expected to be often instantiated with 'unsigned char' (byte) element type. The interface and implementation are not currently iterator-friendly, because I did not need iterator behaviour. As the buffer is expected to be used for storing multiple elements at a time from a continuous storage (C array), it does reads and writes more efficiently than by-element copying iterators can provide. But there is no problem adding iterators, if there will be any interest in this container. Here is the interface (which is short and hopefully more undestandable than my description): /* (constructor) * Specifies buffer memory management details. Storage is allocated in chunks * of [chunk_size] elements; this defaults to the count which makes each chunk * about 10Kb in size (a wild guess). Adjust [reuse_amount] to specify how * fast should the buffer deallocate unused chunks, in 1/128's of full buffer * fill-and-read cycle. A value of 128 (the default) corresponds to the time * all old elements in the buffer are read. A value of 256 means that * unneeded chunks are deallocated after filling and emptying the buffer * twice. */ buffer (size_t chunk_size = default_chunk_size, unsigned reuse_amount = default_reuse_amount); /* * Add the given elements to the end of buffer. */ void write (const El *data, size_t count); /* * Read the given number of elements data from the start of buffer, and remove * the read elements. If less then [count] elements are available, will * read (and remove) all the available elements. Returns the number of * elements read (and removed). */ size_t read (El *data, size_t count); /* * Read the given number of elements starting with the given position, * WITHOUT removing them from the buffer. Position starts at zero, so * specifying zero [pos] results in the behaviour similar to read(), but * without removing the elements. */ size_t read_at (size_t pos, El *data, size_t count); size_t size () const; bool empty () const; -- Andrey.

1 0

Boost.ProgramOptions dynamic linking on mingw
by Alo Sarv 25 Jul '05

25 Jul '05

As noted at: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/output… progopt library fails to link on mingw as dll. After some searching around, I found out that using -Wl,--enable-runtime-pseudo-reloc flag during linking, it works properly. However, one should be warned that this flag should not be used when some of the code isn't compiled with the same compiler (e.g. mixing dlls/binaries from different compilers) - the resulting binary will always crash. Alo

4 6

Re: [boost] Boost.Filesystem i18n mini-review
by Beman Dawes 25 Jul '05

25 Jul '05

At 04:42 AM 7/20/2005, Jan Hermelink wrote: >This is not (yet) a review, but I use your filesystem library in several >unicode projects and am very interested in the wide char implementation. >I have tried wpath and wpath_directory_iterator with two projects and >run in several minor problems: > >- Building >I can't build the DLLs on my system (Windows XP SP2, VC 7.1): > path.cpp(51) : error C2491: 'boost::filesystem::wpath_traits::imbue' : > definition of dllimport function not allowed > >Static builds run fine. This should be fixed soon. Thanks for the report. >- fstream.hpp: > Declaration of function narrow_path(const std::wstring & file_ph, ...) >If several filesystem fstream objects are declared in different >translation units, the linker complains this symbol as multiple defined. > >Adding an inline specifier helps as workaround. > >- fstream.hpp: > Implementation of function narrow_path(const std::wstring & file_ph, >...) >This function doesn't work at all on my system, it returns always the >empty string. Why is this 8.3 conversion needed, It is a hack. To avoid having to modify the standard library (which doesn't support wide-character filenames), the 8.3 names are used instead. These appear to always be narrow even if the full name is wide. > can this work on NTFS reliable? Apparently not. I wasn't aware you could turn them off. >Replacing the current implementation thru a simple narrow conversion >helps as workaround. My understanding (which could be faulty) is that there is no general way to do such a wide to narrow conversion that always works. I'd love to be proven wrong. >- is_symlink() >Why isn't this function implemented on Windows? A NTFS junction is >symlink, isn't it? So I've been told. I tried a couple of times to figure out how to use junctions, but my eyes glazed over long before understanding occurred. >After fixing the above problems the library seems to run fine. > >Thank you for your work! And thank you for your comments! --Beman

1 0

Re: [boost] Call for interest for native unicode character
by Graham 24 Jul '05

24 Jul '05

Message: 2 Date: Sat, 23 Jul 2005 19:32:03 -0400 From: Ben Artin <macdev(a)artins.org> Subject: Re: [boost] Call for interest for native unicode character and string support in boost To: boost(a)lists.boost.org Message-ID: <macdev-DD69FE.19320323072005(a)sea.gmane.org> Dear Ben, Thanks for the reference, I have already taken a look at the previous posts. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1040.pdf does mention the primitive types. I see that vector is a preference as a container - however I don't see any handling of graphemes, words, lines, and sentences which are integral parts on the Unicode 4 specification. Nor do I see any proposal for how to integrate the actual Unicode data which is vital to being able to implement Unicode iterators, sort, upper/lower case conversion, and the rest.... I have not seen anything on providing the necessary support for character information e.g. to convert logical to display order. This data even when optimised will still be several meg of data - but a Unicode implementation cannot fly without it. Nor do I see how you can ensure that if you base Unicode strings on vector that you can ensure that the contents is a Unicode string [e.g. adding the first member of a surrogate only and not adding the second member]. Has the conversation moved on? Where is this currently being discussed? Thanks. Yours, Graham Barnett BEng, MCSD/ MCAD .Net, MCSE/ MCSA 2003, CompTIA Sec+

2 1