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

bjam, 64-bit builds, VC8
by Jarl Lindrud 28 Apr '06

28 Apr '06

Hi! I need to build the boost libraries, and eventually my own application, in 64 bi t mode on Windows, but unfortunately I haven't been able to find any information on how to do so. Does anyone here have any tips? Typically, for a 32 build of boost.thread, for instance, I would type "bjam --with-thread -sTOOLS=vc-8_0 stage", but I don't know what the invocation should be for a 64 bit build. I'm using Visual C++ 2005 (the full version, not "express"). Thanks! Jarl.

1 0

multi_index, best way to do insert_or_replace
by bert hubert 28 Apr '06

28 Apr '06

Hi, I misread (or didn't read) the boost::multi_index_container documentation and assumed 'insert' on a unique index would do 'replace', but of course it doesn't and shouldn't. So, I've made this change: - s_negcache.insert(ne); + + pair<negcache_t::iterator, bool> res=s_negcache.insert(ne); + if(!res.second) { + s_negcache.erase(res.first); + s_negcache.insert(ne); + } But I can't help feeling there is probably a better and prettier way. Do people have any suggestions? In this case, ne is a NegCacheEntry, defined as: struct NegCacheEntry { string d_name; QType d_qtype; string d_qname; uint32_t d_ttd; }; And the index: typedef multi_index_container < NegCacheEntry, indexed_by < ordered_unique< composite_key< NegCacheEntry, member<NegCacheEntry, string, &NegCacheEntry::d_name>, member<NegCacheEntry, QType, &NegCacheEntry::d_qtype> >, composite_key_compare<CIStringCompare, std::less<QType> > >, ordered_non_unique< member<NegCacheEntry, uint32_t, &NegCacheEntry::d_ttd> > > >negcache_t; Thanks! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services

2 2

problem with 1.33.1 dll's
by george 28 Apr '06

28 Apr '06

hello! today I switch to 1.33.1 an I get some problems with dynamic libs: until 1.33 I just link with the name of the library -lboost_date_time -l boost_thread now with 1.33.1 I cant, I get: /usr/lib/gcc/i586-suse-linux/4.0.2/../../../../i586-suse-linux/bin/ld: cannot find -lboost_date_time and etc.... autolinking doesn't work so I link with the whole name -lboost_date_time-gcc-mt-1_33_1 -lboost_date_time-gcc-1_33_1 and it get compiled but when I try to run it, it can't find the libs(.so) ./server: error while loading shared libraries: libboost_thread-gcc-mt-1_33_1.so.1.33.1: cannot open shared object file: No such file or directory ./client: error while loading shared libraries: libboost_date_time-gcc-1_33_1.so.1.33.1: cannot open shared object file: No such file or directory but there are those files in the folder..... should I run any utility to fix this? P.S. I build 1.33.1 with: ./configure --prefix=/usr/local make make install thansks for any help.

2 2

[multi_array] How to use non-default constructor?
by Seweryn Habdank-Wojewódzki 28 Apr '06

28 Apr '06

Hi! I would like to know if in multi_array there is a possibility to initialize multi_array using non-default constructor? When I am using std::vector there is a possibility to do it like that: std::vector<MyObject> my_object_vec ( 2, MyObject( parameters ) ); This vector constructor uses non-default constructor of MyObject. In C++ arrays constructon like that should be done in two steps first is to initialize array (uses default constructor) and then we could assign values to the array using copy constructor, but this is not nice, and in my cases not good solution. Important is that in MyObject class there shouldn't be default constructor, and better not to use copy constructor. Of course there exists non-default constructor like MyObject ( const Parameters & parameters ). Regards. -- |\/\/| Seweryn Habdank-Wojewódzki `\/\/

2 4

[MPL] Loooong vectors
by Jaakko Järvi 28 Apr '06

28 Apr '06

Howdy, Are type containers with hundreds of types (maybe even more) at all realistic regarding compilation resources? Is there a container type for such very large type containers already? Access to elements should be at least logarithmic. Vectors of vectors, or a tree structure built out of vectors, would probably do unless there is something better out there already. Best, Jaakko Järvi

1 0

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