- Boost - lists.boost.org

Problem with shared_ptr in MSVC8.0 (only when compiled in /clr mode ?)
by Loïc Joly 10 May '06

10 May '06

Hello everybody, In boost::shared_ptr, there is a trick to get a type convertible to bool that is not a bool... unspecified_bool_type is a function pointer. However, with MSVC8.0, and at least when I compile with /clr, I seem to have some problem with it : The null fct ptr seems to be coded 0xffffffff. That is just fine in non /clr compilation, where it gets evaluated as false when converted in boolean. But in /clr mode, it is converted to true. I guess this is a problem with the compiler, but would it not be possible to use a not so clever unspecified_bool_type with this compiler as a work-around ? Best regards, -- Loïc

2 5

Re: [boost] [review] Fusion review begins
by Martin Bonner 10 May '06

10 May '06

----Original Message---- From: Powell, Gary > Oleg> I propose to change tuple manipulators to be: > Oleg> 1) tuple_bounds("(", ")") // if need to specify one bound, I > Oleg> need to specify both. > Oleg> 2) tuple_delimiter(",") // I'm happy with bounds, but > Oleg> delimiter should be specified. > Oleg> 3) tuple_punc("(", ",", ")") // I should specify all > punctuation. >> > > The issue is that if you use a facet to do punct, it's tied to the > type of container. > > I apologize for not looking at what the current code does, but the > stuff I wrote orginally was tied directly to the tuples. > > Also, you probably want to stick with 'C' not "C"; I don't think you should rule out: tuple_punc("<tuple>", "\n", "</tuple>") -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

2 1

[string_convert] efficiency of to_string_classic
by Alexander Nasonov 10 May '06

10 May '06

I played with to_string_classic from vault / Strings - Text Processing / string_convert.zip It's faster then ostringstream but not much: Intel 8.1.028 on FreeBSD 6.1, -O2: ostream-based implementations (best of three runs) | ---------------------------------------------------- to_string_classic | 26.091 seconds | ---------------------------------------------------- ostringstream | 32.335 seconds | ---------------------------------------------------- GNU gcc 3.4.4 on FreeBSD 6.1, -O2: ostream-based implementations (best of three runs) | ---------------------------------------------------- to_string_classic | 25.126 seconds | ---------------------------------------------------- ostringstream | 31.333 seconds | ---------------------------------------------------- This is very slow compared to integral2str function defined in vault / Strings - Text Processing / integral2str.hpp Unlike to_string_classic which returns std::string, integral2str function returns boost::array<char,N>. I wrap it into std::string for more accurate comparison with to_string_classic. Here are the results: Intel 8.1.028 on FreeBSD 6.1, -O2: integral2str (worst of three runs) | ------------------------------------ std::string | 5.690 seconds | ------------------------------------ boost::array | 0.734 seconds | ------------------------------------ GNU gcc 3.4.4 on FreeBSD 6.1, -O2: integral2str (worst of three runs) | ------------------------------------ std::string | 5.763 seconds | ------------------------------------ boost::array | 1.247 seconds | ------------------------------------ // // Code that measure performance of ostream-based implementations // #include "to_string.hpp" #include <locale> #include <sstream> std::string slow(int n) { std::ostringstream out; out.imbue(std::locale::classic()); out << n; return out.str(); } int main() { using namespace string_convert; char volatile x = 0; for(int i = 0; i < 10000000; ++i) x += to_string_classic(i)[i % 2]; //x += slow(i)[i % 2]; return x; } // // Code that measure performance of integral2str // #include "integral2str.hpp" #include <string> int main() { char volatile x = 0; for(int i = 0; i < 10000000; ++i) x += integral2str(i)[i % 2]; //x += std::string(integral2str(i).data())[i % 2]; return x; } -- Alexander Nasonov Project Manager http://www.akmosoft.com

2 1

portable C++ signal handlers?
by Ryan Gallagher 10 May '06

10 May '06

