- Boost - lists.boost.org

Shouldn't both logging proposals be reviewed in the same formal review?
by Andreas Huber 20 Nov '09

20 Nov '09

According to the schedule, John Torjo's Log2 library will be reviewed soon (currently 3rd in the queue). There's another logging proposal by Andrey Semashev (currently 13th in the queue). It seems to me that these proposals are sufficiently close in functionality that only one of them should be accepted into Boost. Therefore, wouldn't it make sense to review both libraries in one (longer) formal review? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

19 42

[Variant] [BGL] Variant<edge_descriptor, edge_descriptor> is not EqualityComparable
by Cosimo Calabrese 20 Nov '09

20 Nov '09

Hi to all, this discussion is linked to "Boost.Variant is not EqualityComparable". I've opened a new one because to involve the BGL argument. The problem is simply this. I've created a union graph adaptor, that provides a "union view" of two graphs; in that adaptor, the edge_descriptor is defined like this: typedef boost::variant< WR1<typename graph_traits<Graph1>::edge_descriptor>, WR2<typename graph_traits<Graph2>::edge_descriptor> > edge_descriptor; Now I would to use that graph to the Dijkstra's algorithm, that requires that the edge_descriptor models the EqualityComparable concept. But as we know, boost::variant doesn't support the inequality expression ( v1 != v2 ). I've tried to add it from my code (I would avoid to modify the boost lib), but it doesn't works. I'm using MSVS 2005 on WinXP, boost 1.38. I've tried to add the following line, as suggested by Stefan Strasser (thanks Stefan): using namespace std::rel_ops; to add the generic operator!=(), but the compiler doesn't find it, the compiler error is the same. Now I try to provide to you more details. If it isn't enough, I can provide the entire code. I've defined the graph adaptor like this: ////// union_graph.hpp ////// #include <boost/graph/graph_traits.hpp> #include <boost/graph/properties.hpp> #include <boost/graph/adjacency_iterator.hpp> #include <boost/graph/graph_utility.hpp> #include <boost/graph/exception.hpp> #include <boost/variant.hpp> namespace boost { template <typename T> class WR1 { /* ... */ }; template <typename T> class WR2 { /* ... */ }; template <typename Graph1, typename Graph2> class union_graph { public: typedef Graph1 graph_type1; typedef Graph2 graph_type2; // Constructor union_graph( Graph1& g1, Graph2& g2 ) : m_g1(g1), m_g2(g2) { /* ... */ } // Graph requirements typedef boost::variant< WR1<typename graph_traits<Graph1>::vertex_descriptor>, WR2<typename graph_traits<Graph2>::vertex_descriptor> > vertex_descriptor; /* ... */ // IncidenceGraph requirements typedef boost::variant< WR1<typename graph_traits<Graph1>::edge_descriptor>, WR2<typename boost::graph_traits<Graph2>::edge_descriptor> > edge_descriptor; /* ... */ }; // EqualityComparable concept, requested by IncidenceGraph concept template <typename Graph1, typename Graph2> inline bool operator!=( const typename boost::graph_traits< boost::union_graph<Graph1, Graph2> >::edge_descriptor& left, const typename boost::graph_traits< boost::union_graph<Graph1, Graph2> >::edge_descriptor& right ) { return !( left == right ); } and I've used it like this: ////// main.cpp ////// #include "union_graph.hpp" int main() { typedef adjacency_list<...> Graph1; typedef adjacency_list<...> Graph2; typedef union_graph<Graph1, Graph2> UG; Graph1 g1( 10 ); Graph1 g2( 10 ); UG ug( g1, g2 ); graph_traits<UG>::edge_descriptor e1; graph_traits<UG>::edge_descriptor e2; tie( e1, existence ) = edge( v1, v2, g ); tie( e2, existence ) = edge( v1, v2, g ); e1 != e2; } The first part of the template compiler error is: 1>D:\dev\CommesseAperte\Sviluppo\TELLUS36_Librerie\boost_1_38_0\boost/concept_check.hpp(233) : error C2678: binary '!=' : no operator found which takes a left-hand operand of type 'boost::variant<T0_,T1>' (or there is no acceptable conversion) 1> with 1> [ 1> T0_=boost::WR1<boost::detail::edge_desc_impl<boost::directed_tag,__w64 unsigned int>>, 1> T1=boost::WR2<boost::detail::edge_desc_impl<boost::directed_tag,__w64 unsigned int>> 1> ] Can someone help me? I wouldn't hack the lib, because I will do it to every new version of Boost... Thanks in advance, Cosimo Calabrese.

