- Boost-users - lists.boost.org

Re: [Boost-users] [WAVE] bug: generic lexing error
by Hartmut Kaiser 28 Apr '06

28 Apr '06

Andreas Sæbjørnsen wrote: > I do not know why you were not able to reproduce the error as > I reproduced it on two different machines using two different > boost installations. Using the attached source-file you > should be able to reproduce the error. Both icc and g++ > compiles this file without error. > > If the behaviour in section 2.2.2 of the standard lead to > Wave being unable to preprocess some C++ source-files that > cpp and the EDG preprocessor will accept, what do you think > about creating a feature for optionally turning this behaviour off? I've induced a null byte into your sample and gcc complains about it as well. So my guess is, that something else goes wrong. But since I still have no luck in reproducing your original problem here on my Windows machine I'll have to try it on a linux box, but will have the possibility for that next week only. Regards Hartmut > > Regards > Andreas > > > > > On 4/21/06, Hartmut Kaiser < hartmut.kaiser(a)gmail.com > <mailto:hartmut.kaiser@gmail.com> > wrote: > > > Andreas Sæbjørnsen wrote: > > > Using the wave driver reference implementation on the > code found at: > > http://folk.uio.no/andsebjo/bugInducingCode.C > <http://folk.uio.no/andsebjo/bugInducingCode.C> > > I get the following error: > > bugInducingCode.C(10157): error: generic lexing error: > > '\000' in input stream This code compiles with g++ and if any > > line is cut within the file it does not fail with Wave. > > The code contains only C++ syntax so it is basically a test > > of the cpplexer. > > Is this a know problem? > > > > This problem occurs in both my two months old CVS version of > > boost and the 1.3.1 build. > > Hmmm. Sorry I'm not able to reproduce this problem > here. But the error you > get says your input stream contains a binary 0 (zero) > byte. And yes it's a > lexer diagnostic. > > The standard says ( 2.2.2 [lex.charset]): > > <quote> > If the hexadecimal value for a universal character name > is less than 0x20 or > in the range 0x7F0x9F (inclusive), or if the universal > character name > designates a character in the basic source character > set, then the program > is illformed. > </quote> > > So I'm pretty sure Wave is right to diagnose this. > > Could you send me the file as an attachment, please, > just to make sure I > really get it as you have it on your disk. > > Regards Hartmut > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > <mailto:Boost-users@lists.boost.org> > http://lists.boost.org/mailman/listinfo.cgi/boost-users > <http://lists.boost.org/mailman/listinfo.cgi/boost-users> > > > >

2 5

boost and python
by Jeff Mearing 27 Apr '06

27 Apr '06

Hi, I am currently running Linux (Fedora), with python2.4 . I am keen to use boost to enable me to use python and C++ code together. I have built the Boost package using Bjam. All seemed to go good there following the build instruction for the hello world example. I then built the hello world example fine using the : bjam -sTOOLS=gcc HelloTest now if i run up python on the command line, and type: >> import hello into the python shell it fails to find the hello module, i then tried moving the hello.so file into : /usr/lib/python2.4/lib-dynload the hello module is now found, however the 'libboost_python.so' cant be found, i guess because hello depends on this and it cannot be found. Which environment variable do i have to set to fix this link problem? Current environment variable settings: PYTHON_PATH=usr/lib PYTHON_ROOT=usr/lib PYTHON_VERSION=2.4 cheers Dave i hope you can help! jeff

4 3

auto_ptr, string serialization
by Olivier Destrebecq 27 Apr '06

27 Apr '06

