- Boost - lists.boost.org

preprocessor fix
by Arias Brent-P96059 19 Nov '04

19 Nov '04

I've invented a printable enum, based on the Boost preprocessor programming lib. But although the printable enum works, I think my efforts revealed a bug in Boost. The BOOST_PP_SEQ_ENUM preprocessor macro doesn't work with the empty "false" result of BOOST_PP_EXPR_IIF. This has forced me to do hacks like this: #define ENUM(name, start, entries)\ BOOST_PP_SEQ_ENUM( \ BOOST_PP_IIF(ENUMS, \ (typedef enum{ BOOST_PP_SEQ_HEAD(entries) = start) \ BOOST_PP_SEQ_TAIL(entries) \ (LAST_##name } name;) \ , \ (static void PP_NILFUNC();) \ ) \ ) As you can see in the above definition, I've included an explicit "false" clause for BOOST_PP_IIF() that expands into the harmless (and utterly superfluous) expression "static void PP_NILFUNC();". I would instead have preferred to use BOOST_PP_EXPR_IIF and thus avoid the eye-sore. But the hack was necessary, as I said before, because BOOST_PP_SEQ_ENUM does not elogantly handle the empty "false" result of BOOST_PP_EXPR_IIF. Can this be fixed? -Brent

3 3

[Boost-bugs] [ boost-Bugs-1069225 ] date_time type conversion warning
by SourceForge.net 19 Nov '04

19 Nov '04

Bugs item #1069225, was opened at 2004-11-18 21:21 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=1069225&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: date_time type conversion warning Initial Comment: from boost 1.32.0 final draft tarball. d:\development files\boost 1.32.0 \include\boost\date_time\date_parsing.hpp(211) : warning C4244: 'argument' : conversion from '_STL::basic_string<_CharT,_Traits,_Alloc>::value_t ype' to 'char', possible loss of data with [ _CharT=wchar_t, _Traits=_STL::char_traits<wchar_t>, _Alloc=_STL::allocator<wchar_t> ] d:\development files\boost 1.32.0 \include\boost\date_time\date_parsing.hpp(253) : see reference to function template instantiation 'date_type boost::date_time::from_stream_type<date_type,_STL::b asic_string<_CharT,_Traits,_Alloc>::iterator> (iterator_type &,iterator_type &,wchar_t)' being compiled with [ date_type=boost::gregorian::date, _CharT=wchar_t, _Traits=_STL::char_traits<wchar_t>, _Alloc=_STL::allocator<wchar_t>, iterator_type=_STL::basic_string<wchar_t,_STL::char_tr aits<wchar_t>,_STL::allocator<wchar_t>>::iterator ] d:\development files\boost 1.32.0 \include\boost\date_time\gregorian\parsers.hpp(78) : see reference to function template instantiation 'boost::date_time::period<point_rep,duratio n_rep> boost::date_time::from_simple_string_type<boost::grego rian::date,wchar_t>(const _STL::basic_string<_CharT,_Traits,_Alloc> &)' being compiled with [ point_rep=boost::gregorian::date, duration_rep=boost::gregorian::date_duration, _CharT=wchar_t, _Traits=_STL::char_traits<wchar_t>, _Alloc=_STL::allocator<wchar_t> ] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1069225&group_… ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[assign] documentation bug
by Caleb Epstein 19 Nov '04

19 Nov '04

In the assign library documentation page <boost>/libs/assign/doc/index.html#repeat: v = list_of(1).repeat(5,2)(3); // v = [1,2,2,2,2,2,3] BOOST_ASSERT( v.size() == 1 + 5 + 3 ); push_back( v )(1).repeat(1,2)(3); // v = old v + [1,2,3] BOOST_ASSERT( v.size() == 12 ); I think the first BOOST_ASSERT should be BOOST_ASSERT (v.size() == 1 + 5 + 1) and the last one should be BOOST_ASSERT( v.size() == 10 ); -- Caleb Epstein caleb.epstein(a)gmail.com

3 3

[1.32] dynamic_bitset docs
by Pavel Vozenilek 19 Nov '04

19 Nov '04

Documentation for dynamic_bitset contains TODO notes at the beginning. Maybe they should be removed for Release, they are of little value for user and rather give impression of library being unfinished. Chapter "Changes from previous version(s)" contains striken text "reserve(), capacity()" that may be removed (functions are present but undocumented).. /Pavel