Gennadiy Rozental wrote: > SIGNAL catching is optional and doesn't constitute portabiltiy issues per se, > whether to use it's up to you. Out of curiousity, what is a good (portable?) way of dealing with signals in C++? C signal handling seems to force globals on you, which is a pain especially when signal handling is a late requirement. Doing a bit of online research recently I read that some people prefer to translate signals to exceptions. As a co-worker of mine has pointed out this is how python deals with it (with python exceptions that is). >From what I've read though this is not portable, and, besides, is often not the control flow I would desire. Further reading suggested the use of singletons for registration of handlers. This (glorified global) seemed to make sense to me and I came up with the attached code for this. However, I do refer to statics here, which also may be non-portable. It does work with msvc-7.1 though. (Is it the case of multi-processors that makes this non-portable?) (Perhaps this should move to comp.lang.c++.moderated? This code is welcomed to be used by the boost community though. Distributed under boost software licence and all that...) Please feel free to critique in discussing this issue as I'm fairly inexperienced with dealing with signals outside of C. If possible I'd like to see a solution like this that works on boost's supported platforms and released as part of boost. -Ryan /// Singleton class to register and dispatch to handlers for c-style signals. /// @note Because the signal_registry::dispatch handler refers to the static /// instance of this class, which is not of type sig_atomic_t, this /// class is technically incurring undefined behavior. In practice /// compiler implementation support this action (at least better so /// that throwing an exception from the handler). /// class signal_registry : boost::noncopyable { private: typedef boost::signal<void (int)> signal_type; typedef boost::shared_ptr<signal_type> signal_pointer; typedef std::map<int, signal_pointer> signal_id_to_handler_map_type; public: /// Access to the singleton instance. /// @return The singleton instance. static signal_registry& instance() { static signal_registry meyers_singleton_instance; return meyers_singleton_instance; } /// Register a new handler to call on the given signal. /// When signaled, the handlers are called in the reverse order registered. /// @note previous handlers are not replaced. /// @param signal_id The id of the signal for which to register the handler /// (e.g. SIGINT). /// @param handler The callback for handling the given signal. It's /// argument will be the signal_id. boost::signals::connection register_handler(int signal_id, boost::function<void (int)> const& handler) { if(m_signals.count(signal_id) == 0) { std::signal(signal_id, &signal_registry::dispatch); m_signals[signal_id] = signal_pointer(new signal_type()); } return m_signals[signal_id]->connect(handler, boost::signals::at_front); } /// Dispatch the given signal to the stored handlers, if any. /// @param signal_id The id of the signal raised (e.g. SIGINT). /// @retval true If a handler was called. /// @retval false Otherwise. static void dispatch(int signal_id) { instance().dispatch_impl(signal_id); } private: void dispatch_impl(int signal_id) const { signal_id_to_handler_map_type::const_iterator handler_iter = m_signals.find(signal_id); if(handler_iter != m_signals.end() && !((handler_iter->second)->empty())) { (*(handler_iter->second))(signal_id); } } signal_id_to_handler_map_type m_signals; ~signal_registry() {} };

4 7

Easy wiki spam removal?
by Rene Rivera 10 May '06

10 May '06

Simple question... Is there a really easy way to remove spam from the wiki? And I mean something like a "rollback to X version" or "delete Y revision" button? There's a whole bunch of pages just affected and copy+paste from the last good revision into a new revision is just painfully slow for doing it many times. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

2 1

Re: [boost] [review] Fusion review begins
by Powell, Gary 09 May '06

09 May '06

