- Boost-users - lists.boost.org

lambda&MSVC7.0 problem
by GIE 20 Aug '03

20 Aug '03

Hello! While trying to compile empty test prog (only #include "boost/lambda/lambda.hpp" and main) i've got following errors: ...\lambda\detail\arity_code.hpp(66) : error C2065: 'T' : undeclared identifier ...\boost\lambda\detail\arity_code.hpp(66) : error C2687: cannot define a nested UDT of a template class out of line ...\boost\lambda\detail\arity_code.hpp(66) : fatal error C1903: unable to recover from previous error(s); stopping compilation Can this be helped? (boots version 1.30.0) -- With best regards, GIE.

2 1

[bgl] question to induced subgraphs
by Stephan Höfer 20 Aug '03

20 Aug '03

Hello, I use an induced subgraph of a graph with additional user defined properties like coordinates and so on. Do I have access to this properties via the get and put functions using the indices of the subgraph or do I have to access these properties via the parent (if it is the root) resp. root of the subgraph? I tried both without the demanded success. Using the second way the results were a little bit more accurate than using the first way, but they were wrong in either case. I created the subgraph as Graph& tSubgraph = g.create_subgraph; where g is a before initialized graph. Maybe it works copying the properties to the subgraph, but that wouldn't be efficient in my opinion. Thanks in advance for your answers, Stephan

1 0

PC-Lint reports errors for VC6-specific implementation in is_same.hpp
by stefan_felkel2000 20 Aug '03

20 Aug '03

Hi all, Since I have included boost\dynamic_bitset.hpp in my project, PC-Lint reports many thousands of redefinitions of symbol 'is_same_part_1<<1>>::part_2<<1>> for the following code in type_traits\is_same.hpp. #ifdef BOOST_MSVC // the following VC6 specific implementation is *NOT* legal // C++, but has the advantage that it works for incomplete // types. template< typename T1 > struct is_same_part_1 { template<typename T2> struct part_2 { enum { value = false }; }; template<> struct part_2<T1> { enum { value = true }; }; }; If I replace #ifdef BOOST_MSVC with #if (defined BOOST_MSVC) && (BOOST_MSVC < 1300) The code compiles with Visual Studio .NET 2003 and PC-Lint doesn't report any error. Stefan Felkel

2 2

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 19 Aug '03

19 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