- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-1391875 ] _GLIBCXX_DEBUG fails on 1.33.1 - bug or design?
by SourceForge.net 28 Dec '05

28 Dec '05

Bugs item #1391875, was opened at 2005-12-28 12:02 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=1391875&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: regex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rafal Wijata (ravpl) Assigned to: John Maddock (johnmaddock) Summary: _GLIBCXX_DEBUG fails on 1.33.1 - bug or design? Initial Comment: Results in segfault (on vector destructor) Was ok(and still is) on 1.33.0 Compiled with gcc 4.0.2 on RHELAS4 with g++ -rdynamic -export-dynamic -D_GLIBCXX_DEBUG -g -lboost_regex -o test test.cpp sourcefile incuded. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1391875&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[variant] Proposal for compile time checked getter
by Zara 28 Dec '05

28 Dec '05

Dear all, During a redesign, I began using boost::variant, and I detected that trying to get a value of a type not included in variant type-list resulted in run-time error (cast or null pointer). I feel that a variant should only try to return a valid type from its type-list, otherwise giving a compiler error, and reserve runttime errors for that case when someone tries to get a value from a type contained in the typelist, but not the actual type contained in the actual object. In such a way, I have made a little redesign on boost::get and called it boost::checked_get: namespace boost { template <typename U, BOOST_VARIANT_ENUM_PARAMS(typename T) > inline typename add_pointer<U>::type checked_get( boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) >* operand BOOST_VARIANT_AUX_GET_EXPLICIT_TEMPLATE_TYPE(U) ) { typedef boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) > Variant; /* throw a compile-time error if type is not contained on type list */ BOOST_STATIC_ASSERT((!is_same< typename mpl::find<typename Variant::types,U>::type, typename mpl::end<typename Variant::types>::type>::value)); typedef typename add_pointer<U>::type U_ptr; if (!operand) return static_cast<U_ptr>(0); detail::variant::get_visitor<U> v; return operand->apply_visitor(v); } } // end of addition to namespace boost And, of course, the rest of the templates needed for const *, ref and const&.. I think it would be interesting to include it in boost libraries. In fact, I use it intensely. Best regards, -- Zara PS Forgive me for my bad english.

1 0

[asio] Why "const mutable_buffers &" in interfaces?
by Mats Nilsson 28 Dec '05

28 Dec '05

Hi Just a question asking to clarify the use of "const Mutable_Buffers &mutable_buffers" in the calls to some of the functions, e.g stream_socket::receive(const Mutable_Buffers &buffers, message_flags flags). To me, this is not logical, since I'd expect a receive function to actually modify the stuff I send into it, and the const qualifier doesn't seem to allow this. If it needs to be this way, you might want to explicitly explain this design choice somewhere close to where it is used. Also the reference documentation for asio::mutable_buffer seems to have a copy-paste bug; its detailed description includes "The const_buffer class provides ...", or am I missing something? Mats

3 2

Some Boost.Test queries
by Daryle Walker 27 Dec '05

27 Dec '05

1. Is there a way to specify that two auto-unit tests must come in a certain order? What about any kind of tests? Or do you have to create a giant test to force a particular order? 2. If the answer to [1] is "yes," then can fixtures be used to carry over changed variables between tests? 3. Can a fixture be a class template, so it can be used with a auto-unit test template such that the fixture changes its class parameter to match the test's parameter? (I worked around this currently by using an inner class template within a non-template class fixture.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

[defer] - new version uploaded
by simon meiklejohn 26 Dec '05

26 Dec '05

New version of the Defer library uploaded to the Boost Vault, Concurrent Programming folder. Main addition is support for a size configurable work item queue provided by Oliver Kowalke (thanks Oliver), from the thread_queue component in the same folder. This library may provide a counterpoint to the Boost.Asio library's related work deferral facilities. Cheers Simon

1 0

Re: [boost] [Review] Boost.Logging: formal review
by Richard Glanmark 26 Dec '05

