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

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

[Boost-bugs] [ boost-Bugs-1262038 ] boost:signals SIGSEV
by SourceForge.net 17 Aug '05

17 Aug '05

Bugs item #1262038, was opened at 2005-08-17 14:37 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=1262038&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: macchese (macchese) Assigned to: Nobody/Anonymous (nobody) Summary: boost:signals SIGSEV Initial Comment: hi all, I'm using boost-1_33 with $ g++ --v Reading specs from /usr/lib/gcc/i586-mandrake-linux-gnu/3.4.3/specs Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-clocale=gnu --disable-libunwind-exceptions --enable-languages=c,c++,ada,f77,objc,java --host=i586-mandrake-linux-gnu --with-system-zlib Thread model: posix gcc version 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk) and, just compiled the first example from http://www.boost.org/doc/html/signals/tutorial.html#id1280117 I obtain a segmentation fault. this is the trace from gdb [max@macchese temp]$ gdb ./unitest GNU gdb 6.3-3.1.102mdk (Mandrakelinux) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-mandrake-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) r Starting program: /home/max/src/temp/unitest Program received signal SIGSEGV, Segmentation fault. 0x0804bbdf in std::less<int>::operator() () (gdb) bt #0 0x0804bbdf in std::less<int>::operator() () #1 0x0804b901 in boost::signals::detail::any_bridge_compare<std::less<int>, int>::operator() () #2 0x0804b3d1 in boost::detail::function::function_obj_invoker2<boost::signals::detail::any_bridge_compare<std::less<int>, int>, bool, boost::any, boost::any>::invoke () #3 0xb7fdf7e0 in boost::function2<bool, boost::any, boost::any, std::allocator<boost::function_base> >::operator() ( this=0x8050030, a0={content = 0x80500c0}, a1={content = 0x8050080}) at function_template.hpp:576 #4 0xb7fe049e in std::_Rb_tree<boost::any, std::pair<boost::any const, std::list<boost::signals::detail::connection_slot_pair, std::allocator<boost::signals::detail::connection_slot_pair> > >, std::_Select1st<std::pair<boost::any const, std::list<boost::signals::detail::connection_slot_pair, std::allocator<boost::signals::detail::connection_slot_pair> > > >, boost::function2<bool, boost::any, boost::any, std::allocator<boost::function_base> >, std::allocator<std::pair<boost::any const,std::list<boost::signals::detail::connection_slot_pair, std::allocator<boost::signals::detail::connection_slot_pair> > > >>::lower_bound (this=0x8050030, __k=@0xbffff1e0) at stl_tree.h:1154 #5 0xb7fdf6dd in std::map<boost::any, std::list<boost::signals::detail::connection_slot_pair, std::allocator<boost::signals::detail::connection_slot_pair> >, boost::function2<bool, boost::any, boost::any, std::allocator<boost::function_base> >,std::allocator<std::pair<boost::any const, std::list<boost::signals::detail::connection_slot_pair, std::allocator<boost::signals::detail::connection_slot_pair> > > > >::lower_bound (this=0x8050030, __x=@0xbffff1e0) at stl_map.h:540 #6 0xb7fdec09 in std::map<boost::any, std::list<boost::signals::detail::connection_slot_pair, std::allocator<boost::signals::detail::connection_slot_pair> >, boost::function2<bool, boost::any, boost::any, std::allocator<boost::function_base> >,std::allocator<std::pair<boost::any const, std::list<boost::signals::detail::connection_slot_pair, std::allocator<boost::signals::detail::connection_slot_pair> > > > >::operator[] (this=0x8050030, __k=@0xbffff1e0) at stl_map.h:336 #7 0xb7fdddad in boost::signals::detail::named_slot_map::clear (this=0x8050030) at /home/max/src/boost_1_33_0/libs/signals/build/../src/named_slot_map.cpp:81 #8 0xb7fddce7 in named_slot_map (this=0x8050030, compare=@0xbffff2d0) at /home/max/src/boost_1_33_0/libs/signals/build/../src/named_slot_map.cpp:74 #9 0xb7fe19bf in signal_base_impl (this=0x8050028, comp=@0xbffff2d0, combiner=@0xbffff2e0) at /home/max/src/boost_1_33_0/libs/signals/build/../src/signal_base.cpp:23 #10 0xb7fe23c0 in signal_base (this=0xbffff390, comp=@0xbffff2d0, combiner=@0xbffff2e0) at /home/max/src/boost_1_33_0/libs/signals/build/../src/signal_base.cpp:179 #11 0x0804a0cc in boost::signal0<void, boost::last_value<void>, int, std::less<int>, boost::function<void ()(), std::allocator<void> > >::signal0 () #12 0x08049921 in boost::signal<void ()(), boost::last_value<void>, int, std::less<int>, boost::function<void ()(), std::allocator<void> > >::signal () #13 0x08049601 in main () (gdb) I compiled the source (in attach) by: g++ main.cpp -o unitest -I/usr/local/include -I/usr/local/include/boost-1_33/ -L/usr/local/lib -lboost_signals-gcc-d I tryied also libboost_signals-gcc-mt-d with the same result. hope this help ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1262038&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1262030 ] there is not a signal category
by SourceForge.net 17 Aug '05

