- Boost - lists.boost.org

Re: [boost] [1.33.0] VC 7.1 vs. SFINAE/type traits
by Mat Marcus 17 Aug '05

17 Aug '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas, On 8/16/05, Thomas Witt <witt(a)acm.org> wrote: >[snip] > > I can't say whether that is your problem, but code like this is > potentially dangerous. It'll break whenever you happen to "suck" in a > use of operator~ on an unnamed enum. And yes it tends to generate weird > error messages. Looking at the errors the unknown type in the is_enum > instantiation looks suspicious to me. > > I only have apples gcc 4 currently. A slightly modified example gives this: > > enum { foo, bar }; > > template <typename EnumType> > typename boost::enable_if<boost::is_enum<EnumType>, EnumType>::type > operator ~ (EnumType a); > > int main() > { > > int i = ~bar; > > std::stringstream t; > > } > > mat.cpp: In function 'int main()': > mat.cpp:14: error: '<anonymous enum>' is/uses anonymous type > mat.cpp:14: error: trying to instantiate 'template<class T> struct > boost::is_enum' > > Thomas Thanks for sending this fascinating example. After doing a bit of my own exploration with gcc 4.0 I must agree with you. If I understand the ramifications correctly, if gcc 4.0 correctly disallows instantiating templates upon unnamed enum types, then SFINAE cannot be safely used for operators that may also happen to exist for (anonymous) enums. In the example above, even if we replace is_enum with a more restricted metafunction, the problem will not go away, since any instantiation would seem to be prohibited. Worse still, though it is easy enough to avoid calling the operator with an anonymous enum, I must also avoid files that might use operators on other unrelated anonymous enums, lest the compiler try to illegally instantiate the metafunction. So the big question is, "Is there no known way of safely testing whether a type is an anonymous enum?" Thanks, Mat -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQwL96RIZBaoznf65EQKf6wCcDyhiiRlQBMQ5NBISeTiQ0rnVEuwAn1y6 D54sfcwOgIvouUhH6QWtzLgv =f75H -----END PGP SIGNATURE-----

6 11

Unit test failure in release mode VS2005 beta 2
by Paul A Bristow 17 Aug '05

17 Aug '05

