February 2005 - Boost - lists.preview.boost.org

[Boost-bugs] [ boost-Patches-1115576 ] Patch 1.32 IRIX MIPSPro 7.4.1 [Test Bind Program Options]
by SourceForge.net 03 Feb '05

03 Feb '05

Patches item #1115576, was opened at 2005-02-03 17:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1115576&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: hxpro (hxpro) Assigned to: Nobody/Anonymous (nobody) Summary: Patch 1.32 IRIX MIPSPro 7.4.1 [Test Bind Program Options] Initial Comment: Some simple fixes to make the build work... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1115576&group_… ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

BOOST_PP_EXPR_IF Behavior
by John Eddy 03 Feb '05

03 Feb '05

I am not terribly familiar with the rules of the preprocessor. Is it the case that the expression of the BOOST_PP_EXPR_IF macro is expanded regardless of the resulting value of the condition? The reason I ask is because the following code produces a warning with VC7 .NET 2003. #define MY_MACRO(array) \ BOOST_PP_EXPR_IF( \ BOOST_PP_ARRAY_SIZE(array), \ BOOST_PP_TUPLE_TO_SEQ( \ BOOST_PP_ARRAY_SIZE(array), \ BOOST_PP_ARRAY_DATA(array) \ ) \ ) MY_MACRO((0, ())); The warning is: C4003: not enough actual parameters for macro 'BOOST_PP_EXPR_IIF_0' The macro expands correctly. Perhaps there is a better way to do what I am after. I would like to create a comma separated list (no parenthesis as would be the case if I only took the array data) from a possibly empty set. Thanks, John

2 2

allocator_utilites: problems with VC6
by Jonathan Turkanis 03 Feb '05

03 Feb '05

Hi, I'm trying to use allocator_utilities with VC6 in the following manner: template<typename Alloc> struct bzip2_allocator_traits { typedef typename boost::detail::allocator::rebind_to< Alloc, char >::type type; }; template< typename Alloc, typename Base = // VC6 workaround: C2516 BOOST_DEDUCED_TYPENAME bzip2_allocator_traits<Alloc>::type > struct bzip2_allocator : private Base { ... }; Unfortunately, I get the error C2039: 'rebind' : is not a member of 'fake_allocator<0>' Any suggestions? Jonathan

2 2

[filesystem] readdir_r on SunPRO
by Caleb Epstein 03 Feb '05

03 Feb '05

Just noticed this compile error for the latest CVS code using the SunPRO compiler: "/home/nbde52d/src/boost-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp", line 121: Error: readdir_r is not a member of file level. Here's the compile command: CC -c -g -xtarget=generic +d -features=rtti -features=except -features=tmplife -instances=static -I"/home/nbde52d/src/boost-regression/results/bin/boost/libs/filesystem/build" -I"/home/nbde52d/src/boost-regression/boost" -I"/home/nbde52d/src/boost-regression/boost" -o "/home/nbde52d/src/boost-regression/results/bin/boost/libs/filesystem/build/libboost_filesystem.a/sunpro-5_3/debug/operations_posix_windows.o" "/home/nbde52d/src/boost-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp" The -mt flag is not present, so including <dirent.h> does not pull in the readdir_r prototype. I think the use of ::readdir_r needs to be further protected with a check for whether MT code is being compiled (BOOST_HAS_THREADS?) -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

Was [RE: [boost] Moving from CVS to Subversion?] Now is "Subversion experiences from the field"
by Brian Braatz 03 Feb '05