17 Aug '05

Bugs item #1262030, was opened at 2005-08-17 14:27 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=1262030&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: macchese (macchese) Assigned to: Nobody/Anonymous (nobody) Summary: there is not a signal category Initial Comment: I'm trying to submit a bug for the signals library, I'm wondering if there is a category or should use the "any" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1262030&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] patch to silence a MSVC++ warning in trim.hpp
by Martin Bonner 17 Aug '05

17 Aug '05

----Original Message---- From: Stefan Seefeld [mailto:seefeld@sympatico.ca] Sent: 17 August 2005 11:59 To: boost(a)lists.boost.org Subject: Re: [boost] patch to silence a MSVC++ warning in trim.hpp > Vadim Zeitlin wrote: >> Hello, >> >> when compiling <boost/algorithm/string/trim.hpp> with MSVC 7.1 at >> maximal warning level you get a warning 4512 ("assignment operator >> could not be generated") because of the const members in struct >> is_classifiedF from boost/algorithm/string/detail/classification.hpp. >> >> The trivial patch below fixes it. Notice that I didn't take the >> assignment operator in "#ifdef _MSC_VER" because I see no harm in >> doing this for all compilers but then no other compiler I know about >> gives such warning so it should be also safe to add the #ifdef if >> this is preferred. > > Wouldn't it be even better to provide a new baseclass > boost::nonassignable that is similar to boost::noncopyable ? That > makes things even more explicit. > That wouldn't help. If you derive from boost::noncopyable, you get warning 4512 (because MSVC is unable to generate an assignment operator). I think the best fix is for users to #pragma off the warning. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

3 2

Propose adding Clone Smart Pointer (clone_ptr) to the boost library
by Axter 17 Aug '05

17 Aug '05

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 Also check out the boost vault (clone_ptr_Introduction.zip )

2 2

patch to silence a MSVC++ warning in trim.hpp
by Vadim Zeitlin 17 Aug '05

17 Aug '05

Hello, when compiling <boost/algorithm/string/trim.hpp> with MSVC 7.1 at maximal warning level you get a warning 4512 ("assignment operator could not be generated") because of the const members in struct is_classifiedF from boost/algorithm/string/detail/classification.hpp. The trivial patch below fixes it. Notice that I didn't take the assignment operator in "#ifdef _MSC_VER" because I see no harm in doing this for all compilers but then no other compiler I know about gives such warning so it should be also safe to add the #ifdef if this is preferred. *** classification.hpp.orig Wed Aug 17 10:19:50 2005 --- classification.hpp Wed Aug 17 10:19:46 2005 *************** *** 55,60 **** --- 55,64 ---- #endif private: + // prevent compiler from trying to generate this operator + // automatically (and failing because of const members) + is_classifiedF& operator=(const is_classifiedF&); + const std::ctype_base::mask m_Type; const std::locale m_Locale; }; Thanks in advance, VZ