26 Dec '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Gennadiy Rozental > Sent: den 15 december 2005 22:39 > To: boost(a)lists.boost.org > Subject: Re: [boost] [Review] Boost.Logging: formal review > > > 1. Enabled/disabled logger, logging macros and efficiency > > > > The logging macro BOOST_LOG should accept two arguments > instead of one. > > The logger and the log message. The syntax > > > > (1) BOOST_LOG(some_log) << "my message " << foo() << bar(); > > > > should be replaced with > > > > (2) BOOST_LOG(some_log, "my message " << foo() << bar()); > > > > and the macro being defined something like this > > > > (3) #define BOOST_LOG(logger, msg) \ > > if(logger.isEnabled()) { /* code that logs msg */ ... } > > > > Thus, disabled loggers will never take longer than simple > > if-statement, as long as the isEnabled() method is fast, which IMO > > should take no longer than comparing booleans. > > 1. I think this is also the case in original interface. > > > In the original solution (1) the method foo() will always > be called, > > which is inefficient when the logger is disabled, in solution (2), > > foo() will never be called when the logger is disabled. > > I think you are mistaken Yes, my mistake. > > Further more, the macro could insert extra information such as > > __LINE__, __FILE__ etc. > > This is also true for original interface. Yes true -- my mistake again (I didn't look enough at the implementation of the macro). > All in all I prefer message not be inside brackets. It looks > much more natural and I don't see any theoretical problens to > get the same performance. But I also believe that macro > shouldn't be a primary interface. > So if you prefer message inside the breakets - it's your choice. However, there is one additional benefit of placing the message inside brackets. One can remove the log statement in a build. Other than that, I guess its style preferences. > > 2. Filtering > > > > There has been some discussion about the ability of a library to be > > able to do more filtering than simple log levels, notably > by Gennadiy > > Rozental. > > > > Gennadiy writes: > >> At the bare minimum it should support: > >> > >> entry level - levels set is ordered set of values indication > > importance of > >> information provided. Filtering is based on threshold. Examples: > > DEBUG, INFO, MAJOR > > > >> entry category - categories set is a set of unique values > indicating > > kind of > >> information provided Filtering is based on masking. > >> Examples: ARGS, RETURN_VALUE, ERROR_LOG, DATA_FLOW, PROG_FLOW > > > >> entry keyword - keyword set is set of user defined keywords (most > > frequently strings) > >> identifying area of the program. Filtering is based on match of > > keywords. > >> Keywords usually are used to mark specific part of application. > > > > I agree that it is very important for a logging library to > support this. > > However, I do not think that the solution is for the > logging library > > to be aware of such special values. The library should be as > > simplistic as > > My position that library should be configurable by any class > satisfying Filter concept. > This particular filters could probably be supplied by the > library as an example and as most widely useful. > > > My proposed solution is to basically let loggers be somewhat entry > > (Gennadiy's definition above) unaware. Instead, let the developer be > > I do not see how it's possible. IMO framework should employ > some MPL magic and construct proper entry structure based on > set of Filters passed as template policy parameters. > > > entry aware. By that I mean that the developer should log messages > > that belong to a specific entry category/level to a > specific logger. > > For > > This is never be acceptable IMO. Even with 3 filters, each > ahving 5 possible values you looking into 125 different loggers. Support for log functions on top of a basic framework solution is needed to alleviate this problem. I wouldn't mind that the library provides log funtions that take various filter functions or predicates to determine wether to send a log statement to a logger. In this case, the logger would be enabled and the log filter function would send log statements to the logger if the log statement meets some criteria. Still, the underlying logger framework would be the same; logger object should still be enabled or disabled/enabled, there would still be a few different logger objects for different levels and possible other user defined criteria. IMO it is very important for an administrator/programmer of a system to be able to enable/disable logs, know what loggers and appenders exists and be able to configure said entities. If filter is only done on a per log statement, how do you even know as a administrator of a system what log filters exists? Which filter criteria should be enabled and which filter criteria should be disabled? If all log statements are sent to one logger object, the logger object becomes a monolith of functionality and complexity. Runtime performance might degrade considerable if various filters is to be checked, not only if the log statements should be logged, but also if one wants to send log statements to different appenders/sinks/destinations. Cheers, Richard The content of this e-mail is intended only for the confidential use of the person(s) to whom it is addressed. If the reader of this message is not such a person, you are hereby notified that you have received this communication in error and that reading it, copying it, or in any way disseminating its content to any other person, is strictly prohibited. If you have received this message in error, please notify the author by replying to the e-mail immediately. NeoNet AB and its subsidiaries (NeoNet Securities AB, NeoNet Securities Inc. and NeoNet Technology AB) are unable to exercise control over the content of information contained in transmissions made via the Internet and hereby excludes any warranty as to the quality or accuracy of any information contained in this message and any liability of any kind for the information contained in it, or for its transmission, reception, storage or use in any way whatsoever.

7 8

ptr_container: ptr_map_adapter interface
by Slawomir Lisznianski 26 Dec '05

26 Dec '05

Hello, I've been using ptr_map lately and have a few questions regarding its interface. Below is a signature of `insert' function as declared in ptr_map_adapter: std::pair<iterator,bool> insert( key_type& k, value_type x ); Why is `k' a non-const reference? To imply ownership transfer, couldn't `x' be of `std::auto_ptr<value_type>' type instead? What happend to std::pair as an argument of insert? Was symmetry with std::map dropped for a reason here? Cheers, Slawomir Lisznianski

1 0

[smart-ptr] no link to enable_shared_from_this docs
by Ronald Garcia 25 Dec '05

25 Dec '05

I just recently discovered the enable_shared_from_this.hpp header file and located its documentation by searching, but there appears to be no link to it from the smart pointer library documentation. Should there be one? Thanks, ron

2 1

Re: [boost] Patch for mingw-tools.jam
by Janusz Piwowarski 24 Dec '05

24 Dec '05

.. and missed patch. -- Regards, Janusz

2 1

[MultiIndex] proposal - delayed index initialisation and maintenance
by Neil Hunt 24 Dec '05

24 Dec '05

I am just sort of throwing this out there as a wild idea. Having a trait on any given index such that it is only initialised upon first access. The motivation being - When displaying a table of rows of fields, the user may not necessarily click on any given column header for sorting, and would only rarely click on the majority of column headers. Therefore it is not required to maintain any given column index unless the user has requested sorting by that index. Neil

3 5