- Boost - lists.boost.org

Re: [boost] Possible Placeholder problem with transform & if_ (?)
by Brian Braatz 27 Jul '05

27 Jul '05

Ok - I just fixed this- I don't understand WHY it fixed it but it did. I moved the if_<> into a metafunction class and passed the metafunction class to transform. I would think that either using it inline or as a mfc would be equivalent. (out of curiosity)- Anyone know the answer to this why this is the case? > -----Original Message----- > From: Brian Braatz > Sent: Wednesday, July 27, 2005 3:41 PM > To: 'boost(a)lists.boost.org' > Subject: MPL:Possible Placeholder problem with transform & if_ (?) > > Either something strange is happening with arg<> and transform or I did > not write this code correctly. ( :) ) > > Any help pointing me to either conclusion appreciated. The next step is to > try the same algorithm with transform_view. I really don't want a lazy > sequence (how could mother be proud?), but sometimes life is > disappointing. > > Thanks Guys. > > CODE: > > struct print_type > { > std::ostream & m_os; > print_type(std::ostream & os = std::cout) > : m_os(os) {} > > template <typename T> > void operator()(T const& v) const > { > m_os << "[ " << typeid(v).name() << " ] "; > } > }; > > template <class seq_t> > void _print_types(const char * pHeading) > { > std::cout << "** " << pHeading << std::endl; > mpl::for_each<seq_t>(print_type()); > std::cout << std::endl; > } > #define print_types(seq) _print_types<seq>(#sew); > > template <class T> > struct YES > { > typedef YES type; > }; > template <class T> > struct NO > { > typedef NO type; > }; > > struct A{}; > > typedef mpl::vector<A> vec_t; > > typedef mpl::transform > < > vec_t, > mpl::if_ > < > boost::is_same<mpl::_1, A >, > YES< mpl::_1 >::type, > NO< mpl::_1 >::type > >::type > >::type result; > > void test() > { > print_types (result); > > /* ////////////////////////// > > PRINTS: > > ** result > [ struct NO<struct A> ] > > SHOULD PRINT: > > ** result > [ struct YES<struct A> ] > > //////////////////////////// > */ > }

1 0

token_iterator flaw, format and date_time shadowing, regex gcc.mak problem, and Boost.Format suggestion
by Stephan T. Lavavej 27 Jul '05

27 Jul '05

Hi, I have noted the following about Boost 1.32.0. 1. boost/token_iterator.hpp is very broken on line 34. template <class TokenizerFunc, class Iterator, class Type> class token_iterator : public iterator_facade< token_iterator<TokenizerFunc, Iterator, Type> , Type // ********** SHOULD READ: const Type , typename detail::minimum_category< forward_traversal_tag , typename iterator_traversal<Iterator>::type >::type , const Type& > GCC 3.4.2 refuses to compile this when broken. 2. boost/format/format_implementation.hpp contains shadowing on line 28. The constructor takes 'str', which is named identically to a member function. 3. boost/date_time/time_duration.hpp contains shadowing on line 53. The constructor takes 'hours', 'minutes', and 'seconds', which are named identically to member functions. 4. boost/date_time/time_system_counted.hpp contains shadowing on line 34. The constructor takes 'tod', which is named identically to a member function. Shadowing makes using Boost with GCC -Wshadow difficult, and these cases are very easy to fix. 5. libs/regex/build/gcc.mak mentions '-I../../../' twice. This breaks compilation on MinGW. '-I../../..' ought to work everywhere (it does on MinGW). 6. Suggestion: It would be useful if Boost.Format were capable of delayed evaluation. int main() { format mommy("%1% %1%"); format kiddy("x%1%y"); mommy % kiddy; kiddy % 10; cout << mommy << endl; } Thanks, Stephan T. Lavavej

4 3

[Boost-bugs] [ boost-Bugs-1246358 ] interval evaluation bug
by SourceForge.net 27 Jul '05

27 Jul '05