5 17

[type_traits][V1.41] is_base_of<void, void> gives different results for gcc and vc
by Hartmut Kaiser 20 Nov '09

20 Nov '09

Hey, I just realized that is_base_of<void, void> gives different (inconsistent) results at least for gcc 4.3.2 (which evaluates this to false) and vc2005sp1 (evaluates to true, as earlier versions of boost did consistently, btw). This is truly a border case, but should expose consistent behavior anyways. Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com

3 5

[Release Mgt] Vladimir Prus joins release management team
by Beman Dawes 20 Nov '09

20 Nov '09

Vladimir Prus, aka Volodya, has been a big help in getting out timely, high-quality releases for a long time, and has now become an official release manager. Please welcome Volodya to the release team! --Beman --Daniel --Eric --Rene

1 0

Re: [boost] [Boost C++ Libraries] #3644: Getting starting simplified build from source should use a log file.
by Paul A. Bristow 20 Nov '09

20 Nov '09

> -----Original Message----- > From: Boost C++ Libraries [mailto:noreply@lists.boost.org] > Sent: Thursday, November 19, 2009 8:44 PM > Cc: boost-bugs(a)lists.boost.org > Subject: Re: [Boost C++ Libraries] #3644: Getting starting simplified build from source > should use a log file. > > #3644: Getting starting simplified build from source should use a log file. > --------------------------------------+------------------------------------- > Reporter: pbristow | Owner: > Type: Bugs | Status: new > Milestone: Boost 1.42.0 | Component: Building Boost > Version: Boost 1.41.0 | Severity: Problem > Keywords: simplified library build | > --------------------------------------+------------------------------------- > > Comment(by vladimir_prus): > > Would printing this information at the end of the build address your > concerns? Well yes it would, but surely it is always better to have a log file so you can check it went OK? Or will checking %errorlevel% tell the user that? But checking %errorlevel% doesn't tell you what libraries you have just built. (If you are using the simple 'default' build, you may not care?) Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

2 2

Re: [boost] [Boost C++ Libraries] #3646: Boost.test build of libraries - warnings ttat could be silenced.
by Paul A. Bristow 20 Nov '09

20 Nov '09

> -----Original Message----- > From: Boost C++ Libraries [mailto:noreply@lists.boost.org] > Sent: Friday, November 20, 2009 3:24 AM > Cc: boost-bugs(a)lists.boost.org > Subject: Re: [Boost C++ Libraries] #3646: Boost.test build of libraries - warnings ttat could > be silenced. > > #3646: Boost.test build of libraries - warnings ttat could be silenced. > ---------------------------+------------------------------------------------ > Reporter: pbristow | Owner: rogeeff > Type: Patches | Status: new > Milestone: Boost 1.42.0 | Component: test > Version: Boost 1.41.0 | Severity: Cosmetic > Keywords: test warnings | > ---------------------------+------------------------------------------------ > > Comment(by steven_watanabe): > > These should probably be disabled in the source, since Boost.Test can be > used with direct #include instead of a library. Yes - but I was trying to be realistic and not over-flagellate ;-) Paul

1 0

Re: [boost] Shouldn't both logging proposals be reviewed in the same formal review
by Tom Brinkman 20 Nov '09

20 Nov '09