03 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Walter Landry > Subject: Re: [boost] Moving from CVS to Subversion? > > David Abrahams <dave(a)boost-consulting.com> wrote: > > > > I am just posting this here to alert those who look at subject lines > > to what we're discussing. To review the whole discussion, see > > http://news.gmane.org/find- > root.php?message_id=%3cuk6pujjyu.fsf%40boost%2dconsulting.com%3e > > One thread you might find interesting > > http://news.gmane.org/find-root.php?group=gmane.comp.version- > control.subversion.devel&article=53583 > > It talks about the troubles Mono had in going from CVS to Subversion. > YMMV. > > My personal opinion is that, if you want a centralized version control > system, you aren't going to do significantly better than Subversion. > There are a fair number of large projects using it, and, especially > with the new fsfs backend, it seems to work pretty well for most > people. [Brian Braatz] I am currently running cvs and subversion side by side and wanted to share my experiences: We have been running CVS for 4 years and SVN for about 2 CVS **** We have about 50 people hitting one server CVS seems to handle this nicely We are using cvs for 2 projects Cvs add not being recursive is a pain in the butt. I am several states away from the cvs server I am currently STILL adding boost 1.32 to a repository I started this last Friday On the SVN repository, this took a few hours (same net connection) Also the recursive "svn add" command meant I did not have to baby sit it SVN (Subversion) **************** Svn add is recursive Most of the SVN commands are very similar to cvs Seems significantly faster than cvs We had ONE instance in 2 years where we lost data- IT guys never figured out what it was- might have been a power surge or SVN we don't know We have never lost data on the cvs server We are only running about 5 guys against our svn box You can move files and retain history Retrieving files FROM history is not as simple as cvs It uses the berkely db backend Which I am not familiar with nor are my people experts in it I can "svn add" while on an airplane, but I have to be online to "svn commit" It has transactional commits- Which means if something bombs halfway through a commit- NONE of the files are added We have been bit by this one on CVS in our projects My Opinion: I like SVN, but we have not completely switched over to it For Boost, the redundant servers from sourceforge is a compelling reason to stay cvs. I am not aware if you can get the same thing from sourceforge with svn. Svn does not however tax the server as much as cvs, hence there is more client side processing Anyone else have any experience with these two side by side they wish to share?

4 3

Simple regex problem
by Preston A. Elder 03 Feb '05

03 Feb '05

Hum, Consider the following application (running on Linux with GCC): === BEGIN CODE #include <boost/regex.hpp> #include <iostream> #include <exception> #include <typeinfo> int main() { try { std::string rx_string = "^([[:alpha:]][-[:alnum:]]*[[:space:]]*)+$"; boost::regex rx(rx_string, boost::regex_constants::char_classes | boost::regex_constants::intervals); std::string test = "GlobalMSG HelpServ DevNull"; if (boost::regex_match(test, rx)) std::cout << "Matched." << std::endl; else std::cout << "Not Matched." << std::endl; } catch (const std::exception &e) { std::cout << "Exception " << typeid(e).name() << ": " << e.what() << std::endl; } return 0; } === END CODE The result of running this is: Exception N5boost14bad_expressionE: Memory exhausted My question is, why? The regex is simple enough, and the source string is quite short. Please note, the same regex with the test string of: "OperServ Magick-1" runs and completes successfully without a problem. Any ideas on how to fix this? -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

3 3

CW and NOMINMAX
by Stefan Slapeta 03 Feb '05

03 Feb '05

Hi all, I wonder why NOMINMAX is defined globally for _all_ platforms in cw-tools.jam. # Some language related options flags cw C++FLAGS : -DNOMINMAX ; This produces warnings for some regressions due to redefinitions in the code! Aside from that, IMO it doesn't make sense to define NOMINMAX on other platforms than windows, no? If nobody objects, I would like to remove this line to see what happens. Stefan

1 0

New Library?
by John Eddy 03 Feb '05

03 Feb '05

Would anyone be interested in a library for doing logging? I've written one for my own purposes and thought others might find it useful. It will store log entries at various levels (FATAL, SHOUT, ERROR, WARN, INFO, DEBUG, DETAIL). There is a default level and the level can be customized for entries by individual instances of any type and for entries by any types as a whole. I'll be glad to provide more information if anyone is interested. John

8 14

Re: [boost] Re: Help needed with BGL & multi_index_container
by JOAQUIN LOPEZ MU?Z 03 Feb '05

03 Feb '05