I have a class that inherit from another, both implement serialization the derived class has this code: #ifndef _GENREMETADATA_H_ #define _GENREMETADATA_H_ #include "fetchableMetadataObject.h" #include <boost/serialization/split_member.hpp> #include <boost/serialization/string.hpp> class GenreMetadata : public FetchableMetadataObject { public: ..... private: std::string m_abbreviation; std::string m_displayName; std::string m_name; std::auto_ptr<std::vector<GenreMetadata> > m_childGenresMetadata; std::auto_ptr<std::vector<GenreMetadata> > m_parentGenresMetadata; std::auto_ptr<std::string> m_description; std::auto_ptr<GenreMetadata> m_primaryParentGenreMetadata; template<class Archive> void serialize(Archive & inArchive, const unsigned int version) { //serialize the base class // inArchive & BOOST_SERIALIZATION_BASE_OBJECT_NVP (FetchableMetadataObject); //then our own properties // inArchive & BOOST_SERIALIZATION_NVP(m_abbreviation); inArchive & BOOST_SERIALIZATION_NVP(m_displayName); inArchive & BOOST_SERIALIZATION_NVP(m_name); inArchive & BOOST_SERIALIZATION_NVP(m_childGenresMetadata); inArchive & BOOST_SERIALIZATION_NVP(m_parentGenresMetadata); inArchive & BOOST_SERIALIZATION_NVP(m_description); inArchive & BOOST_SERIALIZATION_NVP (m_primaryParentGenreMetadata); } }; #endif //_GENREMETADATA_H_ i included a version of auto_ptr serialization: #include <list> #include <memory> #include <fstream> #include <boost/config.hpp> // std::autoptr inteface wrong in dinkumware #include <boost/detail/workaround.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/detail/workaround.hpp> #include <boost/serialization/split_free.hpp> namespace boost { namespace serialization { ///////////////////////////////////////////////////////////// // implement serialization for auto_ptr<T> // note: this must be added to the boost namespace in order to // be called by the library template<class Archive, class T> inline void save( Archive & ar, const std::auto_ptr<T> &t, const unsigned int file_version ){ // only the raw pointer has to be saved // the ref count is rebuilt automatically on load T *objectPtr = t.get(); ar << BOOST_SERIALIZATION_NVP(objectPtr); } template<class Archive, class T> inline void load( Archive & ar, std::auto_ptr<T> &t, const unsigned int file_version ){ T *objectPtr; ar >> BOOST_SERIALIZATION_NVP(objectPtr); // note that the reset automagically maintains the reference count #if BOOST_WORKAROUND(BOOST_DINKUMWARE_STDLIB, == 1) t.release(); t = std::auto_ptr<T>(objectPtr); #else t.reset(objectPtr); #endif } // split non-intrusive serialization function member into separate // non intrusive save/load member functions template<class Archive, class T> inline void serialize( Archive & ar, std::auto_ptr<T> &t, const unsigned int file_version ){ split_free(ar, t, file_version); } } // namespace serialization } // namespace boost When i compile this code i get the following error: ../../common_rn/import/boost/debug/include/boost-1_33_1/boost/ serialization/access.hpp:109: error: 'struct std::basic_string<char, std::char_traits<char>, std::allocator<char> >' has no member named 'serialize' I looked at the serialization code for string and it treats it as a primitive type. Could my problem come from there. Notice how it complains about the string contained in the auto_ptr, but not the other strings. Also it does not complain about the array contain in the auto_ptr. Also if i split the serialization of my object an manually try to archive the string object, it complain about the serialization if i pass in a pointer to the string, but not if i pass the object itself any help appreciated Best, Olivier Destrebecq olivierd(a)real.com

1 0

Repost: [Serialization] Build Fails for --layout=System, 1.33.1, vc-8_0 toolset, Win XP
by Rush Manbert 27 Apr '06

27 Apr '06

Hi, This is a repost and is directed to Robert Ramey, since the serialization library is his baby and I assume he wrote the build configuration code for it. I got no reply the first time, and I really need to be able to build this way. I am having problems building Boost 1.33.1 under Windows XP for the vc-8_0 toolset. My problems seem to come from a bug in the build of the serialization library. The attached zip file contains information from 2 builds. One of them succeeds and the other fails. The difference between them is that the failed build includes "--layout=system" on the bjam command line, while the successful build does not. In both cases, the build is run by a script that makes sure the build location and the installation location are cleaned up before the build starts. In the zip file are the following files: * failedBoostBuild.log contains all of the output generated by bjam for the failed build. * failedConsoleTranscript.txt is the console output from the build script. It shows the bjam command line for the failed build. * failedInstalledLibList.txt is a "dir" listing of the library installation directory, after the failed build completed. * goodBoostBuild.log, goodConsoleTranscript.txt, and goodInstalledLibList.txt are the equivalents to the above for the successful build. I believe that there is an error shown in failedBoostBuild.log at line 3000. The line says: "LINK : fatal error LNK1104: cannot open file 'boost_serialization-vc80-mt-gd-1_33_1.lib'" and I believe that the error is that the library file name includes the toolset name and the Boost version number. Since I specified --layout=system, neither of these are included in the generated library names. There is a similar error at line 3058. If you compare the failedInstalledLibList.txt and goodInstalledLibList.txt, you can see that none of the boost_wserialization libraries are present in the failed case. I am guessing that they represent the four failed targets reported by bjam at the end of the build. I want to use the --layout=system naming conventions and do internal releases of the Boost libraries to our development environment. I have already done this successfully under Mac OSX, and I expected it to work the same way under Windows. If my conclusion that there is a build bug is correct, is there some workaround possible to make the build succeed? (I looked at the serialization jamfile and came away unenlightened. :-) Is there some other explanation? Thanks, Rush