Bugs item #1246358, was opened at 2005-07-27 14:46 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=1246358&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: interval evaluation bug Initial Comment: evaluation of sin of [0,1] with interval template specification typedef boost::numeric::interval< double, boost::numeric::interval_lib::policies< boost::numeric::interval_lib:: save_state< boost::numeric::interval_lib:: rounded_transc_exact<double, boost::numeric:: interval_lib::rounded_arith_opp<double> > >, boost::numeric::interval_lib:: checking_strict<double> //boost::numeric::interval_lib:: checking_base<double> > > Interval; and rint definition in ms Windows static double inline rint( double x) // Copyright (C) 2001 Tor M. Aamodt, University of Toronto // Permisssion to use for all purposes commercial and otherwise granted. // THIS MATERIAL IS PROVIDED "AS IS" WITHOUT WARRANTY, OR ANY CONDITION OR // OTHER TERM OF ANY KIND INCLUDING, WITHOUT LIMITATION, ANY WARRANTY // OF MERCHANTABILITY, SATISFACTORY QUALITY, OR FITNESS FOR A PARTICULAR // PURPOSE. { if( x > 0 ) { __int64 xint = (__int64) (x+0.5); if( xint % 2 ) { // then we might have an even number... double diff = x - (double)xint; if( diff == -0.5 ) return double(xint-1); } return double(xint); } else { __int64 xint = (__int64) (x-0.5); if( xint % 2 ) { // then we might have an even number... double diff = x - (double)xint; if( diff == 0.5 ) return double(xint+1); } return double(xint); } } gives incorrect result: so sin([0,1]) = [ 0.841471 , -1.60814e-016 ] Thats looks incredible!!! How can i fix it out? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1246358&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-1246336 ] reverse_graph and constness of property maps
by SourceForge.net 27 Jul '05

27 Jul '05

Bugs item #1246336, was opened at 2005-07-27 16:04 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=1246336&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: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: reverse_graph and constness of property maps Initial Comment: accessing properties in a reverse_graph often fails because it's getting the "::type" when it should be getting the "::const_type", and vice-verse. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1246336&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-1246308 ] MSVC support
by SourceForge.net 27 Jul '05

27 Jul '05

Bugs item #1246308, was opened at 2005-07-27 13:08 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=1246308&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: config Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: MSVC support Initial Comment: rint function is not declared in any of MSVC's include files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1246308&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

SF CVS having problems. ?? release delay ??
by Rene Rivera 27 Jul '05

27 Jul '05

As some of you may have noticed starting last night CVS access is not possible. This is currently preventing me from checking in changes to the explicit markup file. And of course also preventing me from getting any updates, and preventing it would seem the boost-consulting mirror from getting updated. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 2

[Signals] Proposal effort for TR2
by Doug Gregor 27 Jul '05

27 Jul '05

At the C++ committee meeting in Lillehammer last April, I'd asked if there was any interest in a TR2 proposal for the Signals library, and got a positive response. I'll be collaborating with the libsigc++ folks to put together a proposal for the upcoming meeting, which will be discussed on the libsigc mailing list: http://mail.gnome.org/mailman/listinfo/libsigc-list We'll naturally be taking the good features from both libraries (tracking, combining, syntax, etc.) and tossing out the bad (*ahem* named slot groups). Interested Boosters are welcome to join us over in that forum. Doug

1 0

Boost.Serialization archive constructor performance
by Kim Barrett 27 Jul '05

27 Jul '05