2 1

"/usr/bin/objcopy" --set-section-flags .debug_str=contents, debug
by Neal Becker 17 Aug '05

17 Aug '05

just curious. Why do debug builds of boost on gcc use this? What does it mean? I'm just wondering. I've never seen it needed for any other build. g++ -g is all that I've ever seen used to build a debug version of anything. "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug

5 8

Re: [boost] [futures] request for comments
by Florian Schintke 17 Aug '05

17 Aug '05

> > You asked for comments, so here goes: I find the apparently > > copious use of implicit conversions disturbing. Especially > > disturbing is the fact that futures seem to have both > > incoming and outgoing implicit conversions. > > In direct discussions with Thorsten I strongly objected against having an > operator T(), he want's to see the commenst on this list anyway... > > [...] > > Regards Hartmut Hi, I am neither an C++ expert nor do I know the internal reasons why inmplicit conversion may be awkward, but as Thorsten I like the futures including the implicit conversion. In the following I try to explain my reasons for this. Futures can be used for asynchronous function calls, but futures could (with another implementation) also be used for lazy evaluation. >From the programmers point of view it is nice, if you can specify the behaviour of your code by just changing the declaration of your variables and do not have to change anything else. // select one of the following declarations // here the single call is visible (explanation see below) int f = fac(15); future<int> f = fac(15); future<int,lazy> f = fac(15); // ... do something else ... // ... later use f (maybe at multiple locations in the code) // without any syntactical change ... do_something(f); cout << f << endl; With this schema one could easily change the computational model from synchronous, asynchronous (concurrently) and lazy. Missing the implicit conversion one would have to change every use of f to f(). If f() is once evaluated (waited for the asynchronous call) f behaves like a normal variable. The function is not evaluated again if f is used again. Why should one have to write () at each usage of this variable? This would be misleading and suggest that something is called or evaluated every time (including side effects of fac()), wich is not the case. Florian -- Florian Schintke <schintke(a)zib.de>, http://www.zib.de/schintke/

1 0

[regex] bad_expression changed interface
by Lorenzo Bettini 17 Aug '05

17 Aug '05

Hi in 1.31 bad_expression was class bad_expression : public bad_pattern { public: bad_expression(const std::string& s) : bad_pattern(s) {} }; now in 1.33 it is class regex_error : public std::runtime_error { public: explicit regex_error(const std::string& s, regex_constants::error_type err, std::ptrdiff_t pos); explicit regex_error(boost::regex_constants::error_type err); boost::regex_constants::error_type code()const; std::ptrdiff_t position()const; }; typedef regex_error bad_pattern; // for backwards compatibility typedef regex_error bad_expression; // for backwards compatibility so I was wondering if there's a way to make throw boost::bad_expression("internal error"); compile on both versions of the library (this statement was reported not to compile with 1.33 by a user of one of my programs) many thanks in advance Lorenzo -- +-----------------------------------------------------+ | Lorenzo Bettini ICQ# lbetto, 16080134 | | PhD in Computer Science | | Dip. Sistemi e Informatica, Univ. di Firenze | | Florence - Italy (GNU/Linux User # 158233) | | Home Page : http://www.lorenzobettini.it | | http://music.dsi.unifi.it XKlaim language | | http://www.lorenzobettini.it/purple Cover Band | | http://www.gnu.org/software/src-highlite | | http://www.gnu.org/software/gengetopt | | http://www.lorenzobettini.it/software/gengen | | http://www.lorenzobettini.it/software/doublecpp | +-----------------------------------------------------+

2 2