Hi Alexander, ----- Mensaje original ----- De: Alexander <rhjrjlbk2002(a)yahoo.com> Fecha: Miércoles, Febrero 2, 2005 8:38 pm Asunto: [boost] Re: Help needed with BGL & multi_index_container > Hi Joaquin and Jeremy, > > Below you may find latest version of my test program. > This time it compiles, links and works :-). I have to > say - it was not easy to make it working. > > The only trouble I have is clumsy code in templated > ItemHolder::operator()(const P&p) and correspondent call > to template ItemHolder::get_int(...). See my comments > below. > > I'm looking for advice to make it nicer. I think I've got something, please read below. > > Replacement of "const P& p" to "void*" breaks VS 7.1. > [...] > > > From: Joaquin M Lopez Munoz <joaquin <at> tid.es> > > Date: Tue, 01 Feb 2005 22:51:12 +0000 > > MG::vertex_descriptor vd1 = > > add_vertex( ItemHolder( 1, Item(1) ), mg ); > > In this line following is happen: > > 1. adjacency_list allocates (with new) a new > stored_vertex structure to store property > element of type ItemHolder (yes, using my initialization > value), fields to store incoming, outgoing edges and > other fields. > > 2. This pointer is cast to a void *, to be used as > the new vertex descriptor. > > 3. The void * is fed to the multi_index_container used > for vertex storage. > > 4. Now, inside ItemHolderKey, that "void *" must be converted to back > to stored_vertex type, defined in base class of adajcent_list. And > thisI find as a real threat to break everything. To my regret, I > can't spend > more > time - I have to put all that into my project. > > > Well, all in all I must say this is a glorious hack :) > > Thank you! Indeed, you did helped me. > > > Probably, the only sensible approach is to write from > > scratch a graph-compliant structure that uses > > I already did that couple of times. I do not want that anymore. > Writing, testing, documenting, helping colleques to numerous > suboptimal versions of the same component, scattered through > number of versions of different products... No, thank you. > > > That said, the thing seems to work and may suffice > > for your purposes. > > I see that as a quite general use case. > > > It'd be great if some BGL expert (Jeremy?) jumped > > in and comment on this. > > Yes, that would be great. > > Kind Regards, > Alexander > > -------------- sample code -------------- > #include <iostream> > > #include <boost/multi_index_container.hpp> > #include <boost/multi_index/ordered_index.hpp> > #include <boost/multi_index/sequenced_index.hpp> > > #include <boost/graph/adjacency_list.hpp> > > using namespace boost; > using namespace boost::multi_index; > > using namespace std; > > template<class Index> > struct MICSelector > { > typedef Index index; > }; > > struct Item > { > Item(int _a=0, int _b=0, int _c=0) > : a(_a), b(_b), c(_c) {} > > int a,b,c; > > friend std::ostream& operator<< > (std::ostream& os, const Item& item) > { > return os << " a: " << item.a << > " b: " << item.b << " c: " << > item.c << " "; > } > }; > > struct ItemHolder > { > ItemHolder(int id=0, const Item item=Item()) > : m_ID(id), m_item(item) {} > > int m_ID; > Item m_item; > > friend std::ostream& operator<< > (std::ostream& os, const ItemHolder& item) > { > return os << " ID: " << item.m_ID > << " Item( " << item.m_item << ") "; > } > }; > > struct ItemHolderKey > { > typedef int result_type; > int operator()(const ItemHolder& v) const { return v.m_ID; } > > template<class P, class Derived, class Config, class Base> > int get_int(const P& p, const adj_list_impl<Derived, Config, Base>&) > const; > > template<class P> > int operator()(const typename P& p) const; > }; The problem with your approach to implementing this oeprator() is that you've got a circular dependency between ItemHolderKey, which is nasty to say the least. Since you're hacking your way through this, I guess you won't mind relying on just another undocumented feature to solve this in a nicer manner. Reviewing the BGL source, seems like the container is not instantiated with void*s but rather with the actual stored_vertex pointer. stored_vertex must be one of the following types: boost::graph::detail::adj_list_gen<...>::config::seq_stored_vertex; boost::graph::detail::adj_list_gen<...>::config::bidir_seq_stored_vertex ; boost::graph::detail::adj_list_gen<...>::config::rand_stored_vertex; boost::graph::detail::adj_list_gen<...>::config::bidir_rand_stored_verte x; So you just can provide overloads for all of them and get rid of the "static MG m" dependency and the get_int() memfun: template <class Graph, class VertexListS, class OutEdgeListS, class DirectedS, class VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS> int operator()( const boost::graph::detail::adj_list_gen<...>::config::seq_stored_vertex* p) const { return p->m_property.m_value.m_ID; } //etc for the other stored_vertex types See what I mean? You can even do better and provide an adaptor that takes a general key extractor and performs the surgery: template<typename KeyExtractor> struct from_adjacency_list: private KeyExtractor { typedef KeyExtractor::result_type result_type; // we forward to KeyExtractor for the general case template<typename Value> const result_type& operator()(const Value& v) { return KeyExtractor::operator()(v); } // overloads for the various stored_vertex types template <class Graph, class VertexListS, class OutEdgeListS, class DirectedS, class VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS> const result_type& operator()( const boost::graph::detail::adj_list_gen<...>::config::seq_stored_vertex* p) const { return KeyExtractor::operator()(p->m_property.m_value); } // etc }; Now you can use this adaptor in a fairly general way: // No need to define ItemHolderKey. // No dependecies from the particular adjacency_list you're // instantiating. typedef indexed_by < sequenced<>, ordered_unique< from_adjacency_list<member<ItemHolder,int,&ItemHolder::m_ID> > > // and other indices > Index; I haven't actually tried this, but I think it should work and provide with a much more comfortable way to define your embedded MICs. [...] > It is correct that I use undocumented features of BGL to > fuse MIC and BGL. OTOH, it is the way how std::list, > std::vector etc. are used. It would be a surprise if it > is gonna change. One could say that it is > documentation issue, rather then the code. Well, the thing should work but won't be surprised if everthing goes to heck when ugrading to Boost 1.3x. As for this being a documentation issue, I'm afraid too much detail is relied on to think realistically BGL authors will concede to open it to the public. A most viable solution (applicable not only to MIC but also to any other container) would be to have a graph class modeled after adjacency_list with the following aspect: template< typename ElementType, typename EdgeList, typename VertexList, ... > element_adjacency_list; so that it guarantees that the edge container is instantiated with elements of type ElementType*. This is not very hard to achieve if the actual stored_vertex is defined like this: template<typename ElementType> struct element_pointer { ElementType* ptr; }; template<typename ElementType,...> struct stored_vertex: public element_pointer<ElementType> { // rest of the payload (properties, pointer to edge list, etc. }; // from stored_vertex* to ElementType* stored_vertex<...>* sv; ElementType* ptr=sv->ptr; // from ElementType* to stored_vertex // this is portable! ElementType* ptr; element_pointer<ElementType>* eptr= reinterpret_cast<element_pointer<ElementType>*>( reinterpret_cast<char*>(ptr)- offsetof(element_pointer<ElementType>,ptr) ); stored_vertex<...>* sv=static_cast<stored_vertex<...>*>(eptr); Implementing this should be mostly cut&paste from the original adjacency_list, so, who knows, maybe you can convince BGL authors to do it :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[Boost-bugs] [ boost-Bugs-1115124 ] Diff in state of mersenne_twister gen between GCC3.41 & CW9
by SourceForge.net 03 Feb '05

