- Boost-users - lists.boost.org

[spirit] error removal
by Aaron Griffin 14 Oct '05

14 Oct '05

Hi all, This is a contrived example, but the solution should be the same. Assuming I have two rules, like so: section = identifier >> ch_p('{') >> *setting >> ch_p('}'); setting = identifier >> ch_p('=') >> value; // identifier and value are simple, but left off for brevity This should parse something like: somesettings { a = 12 b = "hello whirled" } Now, what I am looking to do is, if the parser fails parsing a value inside a "section", the parsing itself does not fail, but that section itself does. So if I also had: moresettings { this_is_valid = 12345 bigfaterror = 12"hi there"4.3"fewewfewfw" } Then the "somesettings" section would exist in the final AST, but "moresettings" would not. The error handling docs are a bit unclear to me, bit if I were to make a generic functor_parser which kept an error flag, how would I conditionally remove the section based on that value, seeing as it will already be mid-parse (I don't think something like if_p will work). Thanks in advance for any advice. On a side note, if I have a rule similar to (keyword >> identifier), the skip_parser will translate "somekeyword a" into "somekeyworda" and will parse it fine. However, what is to stop someone from removing the whitespace in the original code. With a quick glance, it appears the example c grammar from the spirit site will parse "voidfoo()" just fine due to this. Is there anyway I can tell the skip grammar to force a seperation? Thanks again, Aaron Griffin

3 4

Re: [Boost-users] Compilation errors with Intel Compiler 9.0 for Linux
by Olivier Delalleau 14 Oct '05

14 Oct '05