2 1

[progress] progress_timer inserts \n and std::endl
by Caleb Epstein 18 Nov '04

18 Nov '04

Is there any that boost::progress_timer to inserts *both* \n and std::endl to the output stream when it is destroyed? I think it should just do the std::endl. -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

bug in bgl?
by Eyal Farago 18 Nov '04

18 Nov '04

I'm trying to use the edge(u, v, g) on a revese_grap h, I get a stack overflow after the programs enters an infinite loop(or actually infinite recursive call). once looking at the selected overload I could see a very strait-forward correction: template <class BidirectionalGraph, class GRef> inline std::pair<typename BidirectionalGraph::edge_descriptor, bool> edge(const typename BidirectionalGraph::vertex_descriptor u, const typename BidirectionalGraph::vertex_descriptor v, const reverse_graph<BidirectionalGraph,GRef>& g) { return edge(v, u, g); //this should be: edge(v, u, g.mg) } the next call to edg(...) shoul pass the adapted grap. eyal.

2 1

RE: [boost] Re: [Review] Named parameters library
by Stefan Seefeld 18 Nov '04

18 Nov '04

> From: Doug Gregor [mailto:dgregor@cs.indiana.edu] > Since I've been researching in this area for several years... > > Dave is correct: no compiler out there is going to optimize this, > because the side effects are killer. It is possible to analyze that > behavior and perform the optimization Thorsten is describing, but > > (1) There are better ways than looking at it from the memory > subsystem/pointer magic angle > (2) This is very much an open research area; don't > expect this from a > research compiler for at least 2 years. > (3) This is very much an open research area; don't > expect this from a > commercial compiler for at least 10 years. > > Copy elision and the RVO are all we have. We can't rely on anything > more than that. out of curiosity: what about the LD_PRELOAD trick that's used on ELF systems to replace symbols at startup ? It's notably used by some tools to swap in special versions of operator new/delete to analyze memory management without the need to recompile anything. Is there any way for a compiler to know that some calls can be fully evaluated at compile-time ? Thanks, Stefan

2 1

[review] Formal review of the Smart Container library ends today
by Pavol Droba 18 Nov '04

18 Nov '04

Hi All, Formal review of the Smart Container library ends today. I'd like to thank you all, that participated and offered opinions about this library. I will now take my time as the review manager to sumarize the conclusion for the final verdict. Best regards, Pavol PS: There is still a little time to submit a review if somebody is willing to do so.

2 2

index.htm: gratuitous HTML reformatting
by David Abrahams 18 Nov '04

18 Nov '04

It appears that recent changes to our index page changed all tags on the index page to uppercase. From cvs annotate: ... 1.186 (rogeeff 28-Oct-04): </P> 1.186 (rogeeff 28-Oct-04): </TD> 1.186 (rogeeff 28-Oct-04): </TR> 1.186 (rogeeff 28-Oct-04): </TABLE> 1.186 (rogeeff 28-Oct-04): <TABLE> 1.186 (rogeeff 28-Oct-04): <TR> 1.186 (rogeeff 28-Oct-04): <TD> </TD> 1.186 (rogeeff 28-Oct-04): <TD> 1.186 (rogeeff 28-Oct-04): <P>The Boost.. ... Every line with a tag in it was last changed by "rogeeff". These kinds of sweeping changes are really bad for any source control system, especially when they're entirely unneccessary. In this case it's complicating the process of merging changes into the release branch. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

5 6

[More IO] Review Status?
by Jonathan Turkanis 18 Nov '04

18 Nov '04

Dear Daryle or Tom, I can see from the most recent review schedule that the More IO library has been rejected, but I have not seen a review result posted. I'm interested to know the rationale for the rejection and future plans for More IO, since I would like to add the Iostreams library to CVS as soon as possible and several of the open issues depend on the status of More IO. For example, during the review of both libraries there was definite support for some sort of null_sink/null_buf. I'd like to know if I should go ahead and add these classes to the iostreams library, or whether I should wait for Daryle to produce a revised version of More IO. Certainly I can put off some of there decisions until later, but I'd rather take a few days and prepare a revision of the Iostreams library all at once. Best Regards, Jonathan

2 1