Boost 1.33.0 Unit_test_example1 is OK in debug thus: ------ Rebuild All started: Project: unit_test_framework, Configuration: Debug Win32 ------ Deleting intermediate and output files for project 'unit_test_framework', configuration 'Debug|Win32' Compiling... xml_report_formatter.cpp xml_log_formatter.cpp unit_test_suite.cpp unit_test_parameters.cpp unit_test_monitor.cpp unit_test_main.cpp unit_test_log.cpp test_tools.cpp results_reporter.cpp results_collector.cpp progress_monitor.cpp plain_report_formatter.cpp framework.cpp i:\boost_1_33_0\boost\test\impl\framework.ipp(313) : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned int', possible loss of data execution_monitor.cpp compiler_log_formatter.cpp Generating Code... i:\boost_1_33_0\boost\lexical_cast.hpp(223) : warning C4701: potentially uninitialized local variable 'result' used Creating library... Creating browse information file... Microsoft Browse Information Maintenance Utility Version 8.00.50215 Copyright (C) Microsoft Corporation. All rights reserved. Build log was saved at "file://c:\temp\boost_test_library\Debug\BuildLog.htm" unit_test_framework - 0 error(s), 2 warning(s) ------ Rebuild All started: Project: unit_test_example1, Configuration: Debug Win32 ------ Deleting intermediate and output files for project 'unit_test_example1', configuration 'Debug|Win32' Compiling... unit_test_example1.cpp Compiling manifest to resources... Linking... LINK : .\Debug/unit_test_example1.exe not found or not built by the last incremental link; performing full link unit_test_framework.lib(compiler_log_formatter.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'Debug\unit_test_framework.lib' or at 'i:\boost_1_33_0\libs\test\build\msvc71_proj\Debug\vc80.pdb'; linking object as if no debug info ... many similar - needs to avoid incremental liking???? Embedding manifest... Build log was saved at "file://c:\temp\boost_test_library\Debug\BuildLog.htm" unit_test_example1 - 0 error(s), 15 warning(s) ========== Rebuild All: 2 succeeded, 0 failed, 0 skipped ========== and runs as expected Running 1 test case... i:/boost_1_33_0/libs/test/example/unit_test_example1.cpp(17): error in "free_tes t_function": check 2 == 1 failed unknown location(0): fatal error in "free_test_function": memory access violatio n *** 1 failure detected (1 failure expected) in test suite "Unit test example 1" Press any key to continue . . . BUT in release >>>>>>>>>>>>>>>>> ------ Rebuild All started: Project: unit_test_framework, Configuration: Release Win32 ------ Deleting intermediate and output files for project 'unit_test_framework', configuration 'Release|Win32' Compiling... xml_report_formatter.cpp xml_log_formatter.cpp unit_test_suite.cpp unit_test_parameters.cpp unit_test_monitor.cpp unit_test_main.cpp unit_test_log.cpp test_tools.cpp results_reporter.cpp results_collector.cpp progress_monitor.cpp plain_report_formatter.cpp framework.cpp ..\..\..\..\boost/test/impl/framework.ipp(313) : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned int', possible loss of data execution_monitor.cpp ..\..\..\..\boost/test/impl/execution_monitor.ipp(214) : warning C4535: calling _set_se_translator() requires /EHa compiler_log_formatter.cpp Generating Code... Creating library... Build log was saved at "file://i:\boost_1_33_0\libs\test\build\msvc71_proj\Release\BuildLog.htm" unit_test_framework - 0 error(s), 2 warning(s) So library builds OK <<<<<<<<<<<<<<<< ------ Rebuild All started: Project: unit_test_example1, Configuration: Release Win32 ------ Deleting intermediate and output files for project 'unit_test_example1', configuration 'Release|Win32' Compiling... unit_test_example1.cpp Linking... msvcprt.lib(MSVCP80.dll) : error LNK2005: "public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ABV01@@ Z) already defined in unit_test_example1.obj <snip> ... MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj) LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library .\Release/unit_test_example1.exe : fatal error LNK1169: one or more multiply defined symbols found Build log was saved at "file://i:\boost_1_33_0\libs\test\build\msvc71_proj\Release\BuildLog.htm" unit_test_example1 - 33 error(s), 1 warning(s) ========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ========== Suggestions? Thanks Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

2 1

Boost regression notification (2005-08-17)
by Douglas Gregor 17 Aug '05

17 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-17T15:35:29Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 74 failures in 7 libraries: graph (11) iostreams (3) numeric/ublas (1) parameter (36) regex (1) serialization (21) wave (1) |graph| graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux mingw-3_4_2 vc-7_1 vc-7_1 vc-7_1 |iostreams| bzip2_test: mingw-3_4_2 gzip_test: mingw-3_4_2 zlib_test: mingw-3_4_2 |numeric/ublas| test3: intel-8.1-linux |parameter| basics: borland-5_6_4 gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.1-linux intel-8.1-linux msvc macros: borland-5_6_4 gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.1-linux intel-8.1-linux msvc sfinae: borland-5_6_4 gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.1-linux intel-8.1-linux msvc unnamed: borland-5_6_4 cw-9_4 cw-9_4 gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux intel-8.1-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 msvc vc-6_5 vc-6_5-stlport |regex| concept_check: gcc-3.2.3-linux |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc test_shared_ptr_132_text_archive: gcc-3.2.3-linux |wave| testwave: gcc-3.3.6-linux

1 0

[1.33.0][Iostreams] Spelling mistake in documentation
by Paul 17 Aug '05

17 Aug '05

Hi, I assume someone has seen the couple of spelling mistakes in this paragraph, from the boost::iostreams tutorial page in the docs: <quote> Finally, I sould mention that the Iostremas library provides an easier way to read from an STL container: instances of boost::iterator_range can be added directly to filtering streams and stream buffers. So you could write: </quote> but i'd thought i'd mention it anyway. I searched the lists for 'sould' and didn't find any mention. see ya Paul

2 1

boost 1.33.0: Bug in property
by Philipp Thomas 17 Aug '05

17 Aug '05

