- Boost-users - lists.preview.boost.org

ClearCase and Boost
by Matt Trentini 20 Aug '03

20 Aug '03

Heya Everyone, We use Rationals ClearCase for our source code control here at work and I'm trying to figure out how to best integrate Boost into the ClearCase VOB's. I understand that this probably isn't the ideal forum but I felt certain that someone else out there has a similar configuration! My issue has to do with the different versions of boost. I don't need to maintain a complete source history (don't need every change to every file, just regular releases) but I do want to have multiple versions located at the same place (ie ie want there to be only one boost directory, not boost_1_30, boost_1_30_2 etc) with labels to specify the version. This way our build environment can always look at the one place in the VOB's and we use our config spec to specify which version we're using. Should be simple. ;) Now, I can download a version of boost, extract the files, export them (with clearexport_ffile) then import (clearimport) to the VOB. Then I can label those files. Unfortunately, if any files (or directories) have been deleted I won't know about it - they'll just remain there. I had a quick scan through the attic files and it seems like deleting files is not particularly uncommon. I don't want those old files (which could have been deprecated or buggy or whatever) just lying around waiting for bugs to creep in. So does anyone know of a better way? How are other people doing this? Cheers, Matt PS I've thought of 'hacky' solutions, like telling clearexport_ffile to create a unique branch for every new version of boost and just leaving each new version on the branch...or creating a branch and then running a script over everything, determining if anything needs removing. But, as I said, these are hacky! :)

1 0

Parsing Problem
by jwwillcox2003 19 Aug '03

19 Aug '03

struct usmtf : public grammar<usmtf> { template <typename ScannerT> struct definition { definition(usmtf const& self) { message = mainText; exerciseSet = !eol_p >> str_p("EXER")[do_print("EXER")] >> ch_p('/') >> *(field >> ch_p('/')) >> ch_p('/'); messageIdentifierSet = str_p("MSGID")[do_print("MSGID")] >> ch_p('/') >> *(field >> ch_p('/')) >> ch_p('/'); field = lexeme_d [ +(upper_p - ch_p('/') - eol_p) ]; mainText = exerciseSet >> eol_p >> messageIdentifierSet >> end_p; }; rule<ScannerT> message, mainText, exerciseSet, messageIdentifierSet, field; rule<ScannerT> const& start() const { return message; } }; }; Using this grammar above, it will parse EXER/EE/FF//MSGID// using mainText = exerciseSet >> messageIdentifierSet >> end_p; However, I want it to parse EXER/EE/FF// MSGID// and mainText = exerciseSet >> eol_p >> messageIdentifierSet >> end_p; does not work. Why? How do I parse what I want?

2 1

lexical_cast with unsigned short
by Charles Schwartz 19 Aug '03

19 Aug '03

If possible, please advise. using lexical cast w/unsigned short fails, on MSVC7: #include <boost\lexical_cast.hpp> #include <iostream> int _tmain(int argc, _TCHAR* argv[]) { std::string aStr("2"); unsigned short i = boost::lexical_cast<unsigned short>(aStr); \\ ERROR! std::cout << i << std::endl; return 0; }

3 3

[BGL/iterator_adaptor] retrieving edge iterators from a const graph object?
by Chris Russell 19 Aug '03

19 Aug '03

I'm developing an algorithm based on a DFS of a directed graph that models the BidirectionalGraph concept. In my DFS visitor I have a need to retrieve the pair of in_edge iterators of a specific vertex in my finish_vertex method. Invoking boost::in_edges(Vertex, Graph) and discarding the result compiles fine. However, I can't compile the statement boost::tie(edgeiniterBegin, edgeiniterEnd) = boost::in_edges(Vertex, Graph). I'm struggling to understand why the const-ness of the Graph object results in a "no user defined conversion. from const boost::iterator_adaptor ...." compilation error. I suspect that I have incorrectly specified the type of the in-edge iterators to which I'm attempting to boost::tie the returned iterator pair (my target iterators are declared as boost::graph_traits<mygraph_t>::in_edge_iterator currently) but haven't been able to figure out how else to explain my intent to the compiler. I'll post the specific error message produced by the Windows version of the Intel 7.x compiler and source if necessary - but I'm guessing that I'm missing something pretty obvious here. Any clarification/suggestions would be appreciated. TIA - Chris

2 2

[BGL] named parameter defaults and namespace confusion
by Chris Russell 19 Aug '03

19 Aug '03

In my project, I'm using several different graph objects that are declared in different namespaces. All of these graphs use default internal color maps. Suppose I declare a graph in namespace A. In another namespace, say namespace B, I attempt to invoke a DFS using the named parameter version of the call specifying only the visitor and defaulting the rest of the parameters. Specifically, I do not specify the color map in the named parameter list. What I expected was that the DFS would find, and use the default internal color map of the graph declared in namespace A. However, it appears that it does not and allocates a temporary color map (I assume the compiler searches namespace B, not A). Subsequently when DFS attempts to initialize the color map to white, a fault occurs at runtime (I haven't had time to get into the guts of DFS and figure out exactly why this bombs yet). I've worked around this by using the standard (sans named parameters) version of the DFS call (explicitly passing in a reference to the internal color map). This seeming interaction between the named parameter mechanism and namespaces is pretty subtle - if not for the runtime fault, I would likely have never noticed that the internal property map wasn't being used during the search. Has anyone else seen this? - Chris