2 2

[iostreams] Assertion in filtering_stream dtor when using a code_ converter
by EMalenfant＠interstarinc.com 27 Apr '06

27 Apr '06

Hi, The following causes an assertion failure (in iostreams::detail::optional::operator*()) when destroying the filtering_stream: #include <boost/iostreams/filtering_stream.hpp> #include <boost/iostreams/code_converter.hpp> #include <boost/iostreams/device/file_descriptor.hpp> #include <windows.h> namespace io = boost::iostreams; int main (void) { io::wfiltering_stream<io::output> out; HANDLE h = CreateFileW(L"test.txt", GENERIC_WRITE | GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_ALWAYS, 0, NULL ); out.push( io::code_converter<io::file_descriptor_sink>( io::file_descriptor_sink(h, true) ) ); out << L"Hello world!"; return 0; } If I add "out.pop()" before returning, there is no assertion. Looking deeper, it turns out that iostreams::chain's dtor calls close(); and reset();, and both end up calling close() on the code_converter. And code_converter is not "multi-closable". IOW, I get the same assertion failure with: HANDLE h = CreateFile(/*...*/); io::code_converter<io::file_descriptor_sink> cvt(io::file_descriptor_sink(h, true)); cvt.close(); cvt.close(); //<< Asserts here To fix this, I made it possible to call code_converter::close() multiple times by simply adding: if (!(this->is_open())){ return; } right at the beginning of code_converter::close(). Am I right in assuming that it should be possible to close() a Device or Filter multiple times ? Anyone has comments on this proposed fix? ----------------------------- Éric Quidquid latine dictum sit, altum viditur.

1 0

Multi Array problem
by Robert Ramey 27 Apr '06

27 Apr '06

I have a problem what is demonstrated in the attached file. Basically I have the following create multi_array - a1 create a view on the multiarray which has the same number of dimensions a1_view a1 == a1_view fails to compile. The attached example illustrates this. In the example I verify that both a1 and a1_view fullfill the requirements for Multi Array. The documentation states that in order for a type to be a model of the Multi Array concept. The operations a == b must be valid. Actually the documentation could be considered ambiguous on this point. But that is was I get from a plain reading of the document and from a common sense interpretation. If two types meeting the requirements of the Multi Array concept have the same number of dimensions, I expect to be able to compare them as this is natural operation to perform and implement. Robert Ramey begin 666 test_misc.cpp M(VEN8VQU9&4@(F)O;W-T+V-O;F-E<'1?8VAE8VLN:'!P(@T*(VEN8VQU9&4@ M(F)O;W-T+VUU;'1I7V%R<F%Y+V-O;F-E<'1?8VAE8VMS+FAP<"(-"B-I;F-L M=61E(")B;V]S="]M=6QT:5]A<G)A>2YH<' B#0H-"B-P<F%G;6$@=V%R;FEN M9RAD:7-A8FQE(#H@-#DY-BD-"@T*:6YT( T*;6%I;B H*2![#0H)='EP961E M9B!B;V]S=#HZ;75L=&E?87)R87D\9&]U8FQE+" S/B!A<G)A>5]T>7!E.PT* M"6%R<F%Y7W1Y<&4@83$H8F]O<W0Z.F5X=&5N='-;,UU;-%U;,ETI.PT*"71Y M<&5D968@87)R87E?='EP93HZ:6YD97A?<F%N9V4@<F%N9V4[#0H)87)R87E? M='EP93HZ87)R87E?=FEE=SPS/CHZ='EP92!A,5]V:65W(#T-"@D)83%;(&)O M;W-T.CII;F1I8V5S6W)A;F=E*# L,BE=6W)A;F=E*#$L,RE=6W)A;F=E*# L M-"PR*5T@73L-"@T*"6)O;W-T.CIF=6YC=&EO;E]R97%U:7)E<SP-"@D)8F]O M<W0Z.F1E=&%I;#HZ;75L=&E?87)R87DZ.DUU=&%B;&5-=6QT:4%R<F%Y0V]N M8V5P=#QA<G)A>5]T>7!E+#,^( T*"3XH*3L-"@EB;V]S=#HZ9G5N8W1I;VY? M<F5Q=6ER97,\#0H)"6)O;W-T.CID971A:6PZ.FUU;'1I7V%R<F%Y.CI-=71A M8FQE375L=&E!<G)A>4-O;F-E<'0\87)R87E?='EP93HZ87)R87E?=FEE=SPS M/CHZ='EP92PS/B -"@D^*"D[#0H-"@ER971U<FX@83$@/3T@83%?=FEE=SL- ""GT` ` end

