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

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

[Q] Boost-Build V2
by Chris Drexler 18 Aug '03

18 Aug '03

Dear Listmembers, since a few weeks I'm using boost within a development system which should be changed towards operating system independence. As boost-buil V2 has a lot of nice features I wanted to base the build process on it. Unfortunatly it's very confusing to get all the information I need and sometimes it is not clear to which boost-build version (v1 or v2) some documentation belongs to. I hope this list is the right place to ask some questions about this. I'm going to describe the my current setup first (which is a little bit longish in order to cover all important points, hopefully) and afterwards I'll explain the problems. The scenario: We have some self-made class libraries which depend on downloaded packages (one is boost). So I thought of using the (usage-)dependency features of boost-build v2 for automatically using the right include paths and the according libraries. (I'm using milestone 6 of boost-build) root | + pkgs + boost_1_30_0 | | | + log4cpp_0.3.4b + include | + lib | + mylib + include | + src | + myapps + testapp + src The idea was to separate the information of which package versions to use and where libraries and include files reside. For this I put a Jamfile into 'pkgs' which consist of the following entries (OS independence not included right now) ------------------------------------------------------------------- project pkgs ; BOOST = boost_1_30_0 ; LOG4CPP = log4cpp-0.3.4b ; # system libraries lib winsock : : <name>Ws2_32.lib ; lib advapi : : <name>Advapi32.lib ; alias all : log4cpp boost ; alias boost : : <include>$(BOOST) ; lib log4cpp : : <file>$(LOG4CPP)/msvc6/log4cpp/Release/log4cpp.lib <variant>release : : <library>winsock <library>advapi ; lib log4cpp : : <file>$(LOG4CPP)/msvc6/log4cpp/Debug/log4cpp.lib <variant>debug : : <library>winsock <library>advapi ; ------------------------------------------------------------------- and the Jamfile in 'root' (where project-root.jam and boost-build.jam resides) contains ------------------------------------------------------------------- project MyProject : default-build debug <link>static ; use-project /pkgs : ./pkgs ; use-project /MyLib: ./mylib ; ------------------------------------------------------------------- The Jamfile in 'mylib' uses several of the libraries defined in 'pkgs' ------------------------------------------------------------------- project MyLib : usage-requirements <include>./include : requirements <include>./include : source-location ./src ; LIBSRC = [ .. whatever ..] ; lib MyLib : $(LIBSRC) : : : <library>/pkgs//log4cpp ; lib MyLib2 : $(LIBSRC) : : : <library>/pkgs//all ; ------------------------------------------------------------------- and the application 'testapp' depends on 'mylib' ------------------------------------------------------------------- project testapp : requirements <library>/MyLib//MyLib : source-location ./src ; exe test : testapp.cpp ; exe test2 : testapp.cpp : : <library>/MyLib//MyLib2 ; ------------------------------------------------------------------- Problems/Questions ================== - I had to put a (empty) 'project-root.jam' file into 'pkgs'. Otherwise I get the error message: error: default build can be specified only in first alternative main target is ../../../pkgs/log4cpp Any ideas why this happens? - the library dependcies for 'log4cpp' are correct and the appropriate library is linked BUT the include depencies are not used (neither for boost nor for log4cpp). I had to add the paths once more into the Jamfile in 'root' to make them available. After the changes the Jamfile looks like this ------------------------------------------------------------------- BOOST = pkgs/boost_1_30_0 ; LOG4CPP = pkgs/log4cpp-0.3.4b ; project MyProject : default-build debug <link>static : requirements <include>$(BOOST) <include>$(LOG4CPP)/include ; use-project /pkgs : ./pkgs ; use-project /MyLib: ./mylib ; ------------------------------------------------------------------- This is not what I wanted because now the paths to the package directies appear twice, once in root/Jamfile and once in root/pkgs/Jamfile. Thanks you very much ! Best Regards, Chris Drexler

2 3