boost_1_33_0/boost/pending/property.hpp has template <class Tag, class T, class Base = no_property> struct property : public Base { typedef Base next_type; typedef Tag tag_type; typedef T value_type; property() { } property(const T& v) : m_value(v) { } property(const T& v, const Base& b) : Base(b), m_value(v) { } // copy constructor and assignment operator will be generated by compiler T m_value; }; The bug here is that the empty ctor does not initialize m_value which leads to gcc 4.0.1 warning about m_value being used uninitialized. As our automatic build system rejects packages with such warnings I had to fix it :) This is the patch I'm using: --- boost/pending/property.hpp +++ boost/pending/property.hpp @@ -22,7 +22,7 @@ typedef Base next_type; typedef Tag tag_type; typedef T value_type; - property() { } + property() : m_value() { } property(const T& v) : m_value(v) { } property(const T& v, const Base& b) : Base(b), m_value(v) { } // copy constructor and assignment operator will be generated by compiler Philipp -- Philipp Thomas <pth(a)suse.de> Research & Development SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuremberg, Germany

1 0

Re: [boost] Propose adding Clone Smart Pointer (clone_ptr) to the boost library
by Martin Bonner 17 Aug '05

17 Aug '05

----Original Message---- From: Axter [mailto:boost@axter.com] Sent: 17 August 2005 01:54 To: boost(a)lists.boost.org Subject: Re: [boost] Propose adding Clone Smart Pointer (clone_ptr) to the boost library > The documents state that the clone_ptr class is based on strict > pointer ownership logic. I am not familiar with that term, so it didn't help. > The above code is not using strict ownership logic, and instead the > object is created using a dumb pointer. But your example code has this problem. > I also think you're right in that I should add more to the > documentation Absolutely. I am sure that this code satisfied a real need that you had. What is not at all clear is whether that need is widespread enough to justify including the clone_ptr in boost. What is needed is some clear documentation including: - an explanation of what problems the class solves ("motivating examples"). Note this doesn't need to be very detailed as too why the problem exists at this point. I imagine most people on this list understand concepts like "slicing". - An overview of the class usage (including the restrictions on how the class may be used) - A description of the specification of the class and its members, including the concepts that the template parameters must model. (Don't worry too much about getting the English right. If the library does go into boost, plenty of people here can help with that later.) Finally you might like to consider the following: A) I can see how something like this might be useful to allow a copyable class which owns an object of a polymorphic type. However, under what circumstances is this better than providing a clone() member in the polymorphic type? B) Under what circumstances is a std::container<clone_ptr<T> > better than a boost::ptr_container<T>? -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

[regex] MipsPro warnings in boost/regex/pending/static_mutex.hpp (1.33.0)
by Richard Hadsell 17 Aug '05

17 Aug '05

The mipspro build of regex gives repeated warnings in static_mutex.hpp: mipspro-C++-action bin/boost/libs/regex/build/libboost_regex.so/mipspro/debug/cpp_regex_traits.o cc-1460 CC: WARNING File = /tmp_mnt/netDISKS/cgi/IRIX4/cgi/vendor/library/boost/boost_1_33_0/boost/regex/pending/static_mutex.hpp, Line = 69 Function function "boost::scoped_static_mutex_lock::locked" is redeclared "inline" after being called. inline bool scoped_static_mutex_lock::locked()const ^ I fixed it by declaring both 'operator void const*()' and 'bool locked()' inline in all 3 sections of the header: diff -u -r1.1 -r1.2 --- boost/regex/pending/static_mutex.hpp 2005/08/12 17:26:18 1.1 +++ boost/regex/pending/static_mutex.hpp 2005/08/16 16:49:44 1.2 @@ -52,8 +52,8 @@ public: scoped_static_mutex_lock(static_mutex& mut, bool lk = true); ~scoped_static_mutex_lock(); - operator void const*()const; - bool locked()const; + inline operator void const*()const; + inline bool locked()const; void lock(); void unlock(); private: @@ -99,8 +99,8 @@ public: scoped_static_mutex_lock(static_mutex& mut, bool lk = true); ~scoped_static_mutex_lock(); - operator void const*()const; - bool locked()const; + inline operator void const*()const; + inline bool locked()const; void lock(); void unlock(); private: @@ -154,8 +154,8 @@ public: scoped_static_mutex_lock(static_mutex& mut, bool lk = true); ~scoped_static_mutex_lock(); - operator void const*()const; - bool locked()const; + inline operator void const*()const; + inline bool locked()const; void lock(); void unlock(); private: -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

