- Boost - lists.boost.org

RE: [boost] Latest version of the profiler
by Brian Braatz 10 Feb '05

10 Feb '05

> -----Original Message----- > Subject: [boost] Latest version of the profiler > > I have updated the profiler library to take into account many of the > excellent suggestions. I have tried to give acknowledgements where it is > due, please let me know if I have overlooked anyone. > > The latest version is at: http://www.cdiggins.com/profiler > > The major changes are: > - defining BOOST_PROFILING_OFF causes all member calls to become empty > statements > - basic_profiler now has three policies: logging, stats, timer > - profiler now supports: restart, stop, pause, resume, generate_report > - fixed QueryPerformanceCounter() api bug in HighResolutionTimer > [Brian Braatz] Hahahahaha " Macros were avoided because everyone knows macros are evil, unless we are the ones writing them." I LOVE THIS LINE. Please keep it in :) On a serious note though, with your lib done the way it is , if someone WANTS macros, there is nothing preventing them from having them. I for example- MIGHT take your library and stuff __FILE__ __LINE__ into the id. For this I would use a macro. This is also why I made the request for the char*name type to be a template param. I may want to plop in my own struct that has the __FILE__ and __LINE__ in it.

2 1

RE: [boost] Latest version of the profiler
by Brian Braatz 10 Feb '05

10 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of christopher diggins > > I have updated the profiler library to take into account many of the > excellent suggestions. I have tried to give acknowledgements where it is > due, please let me know if I have overlooked anyone. > > The latest version is at: http://www.cdiggins.com/profiler > > The major changes are: > - defining BOOST_PROFILING_OFF causes all member calls to become empty > statements > - basic_profiler now has three policies: logging, stats, timer > - profiler now supports: restart, stop, pause, resume, generate_report > - fixed QueryPerformanceCounter() api bug in HighResolutionTimer > > If you have brought an issue up previously (or think of a new one) which > you > feel is a significant omission of this library and would affect whether or > not you could use it, please feel free to bring it up again. > > I am still looking for a posix high-resolution timer. Hartmut suggested a > couple of Posix timers which he got off of Google, which unfortunately > were > unusable: one was GPL'ed and the other lacked source code. Gennadiy said > there were some on the mailing list (I couldn't find ), and that he uses > one > in the CVS but I don't know how to use the CVS. I also can not test Posix > timers, since I only use visual C++. I believe that perhaps > boost::date_time > contains a good resolution timer, but I can't tell. > [Brian Braatz] Christopher, I really like the way this is shaping up. I encourage you onward :) I am in the thick of some deep work things right now and will not be able to really play with this for a week or two, but by reading the docs it looks like it would be very usable for the types of problems I have with profiling. Suggestion \ Comments: A suggestion would be to make the TYPE for the name be a template param. (or maybe a typedef in the policy). For my needs, I need to store a structure in this place and not just a string. This goes back to the meta-data discussion awhile back. I believe the users of the library need to be able to give you the type to store for the id, this way I can use whatever ID concept I need to, and it means I can store extra metadata in that (without having to look it up in a separate map<> or something)

1 0

Re: boost::rtl / rel where can I get some more infos
by Vinzenz Feenstra 10 Feb '05

10 Feb '05

What do you think, how long it would take that rtl would be released with boost? ( I know I am asking too much but this would be the last question) BR and Many thanks Vinzenz

1 0

function_traits
by Joel de Guzman 10 Feb '05

10 Feb '05

Hi, I find the interface: function_traits<F>::arity function_traits<F>::result_type function_traits<F>::argN_type (especially the last) awkward in TMP code. In the interest of not having metafunction blobs, I'd suggest the interface: function_arity<F>::value function_result<F>::type function_arg_c<N, F>::type function_arg<mpl::int_<N>, F>::type In particular, I need the function_arg(_c) metafunctions. It is very awkward to get the Nth function argument, given a constant N. Thoughts? Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

4 6

Release 1.33
by Robert Ramey 10 Feb '05

10 Feb '05

I would hope that soon we might think of releasing an updated version of boost - 1.33 As far as I know this might include a)bug fixes for herefore untested combinations of compilers, varients, etc b)Jonathon Turkanis stream bufffer library c)Other libraries (Ranges?) d)Serialization library - bugfixes and DLL version Robert Ramey

6 15

RE: [boost] Wave C++ Review Begins Today - February 7, 2005
by Michiel Salters 10 Feb '05