I've been experimenting with the Boost.Serialization library, to decide whether to use it in a project I'm working on. If it weren't for some performance issues, the decision of whether to use this library would be a no-brainer. Because it seemed otherwise so promising, I've spent some time investigating these performance issues, and have a couple of suggestions for improvements that would address them. (Obviously these suggestions are for post-1.33 release.) The use case being considered is marshalling values for transport to some other process. This is among the use cases discussed in the overview section of the library's documentation. However, it turns out that with relatively fine-grained marshalling operations, constructor / destructor time for the archive can amount to a significant fraction of the time spent in performing such an operation. The thing that seems to be using up most of the time is the initialization of various standard containers (std:set, std::vector, std::list), most of which are used for pointer tracking. For reference, a snippet to show the sort of thing I'm doing. (Please ignore the fact that this code snippet is obviously not thread-safe and similar issues; I've simplified things to show just the parts relevant to this issue.) const int binary_archive_flags = boost::archive::no_header | boost::archive::no_codecvt; const std::size_t size 64; static char buffer[size]; // allocate stream once, and reset for reuse static boost::iostreams::stream<io::array_sink> out(buffer, size); out.seekp(0); #if REUSE_ARCHIVES // allocate archive once, and reset for reuse static boost::archive::binary_oarchive oa(out, binary_archive_flags); oa.reset(); #else boost::archive::binary_oarchive oa(out, binary_archive_flags); #endif save_ss(ss, oa); // write ss into archive oa // arrange for destination process to receive the contents of // buffer containing serialized ss A change which I think should be not too difficult to make, and which would make a large difference, would be to provide a mechanism for resetting and reusing an archive. As part of my experiments I added a public void reset() operation boost::archive::detail::basic_iarchive and basic_oarchive, which clear the various tracking related containers in the associated pimpl objects. I then modified my tests to allocate their archives once and reset before each use. The result was a significant speedup. Rather than spending roughly 1/3 of the time in archive construction / destruction, the archive reset time is now close to the noise level in my measurements. (As you can see in the above code snippet, I'd already started reusing the streams for similar reasons.) I'm not necessarily proposing exactly the interface I used here for experimentation. A better interface might be to reset the archive when the associated stream is changed (which involves adding an interface for changing the stream, of course). But I'm not sure that's right either, since there is some separation between the stream handling part and the pointer tracking part of things. Perhaps there is an intent to support something other than streams, by using something other than boost::archive::basic_binary_[i,o]primitive? I think that once the details of this interface are determined, the implementation is pretty straight-forward. A second change, which may or may not be worthwhile, would be to avoid allocating the various tracking-related containers at all when the archive is created with no_tracking specified. With archive reuse as described above, this probably wouldn't make any directly noticeable performance difference for my usage. It might make a difference in space usage though, as the design I'm investigating this library for might end up with a significant number of archives devoted to various specific things, with pointer-less data being common in this design. So avoiding the allocation of a bunch of always empty containers, might be worthwhile, depending on the space used by such. This seems like it might be significantly more difficult to implement than the reuse support though. And whether it is actually worth doing depends on the internal implementation of the standard containers being used.

5 8

Re: [boost] [wave]: possible use for makefile dependencies
by Martin Bonner 27 Jul '05

27 Jul '05

----Original Message---- From: Pavel Vozenilek [mailto:pavel_vozenilek@hotmail.com] Sent: 26 July 2005 17:09 To: boost(a)lists.boost.org Subject: [boost] [wave]: possible use for makefile dependencies > Hello Hartmut, > > Wave executable could have feature for use > in makefiles or makefile generators. [snip] > Most likely output consisting from only > space separated dependent headers > (no *.obj, no foo.c itself) is the best ouput > as the text is futher manipulated. That breaks horribly as soon as you have any headers whose names contain spaces! (P.S. Is this the correct list for this?) -- 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] Interest in a binary_int template for binary literals?
by Scott Schurr 26 Jul '05

26 Jul '05

Greetings, I'm back from vacation. I have a note and a question regarding the binary_int template. 1. I've compiled the binary_int template with Microsoft Visual Studio.NET version 7.0. It gets unhappy when the most significant bit is set in a 32-bit binary word. The compiler reports: warning C4307: '*' : integral constant overflow along with a bunch of other stuff about the template instantiation. It seems to be only a warning however, since the executable is still produced and runs properly. I tried a couple of things in the enum definition to try and convince the compiler to use an unsigned int for the computation, but to no avail. I couldn't figure out a way to get rid of the warning. 2. Pavel Vozenilek thinks that the names binary_nibble and binary_int could be improved on. Pavel suggests the names 'nibble' and 'bits', noting that the term 'binary' has too many connotations in C++. At any rate, what do folks think would be good names for these two templates? Thanks. Scott Schurr

2 1