On 14 Oct 2005, boost-users-request(a)lists.boost.org wrote: > > There are many errors like this one. Again, if I remove the include > > command -I/opt/intel/compiler90/include/c++ > > it works fine. Also if I use the intel 8.0 includes it works fine (but > > not intel 8.1). > > > > Any help fixing these errors (actually, mainly the regex one, as this > > is the library I really need) will be much appreciated :) > > I believe this is fixed for 1.33.1, can you get hold of that from cvs (it's > on the RC_1_33_0 branch), or would you like a zip to test? I'd like to be > sure this really is fixed for the next release as you're not the only one > with the problem. Thank you :) I got the RC_1_33_0 release from the cvs, and regex is now compiling perfectly with the Intel 9.0 includes. Note that the iostreams library is still broken, but I don't really care that much since I don't plan to use it in the near future. Thanks again for the help! -- Olivier

1 0

Compilation errors with Intel Compiler 9.0 for Linux
by Olivier Delalleau 14 Oct '05

14 Oct '05

I'm getting some annoying errors when compiling some of the libraries of Boost 1.33.0 with Intel Compiler 9.0 (icpc (ICC) 9.0 20050811) under Linux. Here is what happens when I try to compile (again after a first try which failed to update all targets): ----------------------------------------------------------------------------------- ../boost-jam-3.1.11-1-linuxx86/bjam -sTOOLS=intel-linux --prefix=/RQusagers/delallea/local --builddir=/RQexec/delallea/boost_1330_90 -sPYTHON_VERSION=2.4 --with-python-root=/usr/network.ALTIX/python-2.4.1 -sINTEL_VERSION=90 -sINTEL_PATH=/opt/intel/compiler90 install Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (and if you don't know what ICU is then you probably don't need it). ...found 14461 targets... ...updating 104 targets... intel-linux-C++-action /RQexec/delallea/boost_1330_90/bin/boost/libs/iostreams/build/libboost_iostreams.a/intel-linux/debug/file_descriptor.o /RQMNT/exec1/lisa/delallea/boost_src/boost_1_33_0/boost/iostreams/positioning.hpp(45): error: no suitable conversion function from "mbstate_t" to "std::streampos={std::streamoff={long}}" exists return std::streampos(std::mbstate_t(), off); ^ /RQMNT/exec1/lisa/delallea/boost_src/boost_1_33_0/boost/iostreams/positioning.hpp(45): error: expected a ")" return std::streampos(std::mbstate_t(), off); ^ /RQMNT/exec1/lisa/delallea/boost_src/boost_1_33_0/boost/iostreams/positioning.hpp(51): error: no suitable conversion function from "fpos_t" to "boost::iostreams::stream_offset={intmax_t={long}}" exists return pos; ^ /RQMNT/exec1/lisa/delallea/boost_src/boost_1_33_0/boost/iostreams/positioning.hpp(64): error: expression must have class type return fpos_t_to_offset(pos.seekpos()) + ^ /RQMNT/exec1/lisa/delallea/boost_src/boost_1_33_0/boost/iostreams/positioning.hpp(66): error: expression must have class type stream_offset(std::streamoff(pos.seekpos())); ^ compilation aborted for /RQMNT/exec1/lisa/delallea/boost_src/boost_1_33_0/libs/iostreams/build/../src/file_descriptor.cpp (code 2) . /opt/intel/compiler90/bin/iccvars.sh icpc -c -w1 -g -O0 -I"/RQexec/delallea/boost_1330_90/bin/boost/libs/iostreams/build" -I"/RQMNT/exec1/lisa/delallea/boost_src/boost_1_33_0" -I"/RQMNT/exec1/lisa/delallea/boost_src/boost_1_33_0" -o "/RQexec/delallea/boost_1330_90/bin/boost/libs/iostreams/build/libboost_iostreams.a/intel-linux/debug/file_descriptor.o" "/RQMNT/exec1/lisa/delallea/boost_src/boost_1_33_0/libs/iostreams/build/../src/file_descriptor.cpp" ...failed intel-linux-C++-action /RQexec/delallea/boost_1330_90/bin/boost/libs/iostreams/build/libboost_iostreams.a/intel-linux/debug/file_descriptor.o... ----------------------------------------------------------------------------------- Then other similar errors in iostreams... Now, the important detail: I have in my icpc.cfg the following line: -I/opt/intel/compiler90/include/c++ which forces the Intel compiler to (preferably) use its own includes. Otherwise it uses the g++ standard includes and (at least for the file above) compilation works fine. But I would really prefer to be able to compile Boost using only the Intel code (especially since I need this line in my icpc.cfg for some other non-Boost stuff to compile). Then when compiling the regex library I have other errors. Here is an example of what happens with a specific compile line (here I cleaned my icpc.cfg file): ----------------------------------------------------------------------------------- icpc -I/opt/intel/compiler90/include/c++ -c -w1 -DNDEBUG -DNDEBUG -O3 -openmp -I"/RQexec/delallea/boost_1330_90/bin/boost/libs/regex/build" -I"/RQMNT/exec1/lisa/delallea/boost_src/boost_1_33_0" -o "/RQexec/delallea/boost_1330_90/bin/boost/libs/regex/build/libboost_regex.a/intel-linux/release/threading-multi/instances.o" "/RQMNT/exec1/lisa/delallea/boost_src/boost_1_33_0/libs/regex/build/../src/instances.cpp" /RQMNT/exec1/lisa/delallea/boost_src/boost_1_33_0/boost/regex/v4/instances.hpp(84): error #803: function "boost::match_results<BidiIterator, Allocator>::match_results(const boost::match_results<BidiIterator, Allocator> &) [with BidiIterator=const char *, Allocator=std::vector<boost::sub_match<const char *>, std::allocator<boost::sub_match<const char *>>>::allocator_type]" explicitly instantiated more than once template class BOOST_REGEX_DECL match_results< std::basic_string<BOOST_REGEX_CHAR_T>::const_iterator >; ----------------------------------------------------------------------------------- There are many errors like this one. Again, if I remove the include command -I/opt/intel/compiler90/include/c++ it works fine. Also if I use the intel 8.0 includes it works fine (but not intel 8.1). Any help fixing these errors (actually, mainly the regex one, as this is the library I really need) will be much appreciated :) -- Olivier

2 1

[serialization]save object to a previous version
by Li Lirong 14 Oct '05

14 Oct '05

Hi, As I understand, the class versioning system permits a program to load archives created by previous versions of the program. However, is it possible to explicitly save some of objects to a previous version so that previous versions of the program can read the saved archive? Regards, Lirong

2 1

Re: [Boost-users] Report from Mont Tremblant C++ Committee meeting
by Jeff Garland 14 Oct '05

14 Oct '05

On Thu, 13 Oct 2005 12:52:30 -0400, Daryle Walker wrote > On 10/12/05 5:38 AM, "John Maddock" <john(a)johnmaddock.co.uk> wrote: > > [SNIP] > > And for those who think that in-place modification is the way to go: you do > > realise that it's often *slower* than building a new string don't you? > > And what if the string uses more than half of the available space? > (I'm not advocating in-place modification, but just mentioning that > "return a copy" has its flaws too.) That's why the library supports both interfaces -- essentially letting the user decide. Jeff

1 0

Is there a boost way to avoid this macro usage?
by Rush Manbert 13 Oct '05

13 Oct '05

Hi all, I posted this question to comp.lang.c++.moderated and got a single reply that basically said "it looks like you need to use macros", but I thought I would ask the same question here, just in case you MPL folks have some tricks up your boost library sleeves. Basically, I need to make an enum and a static array of structures from one data set and I only know one way to do it, and it involves an amount of "trickiness" that some find disturbing. The original post: In the code shown below, the CODE_TABLE macro is used to insert a sequence of CODE(codeValue) macros. By changing the definition of CODE(codeValue) right before each usage of CODE_TABLE, I can create an enumeration of codeValues, then use the same CODE_TABLE definition to create a static lookup table that can be used to find information about a codeValue, given its numeric value. In this case, I am finding the name of the enumerated value. In the real application, there are a number of other fields available. (As you can probably tell, I have written a lot of C code in my time.) IMHO, the benefit of this technique is that you only maintain CODE_TABLE. All of the required code bits are generated from it. The downside is that Macros are Evil, the macro-that-is-a-list-of-macros is confusing, and you need to carefully redefine CODE(codeValue) in the proper locations. Additionally, the real application will have multiple classes that each define their own CODE_TABLE contents, so making it all work correctly is a little tricky. My question is this: Is there any method available in C++ that can let me do away with the macros while preserving the nice quality that only one data structure needs to be maintained? Something sophisticated and tricky with templates perhaps? I expect that the fact that I stringize the enum name when creating the lookup table makes a macro the only choice. But, since that is only one component in each lookup table entry in the real code, I might be willing to give it up in order to lose the macros. Here is the code example. Contents of foo.h: ----------------- #define CODE_TABLE \ CODE(FooCodeA) \ CODE(FooCodeB) #define CODE(codeValue) codeValue, class foo { public: typedef enum { // Here comes the first use of CODE_TABLE CODE_TABLE } CodesT; foo (CodesT theCode) : m_code (theCode) {} const char *lookup (void) const; const int getCode (void) const {return m_code;} private: CodesT m_code; typedef struct { CodesT theCode; const char *pTheCodeAsString; } CodeLookupTableT; static CodeLookupTableT m_lookupTable[]; }; Contents of foo.cpp: ------------------- #include "foo.h" // Now we redefine CODE so that we can initialize the // static lookup table #undef CODE #define CODE(codeValue) {codeValue, #codeValue}, foo::CodeTableLookupT foo::m_lookupTable[] = { CODE_TABLE }; // The lookup method that finds the string description // from the numeric code const char *foo::lookup (void) const { for (int i = 0; i < (sizeof m_lookupTable)/(sizeof m_lookupTable[0]); ++i) { if (m_lookupTable[i].theCode == m_code) return m_lookupTable[i].pTheCodeAsString; } return "Unknown code value"; } contents of main.cpp: ------------------- #include <iostream> #include "foo.h" using namespace std; int main (int argc, char * const argv[]) { foo myFoo (foo::FooCodeB); cout << "myFoo with code number....: " << myFoo.getCode() << endl << " looks up the code name as: " << myFoo.lookup() << endl; return 0; } Output from running the program: ------------------------------- myFoo with code number....: 1 looks up the code name as: FooCodeB Thanks, Rush

2 5

Hash Map
by Piyush Kapadia 13 Oct '05

13 Oct '05

Is there any faster version of std::map ? I heard there is a faster hashmap implementation, does boost have anything in this regard ?

4 3

[shared_ptr] Two basic questions
by Matthias Kaeppler 13 Oct '05

13 Oct '05

Hello, I have two questions regarding the proper use of boost::shared_ptr; both actually arose after reading http://www.boost.org/libs/smart_ptr/example/shared_ptr_example.cpp 1. In order for some class to work with std::set, you have to supply an operator with "less than" semantics. Why are you instead declaring a "greater than" operator? 2. In your examples, sometimes you're passing a shared_ptr by value, and sometimes by reference-to-const. Which is the better practice? Usually, common pointers are passed by value, but since in shared_ptr a reference counting mechanism keeps track of the copies, maybe it's better to pass it by reference whenever possible? Thanks in advance, Matthias Kaeppler -- Matthias Kaeppler | Tel: +49 631 3405805 Gerhart-Hauptmann-Str. 16a | Mob: +49 176 20108693 D-67663 Kaiserslautern | E-Mail: matthias at finitestate dot org

3 2

[operators] boost::operators-like functionality for methods
by Geoffrey Irving 13 Oct '05

13 Oct '05

Hello, Is it possible to get boost::operator like functionality for general methods? In other words, I'd like to be able to do the following: template<...> struct complete : public ... { void f(){a();} void g(); }; struct C : public complete<...> { void a(); void b(){g();} }; The resulting class C would have methods a,b,g,f. Here C::b refers to the complete::g and complete::f refers to C::a, so the dependencies are circular. It seems like the boost::operators setup can handle this kind of circular dependency, but I'm not how to do it for methods. Thanks, Geoffrey

2 1

MPL map / multi index dependency bug
by Zach Laine 13 Oct '05

13 Oct '05

The following code does not compile using gcc 3.4.3. I tried it with the same results using 1.32 and 1.33. Reversing the order of the #includes fixes the problem. Is this a known order dependency? If so, I couldn't find it documented anywhere. #include <boost/multi_index_container.hpp> #include <boost/mpl/map.hpp> int main() { return 0; } Compiler output: In file included from /usr/local/include/boost-1_33/boost/mpl/map/aux_/begin_end_impl.hpp:20, from /usr/local/include/boost-1_33/boost/mpl/map/map0.hpp:30, from /usr/local/include/boost-1_33/boost/mpl/map/map10.hpp:19, from /usr/local/include/boost-1_33/boost/mpl/map/map20.hpp:19, from /usr/local/include/boost-1_33/boost/mpl/map.hpp:36, from test.cpp:2: /usr/local/include/boost-1_33/boost/mpl/map/aux_/iterator.hpp:41: error: wrong number of template arguments (2, should be 1) /usr/local/include/boost-1_33/boost/mpl/void.hpp:37: error: provided for `template<class T> struct boost::mpl::is_void_' /usr/local/include/boost-1_33/boost/mpl/map/aux_/iterator.hpp:41: error: `type' is not a member of `<declaration error>' /usr/local/include/boost-1_33/boost/mpl/map/aux_/iterator.hpp:41: error: `type' is not a member of `<declaration error>' /usr/local/include/boost-1_33/boost/mpl/map/aux_/iterator.hpp:42: error: template argument 1 is invalid /usr/local/include/boost-1_33/boost/mpl/map/aux_/iterator.hpp:44: error: expected `{' before '>' token /usr/local/include/boost-1_33/boost/mpl/map/aux_/iterator.hpp:44: error: expected unqualified-id before '>' token /usr/local/include/boost-1_33/boost/mpl/map/aux_/iterator.hpp:44: error: expected `;' before '>' token /usr/local/include/boost-1_33/boost/mpl/map/aux_/iterator.hpp:62: error: expected nested-name-specifier before "item_by_order" /usr/local/include/boost-1_33/boost/mpl/map/aux_/iterator.hpp:62: error: ISO C++ forbids declaration of `item_by_order' with no type /usr/local/include/boost-1_33/boost/mpl/map/aux_/iterator.hpp:62: error: expected `;' before '<' token

2 2