Yours, -Gary- ------------------ powellg(a)amazon.com > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Oleg Abrosimov > Sent: Tuesday, May 09, 2006 8:06 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] [review] Fusion review begins > > Ronald Garcia: > > The review of Joel de Guzman's Fusion library begins today, May 1, > > 2006, and continues through May 10, 2006. > > Hello! > > One note about fusion::tuple I/O manipulators: > > "The library defines three manipulators for changing the > default behavior: > Manipulators > tuple_open(arg) > Defines the character that is output before the first element. > tuple_close(arg) > Defines the character that is output after the last element. > tuple_delimiter(arg) > Defines the delimiter character between elements." > Oleg> "Example: Oleg> std::cout << tuple_open('[') << tuple_close(']') << tuple_delimiter(", Oleg> ") << a;" > Oleg> I see a usability issue here. I believe that if one needs to Oleg> specify tuple_open then he would need to specify tuple_close too. > Oleg> I propose to change tuple manipulators to be: > Oleg> 1) tuple_bounds("(", ")") // if need to specify one bound, I Oleg> need to specify both. Oleg> 2) tuple_delimiter(",") // I'm happy with bounds, but Oleg> delimiter should be specified. Oleg> 3) tuple_punc("(", ",", ")") // I should specify all punctuation. > Hmmm. You may be right here, as there could be confusion from the following: cout << tuple_open('[') << tuple_delimiter(';') << tuple(1,2) << tuple_close(']'); where it would output [1;2) instead of [1;2] > Oleg> furthermore, I believe that these manipulators are more Oleg> general. They could be used with any sequence, not only with tuples. > Oleg> May be it should be factored out to separate library and Oleg> named appropriately? > Oleg> 1) seq_bounds("(", ")") // if need to specify one bound, I Oleg> need to specify both. Oleg> 2) seq_delimiter(",") // I'm happy with bounds, but delimiter Oleg> should be specified. Oleg> 3) seq_punc("(", ",", ")") // I should specify all punctuation. > Oleg> seq stands for sequence. > The issue is that if you use a facet to do punct, it's tied to the type of container. I apologize for not looking at what the current code does, but the stuff I wrote orginally was tied directly to the tuples. Also, you probably want to stick with 'C' not "C"; > > Best, > Oleg Abrosimov. > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

[Boost-bugs] [ boost-Bugs-1485069 ] program_options: format_paragraph assert fails on long line
by SourceForge.net 09 May '06

09 May '06

Bugs item #1485069, was opened at 2006-05-09 14:50 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=1485069&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: Kevin J Bluck (kbluck) Assigned to: Nobody/Anonymous (nobody) Summary: program_options: format_paragraph assert fails on long line Initial Comment: Boost 1.33.1, MSVC 8.0 When format_paragraph() in options_description.cpp attempts to format a line that will wrap because it is > 80 chars, it causes an assert failure in the standard library string iterator's operator+=(). The offending po:: code line is options_description.cpp Line 361: if (line_begin + (line_length - indent) > par_end) ... Relevant call stack attached. My guess is that the assert is complaining that the + operation has produced an iterator past the string's end(); this code seems to be assuming that the iterator object is a pointer. I believe it is officially undefined to advance an iterator past end(). One way of getting around this might be to use std::distance instead of comparing the iterators directly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1485069&group_… ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[fusion] question
by Gennadiy Rozental 09 May '06

09 May '06

I may not have time for review, but just one simple question: what are the advantages/disadvantages/differences in usage with stl_container<boost::variant>? Gennadiy

3 4

[Range] Expected complexity constraints
by David Abrahams 09 May '06

09 May '06

I note that the range library still supports the following: * treating null-terminated strings as Ranges where the complexity of end(s) is O(N) * treating pairs of non-random-access iterators as Ranges where the complexity of size(p) is O(N) In my view both of these would ideally be eliminated. The argument for the latter is slightly weaker because of prcedent in the std, although the LWG is considering removing it. Possible alternatives distinguish the ranges that actually give the expected complexity: a. Provide separate concepts for O1EndRange and O1SizeRange b. Provide traits to detect has_o1_end and has_o1_size Probably you'd want to do both. By the way, you can get back O(1) for end(s) where s is a null-terminated string if you allow the end iterator to have a different type from the begin iterator... but those ranges don't play well with the standard algorithms. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 5

[Boost-bugs] [ boost-Support Requests-1484666 ] thread_exception
by SourceForge.net 09 May '06

09 May '06

Support Requests item #1484666, was opened at 2006-05-09 06:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1484666&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: thread_exception Initial Comment: why the what function is not implemented in the thread_exception class while it is implemented in all its childs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1484666&group_… ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0