03 Feb '05

Bugs item #1115124, was opened at 2005-02-02 16: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=1115124&group_… Category: random Group: None Status: Open Resolution: None Priority: 5 Submitted By: Morgan (toth21) Assigned to: Jens Maurer (jmaurer) Summary: Diff in state of mersenne_twister gen between GCC3.41 & CW9 Initial Comment: I have found a bug with the mersenne_twister random number generator class, where results when calling for a random number vary between codewarrior 9.0 and gcc 3.4.1 with boost 1.31.0. A simple example is shown below: #include <boost/random/mersenne_twister.hpp> //for mt11213b typedef boost::mt11213b base_generator_type; class foo { public: foo(const base_generator_type gen):m_gen(gen) {} ~foo(void) {} rand_type operator() ( void ) { const float x = m_gen(); return x; } private: base_generator_type m_gen; } int main(void) { base_generator_type gen( (uint32_t) 2000); //seed is not important foo f(gen); cout << "Random result is " << f() << endl; } The resulting numbers will be different between codewarrior 9.0 running on windows (xp or 2000) and gcc 3.4.1 running on Suse linux 7.3.(Hope that is enough info). I tracked the cause of the bug down to class initialization. In the case of CW9.0, the compiler when constructing a foo, will use a mersenne_twister copy ctor when initializing m_gen, while in the case of gcc 3.4.1 it will choose the following in the .hpp file template<class Generator> explicit mersenne_twister(Generator & gen) { seed (gen); } therefore using the provided generator as a seed to the new generator rather than just copying its state, even though no template parameter is provided. Anyways I will leave it up to the more informed to decide which is more desirable/proper; however, this is a fairly nasty bug at the moment as you can not reproduce results between these two platforms when using this random number generator for your random numbers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1115124&group_… ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0