10 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Doug Gregor > Sent: woensdag 9 februari 2005 17:23 > To: boost(a)lists.boost.org > Subject: Re: [boost] Wave C++ Review Begins Today - February 7, 2005 > ... > Even dereferencing *last could be a bug, if it is > past-the-end. For iterators referencing contiguous memory > (vectors and pointers only, as you've said), one would need to write > > scanner.last = scanner.first + std::distance(first, last); True, but that's an partial fix. For now, I've fixed that bug too in my vector<char> wrapper but it's becoming complex. I'm afraid someone will have to write re2cpp. > > I really have to say Dinkumware did a fine job here, this > would have > > been very hard to find without these checks. > > FWIW, STLport and newer versions of GCC (Apple GCC 3.3, FSF > GCC 3.4) have similar debugging modes. They've been > invaluable in rooting out subtle bugs like those that stem > from iterator invalidation. Yep, although I'm currently wondering if they're 100% right. Is it legal to compare iterators from different containers? I can't find the appropriate wording so I'll just trust Dinkumware here. My current problem is, somewhere deep down in cpp_macromap.hpp a simple innocent if (first != last) statement (line 433) triggers another assertion. These are iterator_facade's (which I don't grok) and end up comparing iterators to two distinct containers. Looking the other way on the callstack, I see some deeply suspect iterators (singular, destroyed, ?) Too messy to say what happened. Regards, Michiel Salters This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

6 7

RE: [boost] Re: Wave C++ Review Begins Today - February 7, 2005
by Michiel Salters 10 Feb '05

10 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Paul Mensonides > Sent: woensdag 9 februari 2005 23:44 > To: boost(a)lists.boost.org > Subject: RE: [boost] Re: Wave C++ Review Begins Today - > February 7, 2005 > > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org > > [mailto:boost-bounces@lists.boost.org] On Behalf Of Hartmut Kaiser [ attribution already lost ] > > > b. Sometimes it may be useful to be able to "partially > > > preprocess" given source. E.g. I would like to > > > have cleaner version of STLport just for my platform. > > > > > > It would be nice if I could specify list of > > > #defines and #undefines to be processed, the rest > > > left as is. > > > > Hmmm, that's more complex, I'll have to think about this. > > That is actually a lot more complex. It implies a heavy duty > dependency analysis on, for example, macros. I think that > implementing this would be more complex (to do correctly) > than the entire preprocessor altogether. I've been thinking about this as well. I'm not sure if we actually want the same, but my idea was to have a partial-evaluation mode which would replace only those tokens actually defined, and evaluate only those #ifdef( )/#if statements that depend on the macros explicitly defined or undefined. I suspect the major internal difference is that in full evaluation a macro is either defined or undefined, while in partial evaluation it can also be not evaluated. The technically tricky stuff is probably neatly rewriting complex #if (a&&b||c) conditions. Requirement-wise it's what to do with #include'd files. Regards, Michiel Salters This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

[range] wrong OS assumed when intel compiler is used
by Martin Wille 10 Feb '05

10 Feb '05

Hi, there's again code in Boost which incorrectly assumes Windows when Intel C++ is used. E.g. I see this error here: intel-linux-C++-action ../bin/boost/libs/range/test/mfc.test/intel-8.1-linux/debug/mfc.o /boost/head-regression/boost/boost/range/detail/mfc/cstring.hpp(18): catastrophic error: could not open source file "afx.h" #include <afx.h> // for CString The range library also has problems regarding its use of Boost.Test: intel-linux-C++-action ../bin/boost/libs/range/test/std_container.test/intel-8.1-linux/debug/std_container.o ../libs/range/test/std_container.cpp(27): error: namespace "boost::unit_test" has no member "test_suite" using boost::unit_test_framework::test_suite; Regards, m

1 0

[boost.indirect container] RFC on interface changes
by Thorsten Ottosen 09 Feb '05

09 Feb '05

Dear all, I'm working on getting the indirect container library (former smart container lib) ready for a post-review. During the review it was decided to provide overloads of assign(), insert() etc that takes a Range instead of two iterators. That is often a problem because of multiple overloads, that is, we get ambiguity. Basically I think we got two alternatives: 1. template< class Iter > void container::assign( const iterator_range<Iter>& ); ... container c; c.assign( make_iterator_range( some_range ) ); 2. template< class Range void container::assign_range( const Range& ): .... container c; c.assign_range( some_range ); Which one do you prefer? Another issue relates to the null pointer policy, that is, the way we specify how the container is allowed to include nulls. Here's two alternatives: 1. container< T > // null not allowed container< nullable<T> > // null allowed 2. container<T&> // null forbidden container<T*> // null allowed Thansks for your feedback. -Thorsten -- Thorsten Ottosen ---------------------------- Dezide Aps -- Intelligent Customer Support: www.dezide.com Aalborg University --- Decision Support Systems: http://www.cs.aau.dk/index2.php?content=Research/bss C++ Boost: www.boost.org C++ Standard: http://www.open-std.org/JTC1/SC22/WG21/

2 4

Checking out latest Boost lock problem
by Edward Diener 09 Feb '05

09 Feb '05

Attempting to check out the latest Boost I am being stopped by: cvs checkout: [23:53:01] waiting for agurtovoy's lock in /cvsroot/boost/boost/libs/utility/doc

22 57