3 3

shared_ptr and RTTI?
by Foster Brereton 27 Apr '06

27 Apr '06

Hi all, I have this request from a colleague. Can anyone help me shed some light on his issue?: > I did not use the boost::shared_ptr in quite some time and I was > surprised to find out that, more recently, the shared_ptr _requires_ > RTTI to be enabled. I did some reading on the websites and groups and > while I admit that the new version is more flexible, powerful, etc, I > would have thought that they also left a switch in for the old behavior > which did not require RTTI. In some projects, RTTI does not add any > benefits and people obviously turn it off. > > Is anybody aware of such a "switch" that will allow somebody to use > boost::shared_ptr without RTTI? Blessings, Foster -- Foster T. Brereton - Computer Scientist Software Technology Lab, Adobe Systems Incorporated fbrereto(a)adobe.com -- http://opensource.adobe.com

2 1

Using boost::lambda::bind with std::transform
by Kobi Cohen-Arazi 27 Apr '06

27 Apr '06

Hi, Would like to do the following with boost::lambda::bind #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> #include <algorithm> using namespace boost::lambda; struct Foo{ std::string get(){ ... } }; std::vector<Foo> array; // say it is already populated std::vector<std::string> tr; // the transformed instead using my handcrafted for loop, I would like to transform the std::list<Foo>::iterator endIter=array.end (); for (std::list<Foo>::iterator iter=array.begin(); iter!=endIter ;++iter) { noExtResults.push_back (iter.get().replace (0,5, "")); } I know it should be something like: std::transform (array.begin(), array.end (), std::back_inserter(tr), bind(&Foo::get, _1)); So here I'm stuck. The bind function will know to extract the string using get. But how to I get that string and do something like: bind(&std::string::replace (???)) Thanks in advance for your kind help, Kobi.

2 12

[algorithm - strings] problems with borland c++ 6
by Federico Feller 27 Apr '06

27 Apr '06

Hi, Im having problems using the string algorithm of boost with Borland C++ 6.0. Precisely, I cant compile the sequence.cpp because of the following error: [C++ Error] sequence.hpp(186): E2285 Could not find a match for 'boost::algorithm::detail::replace<InputT,ForwardIteratorT>(StringE,char *,char *,undefined,undefined)' Iam using std::string for string algorithms. Any ideas? Thanks, Federico __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[checked_delete] pimpl with scoped_ptr<T>
by Herve Alexanian 27 Apr '06

27 Apr '06

Hello, This is my first post regarding boost, I hope I am sending it to the right list. I have a question regarding the use of scoped_ptr versus shared_ptr: I am trying to use scoped_ptr<Impl> to implement the "Pimpl" idiom in order to hide the Impl definition from the user. Since my class is not copyable I thought using a scoped_ptr was better suited than a shared_ptr. So, something like this: class Impl; class MyClass { scoped_ptr<Impl> m_pImpl; ... ... }; When compiling client code, I see a checked_delete error. Reading the blurb about checked_delete this makes sense to me and I am able to work around the error by putting an explicit destructor declaration in MyClass. But, I don't see any error if I use a smart_ptr instead of a scoped_ptr. Why is the requirement about not deleting an incomplete type any different between scoped_ptr and shared_ptr? Thanks, Herve Alexanian Sonics, inc.

1 0