Vladimir Batov wrote >> Yes, it sounds very uplifting and inspiring... and I would agree with that >> whole-heartedly... if I considered Boost merely the place of purely academic >> exercise. For many "average" programmers though the Boost libs is first and >> foremost a product that they want to *use* uniformly throughout a project, many >> projects. In that light from the commercial deployment and project management >> points of view having 2 (or worse -- plethora of) functionally-similar >> facilities readily available is a nightmare as some will end up using one >> facility and some others will prefer another facility. Shared knowledge is >> fragmented (people rarely have time and capacity to know all), code reviews, >> maintenance are difficult, the ultimate product looks unprofessional due to >> inconsistencies (in case of logging configurations, formats, destinations will >> be different). It's not an imaginary situation -- our project for various >> reasons ended up using 3 logging facilities with the very real problems >> described above. Rectifying the problem now is an expensive and tiring exercise. >> Do not get me wrong. I am all for creativity, innovation and healthy competition >> of ideas. However, all that does not have to be dumped onto the user to decide >> -- users often have no time, capacity, qualifications, freedom to make an >> educated choice. More so, users often *want* the gurus (and the level of the >> Boost community is most certainly considerably higher than the average) to make >> that educated choice for them. It's like one going to a financial planner for >> help and the planner dumping all the options on to that poor soul. Now that poor >> customer/user has to be a financial planner himself to make an educated choice. It seems to me that you are trying to make boost into something its not. Boost has never been in the business of picking the best library in a particular domain. Its a place where promising libraries can live for a while, get used, and inspire new ideas and approaches. Some of these might make into the c++ standard. I do however agree with your larger point that boost does not SCALE well. Ten years from now, its highly likely that boost will become too large to manage. People will eventually start asking to distribute boost in parts, where the "core" libraries are separated from the "experimental" libraries. For boost to remain popular and successful, this issue will eventually have to be addressed. Fortunately, it probably does not need to be addressed for a few years.

3 2

Re: [boost] [python] 1.41.0 importing python extensions fails
by Okko Willeboordse 19 Nov '09

19 Nov '09

Solved it mistake on my side sorry

1 0

[python] 1.41.0 importing python extensions fails
by Okko Willeboordse 19 Nov '09

19 Nov '09

Using MSVC 2008 on windows server 2003, Python 2.6.2 Importing python extension modules fails. As an example I compiled the tutorial hello world example; char const* greet() { return "hello, world"; } #include <boost/python.hpp> BOOST_PYTHON_MODULE(hello_ext) { using namespace boost::python; def("greet", greet); in to a dll named hello_ext.pyd. When I try to import the extension I get; >>> import hello_ext Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: DLL load failed: The specified module could not be found. In the debugger I see that hello_ext.pyd is loaded and unloaded; 'python': Loaded 'D:\Projects\GAIUS\owillebo\temp\test\Debug\hello_ext.pyd' 'python': Unloaded 'D:\Projects\GAIUS\owillebo\temp\test\Debug\hello_ext.pyd' Digging in to it. Can anyone confirm this?

1 0

Shouldn't both logging proposals be reviewed in the same formal review
by Tom Brinkman 19 Nov '09

19 Nov '09

I was the review manager of the two futures libraries and a former review wizard. Two issues that I see: 1) Should we review two or more libraries at the same time No. Because of time commitments and lack of review managers, coordinating two reviews at the same time is too difficult. It has not worked. 2) Should we approve libraries that have significant duplication with another library already in boost? Yes. Each library should be reviewed independently, and approved if it meets the boost community standards. Boost libraries already has lots of overlap, no reason to change at this point. What we should do is encourage the authors to work together submit a combined library. Unfortunately, that has not worked either. The trend is probably going to be more and more library duplication, but this does not concern me. I would find it perfectly acceptable if another "command line" parser was approved, or even if another text parser was approved. The more the better. It shows that boost is still interesting place to come and see what talented c++ developers are up too. There are many ways to abstract a solution and build an interface around it. Boost should encourage a diversity of approaches.

2 1