3 3

css patch (more/css_0/front.css)
by Janusz Piwowarski 17 Aug '05

17 Aug '05

Hello, I'm attaching the patch against unintentional(?) "Revision.." underlining (you can see it at boottom of htpp://boost.org page) BTW, Opera displays sans-serif as Verdana and it looks very well. Regards, Janusz

2 1

Re: [boost] Propose adding Clone Smart Pointer (clone_ptr) to the boost library
by Martin Bonner 17 Aug '05

17 Aug '05

----Original Message---- From: Jonathan Wakely [mailto:cow@compsoc.man.ac.uk] Sent: 17 August 2005 14:17 To: boost(a)lists.boost.org Subject: Re: [boost] Propose adding Clone Smart Pointer (clone_ptr) to theboost library > Axter wrote: > >> It does not need a clone member if you apply strict pointer >> ownership logic, which is what a clone pointer normally does. > > clone_ptr also needs the definitions of all derived classes to be > visible, whereas something like ptr_container that uses a clone() > member function only needs to see the definition of the base > class and can do everything through the base class' interface. I think it only needs the definition available for the constructor (which is where a class derived from his "copier" class is instantiated). [snip] > This would not be possible with std::vector<clone_ptr<Base> >: > > // pc.h > #include <boost/ptr_container/ptr_vector.hpp> > struct Base { > ~Base() {} > virtual Base* clone() = 0; > virtual void f() = 0; > }; > void fill(boost::ptr_vector<Base>&); > > // pc.cc > #include "pc.h" > #include <boost/bind.hpp> > #include <algorithm> > > int main() > { > boost::ptr_vector<Base> v; > fill(v); > std::for_each(v.begin(), v.end(), boost::bind(&Base::f, _1)); > return 0; > } > > The fill() function can now be implemented in another file and > populate the vector with any type derived from Base, without > recompiling pc.cc I think that is supported with clone_ptr. The file implementing fill would need the full definition of the derived type(s) of course, but that is less restrictive. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

Re: [boost] Propose adding Clone Smart Pointer (clone_ptr) to the boost library
by Martin Bonner 17 Aug '05

17 Aug '05

----Original Message---- From: Axter [mailto:boost@axter.com] Sent: 16 August 2005 03:39 To: boost(a)lists.boost.org Subject: [boost] Propose adding Clone Smart Pointer (clone_ptr) to the boost library > I'm proposing to add the clone_ptr class to the boost library. > > I've developed a clone_ptr class that performs a clone of an abstract > pointer without the need for a clone method. > > The clone_ptr is well suited for automatic deep copy of abstract > pointers, > and for use with STL containers. > > In addition to being able to perform clone operations, it also have > operators that performs comparison on the object being pointed to, > instead > of the pointer address. > This allows for correct sorting and comparison of clone_ptr's in an > STL > container. > See following link for more info: > http://code.axter.com/clone_ptr_introduction.htm I was interested in the example you give in the web page: class foo { clone_ptr < AbstractClass > m_MyAbstractClassPtr; public: foo(AbstractClass * abstractclassptr_):m_MyAbstractClassPtr(abstractclassptr_){} foo(const foo& Src) { //In the following line of code, the clone pointer will copy the // correct derived class without the need of a clone method m_MyAbstractClassPtr = Src.m_MyAbstractClassPtr; } }; That looked a very clever trick. I couldn't see how clone_ptr was going to copy the dynamic type of the argument to the constructor without any information about that dynamic type. Having looked at the code, I don't think it does. It would work if the constructor was declared: foo(DerivedClass*p): m_MyAbstractClassPtr(p) {} or even template <class Derived> foo(Derived *p):m_MyAbstractClassPtr(p) {} but even that will fail if the constructor is called via: Derived *p = new DerivedDerived; foo foo_obj(p); My basic concern is that while clone_ptr could be useful, it only works if people stick rigidly to certain rules. Those rules need to be made VERY clear, otherwise it provides a plentiful supply of rope. It would also be useful to have some documentation of what methods clone_ptr provides, and what effects they have. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

6 7