2 3

RE: [Boost-Users] shared_ptr - no throw requirement
by Glen Knowles 19 Aug '03

19 Aug '03

From: Victor A. Wagner, Jr. [mailto:vawjr@rudbek.com] >At Monday 2003-08-18 14:43, you wrote: >>What's the rational for the requirement that ~pointee() be no throw? Instead >>of nothrow could it have been specified that shared_ptr functions throw only >>if ~pointee() throws? >> >>This is also something that could go in the docs (assuming I didn't simply >>miss it). > >the ramifications of having any destructor throw are too horrible to >contemplate. >Well, maybe not "too horrible" but several articles have been written on >the ensuing problems. This may be true, and I have read a few articles on the subject, but "too horrible to comtemplate" isn't exactly a rational. A simple statement in the common requirements that it is deemed too error prone would be helpful. Glen [Non-text portions of this message have been removed]

2 1

shared_ptr - no throw requirement
by Glen Knowles 18 Aug '03

18 Aug '03

What's the rational for the requirement that ~pointee() be no throw? Instead of nothrow could it have been specified that shared_ptr functions throw only if ~pointee() throws? This is also something that could go in the docs (assuming I didn't simply miss it). Thanks, Glen [Non-text portions of this message have been removed]

2 1

RE: [Boost-Users] RE: [date_time] library binaries for VC7.1? && Comm on lib placement
by Administrator 18 Aug '03

18 Aug '03

Dan, At least, so far, it only allows for debug/non-debug tagging. Right now, I'm starting to get involved over on the Boost.Build <http://groups.yahoo.com/group/jamboost/> mailing list. We'll see exactly how things pan out, although I doubt there will be any major changes for a little while. Dale > -----Original Message----- > From: Dan Muller [mailto:yg-boost-users@m.gmane.org] > Sent: Monday, August 18, 2003 6:00 AM > To: boost-users(a)yahoogroups.com > Subject: [Boost-Users] RE: [date_time] library binaries for VC7.1? && > Comm on lib placement > > > In article <41B553DE6D81D5119AD90050DA7ACF702E62E6@PDCSERVER>, > administrator(a)sbcltd.com says... > > Dan, > > > > The date_time.lib library is a static lib. The built > date_time.dll actually > > has no exports in it, so for VC purposes is useless. I > would say don't > > worry about it, and just use the static lib. > > Thanks, Dale, this is exactly what I needed to know. I was > starting to > worry that I didn't understand DUMPBIN's output, which would be > worrisome since I've been using it for years. :-) > > > On a side note, has anyone been working on placing built > items into a common > > directory, say <boost_top_dir>/lib? > > > > If not, I have a patch that should help alot. > > Sounds like an excellent idea. I'm assuming that on Windows, > the boost > build would then follow common conventions so that libraries > built with > different characteristics (debug vs. non-debug, multi- vs. single- > threaded, etc) had different names. (I haven't been following boost > build developments lately -- is this a topic of ongoing changes?) > > > > > > -----Original Message----- > > > From: Dan Muller [mailto:yg-boost-users@m.gmane.org] > [text elided] > > > > > > After building boost for VC7.1, I find a .lib file in > > > boost_1_30_0\libs\date_time\build\bin\libboost_date_time.lib\m > > > svc\debug > > > \runtime-link-dynamic and a .dll in > boost_1_30_0\libs\date_time\build > > > \bin\boost_date_time.dll\msvc\debug\runtime-link-dynamic. > > > > > > There are a couple of things that I don't understand about > > > these files. > > > > > > Is the .lib file supposed to be the import library for the > > > .dll? Linking > > > against the .lib file hasn't produced any import references in my > > > applications. Perhaps I'm just not hitting any out-of-line > > > functionality, but it sure seems like the .lib file is a > > > static library > > > rather than an import library. > > > > > > Also, running DUMPBIN /EXPORTS on the .dll file shows no exported > > > symbols related to date_time classes, as far as I can > see. It really > > > looks like it's exporting a bunch of stuff related to the > > > standard C++ > > > library, which makes no sense to me. > > > > > -- > Dan Muller > "So that's what an invisible barrier looks like!" (Time Bandits) > > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark > Printer at Myinks.com. Free s/h on orders $50 or more to the > US & Canada. http://www.c1tracking.com/l.asp?cid=5511 > http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/EbFolB/TM > -------------------------------------------------------------- > -------~-> > > Info: <http://www.boost.org> > Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> > Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > >

2 1

augmented_crc problem with gcc 3.1 and 3.2
by Raoul Gough 18 Aug '03

18 Aug '03

Hi, I've just noticed that my usage of boost::augmented_crc has stopped working since upgrading to gcc 3.x. The problem turns out to be with the workaround extra parameter BOOST_ACRC_DUMMY_PARM_TYPE*. The usage (in crc.hpp) looks like this: template < std::size_t Bits, BOOST_CRC_PARM_TYPE TruncPoly > typename uint_t<Bits>::fast augmented_crc( void const *buffer, std::size_t byte_count, typename uint_t<Bits>::fast initial_remainder BOOST_ACRC_DUMMY_PARM_TYPE ); Which doesn't supply a default value for the fourth parameter (i.e. it really requires all four parameters). Curiously, there is a BOOST_ACRC_DUMMY_INIT defined, which would supply a default value, but it is never used. Is this a bug in crc.hpp? *This happens for gcc 3.1 and 3.2 because config/compiler/gcc.hpp sets BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS to work around a known bug in those versions. -- Raoul Gough "Let there be one measure for wine throughout our kingdom, and one measure for ale, and one measure for corn" - Magna Carta

1 0

bgl compile problem with vc++ 7.1
by Stephan Höfer 18 Aug '03

18 Aug '03

Hello, I've checked out the newest version of boost from the cvs directory on boost-consulting.com. I've tried to recompile my bgl program to be able to use the latest changes of the bgl code. The compilation progress finished with the following error code: ..\..\..\boost\boost\graph\properties.hpp(169) : error C2248: 'boost::detail::subgraph_property_generator::bind_<SubGraph,Property,Tag>::type' : cannot access private typedef declared in class 'boost::detail::subgraph_property_generator::bind_<SubGraph,Property,Tag>' with [ SubGraph=boost::subgraph<boost::adjacency_list<boost::vecS,boost::vecS,boost::undirectedS,VertexProperty,EdgeProperty>>, Property=boost::detail::vertex_property_map<boost::subgraph<boost::adjacency_list<boost::vecS,boost::vecS,boost::undirectedS,VertexProperty,EdgeProperty>>,vertex_point_t>::Property, Tag=vertex_point_t ] and [ SubGraph=boost::subgraph<boost::adjacency_list<boost::vecS,boost::vecS,boost::undirectedS,VertexProperty,EdgeProperty>>, Property=boost::detail::vertex_property_map<boost::subgraph<boost::adjacency_list<boost::vecS,boost::vecS,boost::undirectedS,VertexProperty,EdgeProperty>>,vertex_point_t>::Property, Tag=vertex_point_t ] Cheers, Stephan [Non-text portions of this message have been removed]

2 1