- Boost - lists.boost.org

[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

Foreach and typeof
by Edward Diener 17 Aug '05

17 Aug '05

Did either foreach or typeof make it into Boost 1.33 ? I see nothing about either in the documentation and I had the impression that both passed the review and were to be in Boost 1.33. I guess they will be in the next release.

4 4

Re: [boost] Interest for a perl6-like-junctions-class?
by Rob Stewart 17 Aug '05

17 Aug '05

I posted another update to multivalues.zip. This one eliminates dependence on SFINAE, so it may compile on additional compilers. -- Rob Stewart stewart(a)sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

1 0

[Test] 1.33 small typo error with MIPS Pro
by Kevin Wheatley 16 Aug '05

16 Aug '05

Under MIPS pro va_end() is a null macro and this then causes a warning, so I assume that the commas should be semi-colons. Kevin --- boost_1_33_0_gcc_3.2.3/include/boost-1_33/boost/test/impl/test_tools.ipp 2005-06-22 23:03:05.000000000 +0100 +++ boost_1_33_0/boost/test/impl/test_tools.ipp 2005-08-16 09:41:13.000000000 +0100 @@ -173,7 +173,7 @@ unit_test_log << "difference between " << arg1_descr << "{" << arg1_val << "}" << " and " << arg2_descr << "{" << arg2_val << "}" << ( tl == PASS ? " doesn't exceed " : " exceeds " ) - << toler_val << "%", + << toler_val << "%"; va_end( args ); @@ -196,7 +196,7 @@ unit_test_log << "absolute value of " << arg1_descr << "{" << arg1_val << "}" << ( tl == PASS ? " doesn't exceed " : " exceeds " ) - << toler_val, + << toler_val; va_end( args ); -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |

4 3