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

[filesystem] Using filesystem library from Boost version 1.44 on Cygwin 1.7
by Clarke, Carus V 27 Aug '10

27 Aug '10

I have been using the filesystem library from Boost version 1.43 on a Cygwin 1.7.6-1 platform without any problems. The library was built using the Cygwin version of GCC 4.3.4. The library from the 1.44 version of Boost compiles compiles o.k., but the functions that access files no longer work. This appears to be true for both versions 2 and 3 of the library. Below is a simple program that runs o.k. with the Boost version 1.43 version of the library. The program runs but can not read the file status using Boost version 1.44. This program also works fine when built using MSVC 9.0 and Boost version 1.44. Am I doing something wrong? Any help would be appreciated. Thanks, Carus V. (Bud) Clarke carus.v.clarke(a)boeing.com //-------------------- #include <fstream> #include <iostream> #include <string> #include <boost/version.hpp> #define BOOST_FILESYSTEM_NO_DEPRECATED # if !defined(BOOST_FILESYSTEM_VERSION) # define BOOST_FILESYSTEM_VERSION 3 // disabled: # define BOOST_FILESYSTEM_VERSION 2 # endif #include <boost/filesystem.hpp> #include <boost/system/error_code.hpp> int main() { namespace boost_fs = boost::filesystem; const std::string pathStr = "foo"; std::ofstream ostrm(pathStr.c_str()); if (ostrm) { ostrm << "abcde-12345" << std::endl; ostrm.close(); } boost_fs::path path(pathStr); boost::system::error_code ec; std::cout << std::boolalpha; std::cout << "Checking status of file " << pathStr << "..." << std::endl; boost_fs::file_status st = boost_fs::status(path, ec); std::cout << "Error code value: " << ec.value() << std::endl; std::cout << "Error code message: " << ec.message() << std::endl; return 0; } //-------------------- This program's output on my system is shown below. The file 'foo' is written by the program and does actually exist. For version 2: boost::filesystem library version is v2 Checking status of file foo... Error code value: 0 Error code message: The operation completed successfully Does file exist? false For version 3: boost::filesystem library version is v3 Checking status of file foo... Error code value: 2 Error code message: The system cannot find the file specified Does file exist? false //--------------------

2 1

Re: [Boost-users] [Boost.MPI] question about serializingcustomobject
by Elli Barasch 27 Aug '10

27 Aug '10

Robert Ramey <ramey(a)rrsd.com> wrote: >David Abrahams wrote: >>>> And since Boost.MPI and Boost.Serialization are so closely >>>> related, I think it's especially important that *you* underestand. >>> >>> I disagree. Boost MPI depends upon Boost.Serialization >>> but not the other way around. >> >> I didn't say they were interdependent, just that they were >> closely-related. But anyway, I think you're being shortsighted: The >> success of tools built on top of Boost.Serialization is an important >> indicator of the correctness and genericity of its design. > >> Boost.Serialization *is* dependent on Boost.MPI for a portion of its >> userbase, > ><off topic> what portion of the user base? (This is a rhetorical question >please don't spend any time answering it.) It's always bothered me >that we have no per library data/feedback on the interest/usage >on a library by library basis. I've spoken about this before and >I know you agree with me about it. But until this get's addressed >I think we just have to set these questions aside and recognize >that the answers are anyone's guess. > ><snip> > >> You can't be a generic serialization library without reference to real >> applications. Maybe you still haven't really decided whether serving >> Boost.MPI and its users is something you want to do. > > I think that >> might account for a good deal of the recurring friction we experience. >> It would be a good idea to settle on an answer to that question, along >> with the question of what other applications you're willing to >> support. > >I am acutely aware of this aspect of "generic library design". Every >post on this list reminds me of it. > >>> I only really have few observations/suggestions at this point. >>> >>> a) It would be helpful if there were a way to test the serialization >>> of the archive classes in boost MPI without having MPI installed. >>> If this is not possible, it would seem to me that the serialization >>> is intertwined with the data transport - rather than be separated >>> as it is in the stream/streambuf io/stream design. This would look >>> like a design flaw to me. >> >> Helpful to whom? I agree this is all a good idea, but I'm not sure >> how this relates to anything else we're discussing. > >It would permit me to use the MPI serialization as a use case >to verify that I hadn't broken anything. I know what your going >to say - concepts - but that is going to be a while before that >happens. > >>> b) user experience seems to show that archive >>> construction/destruction is a significant performance issue when a >>> new archive is made for each data transmission. On the other hand, >>> one has to do this since the current archive implemenation track >>> addresses of serialized obects so the same archive can't be use send >>> the same structure (maybe with changed data) multiple times. > >> I can't understand how you reach that conclusion. In my long >> explanation I thought I made it clear that Boost.MPI and its database >> get a great deal of its performance advantage from exactly that: >> sending the same structure multiple times with the same MPI type map. > >hmm - what about tracked objects? I suggested turning off tracking >and Matthias told me that it was needed to send pointers. But for this >to work an archive has to be reconstructed everytime to re-initialize >the tracking lists. I don't want to spend a lot of time on this as that >means I have to delve into the MPI serialization and I don't want >to do this. > >>> Given that MPI has a focus on performance, I wonder if this has been >>> considered. I looked a the documentation, code and examples and it >>> wasn't obvious to me how this is question was addressed - if at all. >> >> We've obviously misunderstood one another somewhere along the way. It >> would be good if we could get that cleared up. > >I think it would take too much time for me to understand. And if I did >come to understand it, I might have something to say about it. If I >said it, then it might start a thread which would cost even more time >which I don't have right now. > >Robert Ramey > > > > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] [Boost.MPI] question about serializingcustomobject
by Elli Barasch 27 Aug '10

27 Aug '10

Robert Ramey <ramey(a)rrsd.com> wrote: >David Abrahams wrote: >>>> And since Boost.MPI and Boost.Serialization are so closely >>>> related, I think it's especially important that *you* underestand. >>> >>> I disagree. Boost MPI depends upon Boost.Serialization >>> but not the other way around. >> >> I didn't say they were interdependent, just that they were >> closely-related. But anyway, I think you're being shortsighted: The >> success of tools built on top of Boost.Serialization is an important >> indicator of the correctness and genericity of its design. > >> Boost.Serialization *is* dependent on Boost.MPI for a portion of its >> userbase, > ><off topic> what portion of the user base? (This is a rhetorical question >please don't spend any time answering it.) It's always bothered me >that we have no per library data/feedback on the interest/usage >on a library by library basis. I've spoken about this before and >I know you agree with me about it. But until this get's addressed >I think we just have to set these questions aside and recognize >that the answers are anyone's guess. > ><snip> > >> You can't be a generic serialization library without reference to real >> applications. Maybe you still haven't really decided whether serving >> Boost.MPI and its users is something you want to do. > > I think that >> might account for a good deal of the recurring friction we experience. >> It would be a good idea to settle on an answer to that question, along >> with the question of what other applications you're willing to >> support. > >I am acutely aware of this aspect of "generic library design". Every >post on this list reminds me of it. > >>> I only really have few observations/suggestions at this point. >>> >>> a) It would be helpful if there were a way to test the serialization >>> of the archive classes in boost MPI without having MPI installed. >>> If this is not possible, it would seem to me that the serialization >>> is intertwined with the data transport - rather than be separated >>> as it is in the stream/streambuf io/stream design. This would look >>> like a design flaw to me. >> >> Helpful to whom? I agree this is all a good idea, but I'm not sure >> how this relates to anything else we're discussing. > >It would permit me to use the MPI serialization as a use case >to verify that I hadn't broken anything. I know what your going >to say - concepts - but that is going to be a while before that >happens. > >>> b) user experience seems to show that archive >>> construction/destruction is a significant performance issue when a >>> new archive is made for each data transmission. On the other hand, >>> one has to do this since the current archive implemenation track >>> addresses of serialized obects so the same archive can't be use send >>> the same structure (maybe with changed data) multiple times. > >> I can't understand how you reach that conclusion. In my long >> explanation I thought I made it clear that Boost.MPI and its database >> get a great deal of its performance advantage from exactly that: >> sending the same structure multiple times with the same MPI type map. > >hmm - what about tracked objects? I suggested turning off tracking >and Matthias told me that it was needed to send pointers. But for this >to work an archive has to be reconstructed everytime to re-initialize >the tracking lists. I don't want to spend a lot of time on this as that >means I have to delve into the MPI serialization and I don't want >to do this. > >>> Given that MPI has a focus on performance, I wonder if this has been >>> considered. I looked a the documentation, code and examples and it >>> wasn't obvious to me how this is question was addressed - if at all. >> >> We've obviously misunderstood one another somewhere along the way. It >> would be good if we could get that cleared up. > >I think it would take too much time for me to understand. And if I did >come to understand it, I might have something to say about it. If I >said it, then it might start a thread which would cost even more time >which I don't have right now. > >Robert Ramey > > > > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] [Boost.MPI] question about serializingcustomobject
by Elli Barasch 27 Aug '10

27 Aug '10

Robert Ramey <ramey(a)rrsd.com> wrote: >David Abrahams wrote: >>>> And since Boost.MPI and Boost.Serialization are so closely >>>> related, I think it's especially important that *you* underestand. >>> >>> I disagree. Boost MPI depends upon Boost.Serialization >>> but not the other way around. >> >> I didn't say they were interdependent, just that they were >> closely-related. But anyway, I think you're being shortsighted: The >> success of tools built on top of Boost.Serialization is an important >> indicator of the correctness and genericity of its design. > >> Boost.Serialization *is* dependent on Boost.MPI for a portion of its >> userbase, > ><off topic> what portion of the user base? (This is a rhetorical question >please don't spend any time answering it.) It's always bothered me >that we have no per library data/feedback on the interest/usage >on a library by library basis. I've spoken about this before and >I know you agree with me about it. But until this get's addressed >I think we just have to set these questions aside and recognize >that the answers are anyone's guess. > ><snip> > >> You can't be a generic serialization library without reference to real >> applications. Maybe you still haven't really decided whether serving >> Boost.MPI and its users is something you want to do. > > I think that >> might account for a good deal of the recurring friction we experience. >> It would be a good idea to settle on an answer to that question, along >> with the question of what other applications you're willing to >> support. > >I am acutely aware of this aspect of "generic library design". Every >post on this list reminds me of it. > >>> I only really have few observations/suggestions at this point. >>> >>> a) It would be helpful if there were a way to test the serialization >>> of the archive classes in boost MPI without having MPI installed. >>> If this is not possible, it would seem to me that the serialization >>> is intertwined with the data transport - rather than be separated >>> as it is in the stream/streambuf io/stream design. This would look >>> like a design flaw to me. >> >> Helpful to whom? I agree this is all a good idea, but I'm not sure >> how this relates to anything else we're discussing. > >It would permit me to use the MPI serialization as a use case >to verify that I hadn't broken anything. I know what your going >to say - concepts - but that is going to be a while before that >happens. > >>> b) user experience seems to show that archive >>> construction/destruction is a significant performance issue when a >>> new archive is made for each data transmission. On the other hand, >>> one has to do this since the current archive implemenation track >>> addresses of serialized obects so the same archive can't be use send >>> the same structure (maybe with changed data) multiple times. > >> I can't understand how you reach that conclusion. In my long >> explanation I thought I made it clear that Boost.MPI and its database >> get a great deal of its performance advantage from exactly that: >> sending the same structure multiple times with the same MPI type map. > >hmm - what about tracked objects? I suggested turning off tracking >and Matthias told me that it was needed to send pointers. But for this >to work an archive has to be reconstructed everytime to re-initialize >the tracking lists. I don't want to spend a lot of time on this as that >means I have to delve into the MPI serialization and I don't want >to do this. > >>> Given that MPI has a focus on performance, I wonder if this has been >>> considered. I looked a the documentation, code and examples and it >>> wasn't obvious to me how this is question was addressed - if at all. >> >> We've obviously misunderstood one another somewhere along the way. It >> would be good if we could get that cleared up. > >I think it would take too much time for me to understand. And if I did >come to understand it, I might have something to say about it. If I >said it, then it might start a thread which would cost even more time >which I don't have right now. > >Robert Ramey > > > > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] [Boost.MPI] question about serializingcustomobject
by Elli Barasch 27 Aug '10

27 Aug '10

Robert Ramey <ramey(a)rrsd.com> wrote: >David Abrahams wrote: >>>> And since Boost.MPI and Boost.Serialization are so closely >>>> related, I think it's especially important that *you* underestand. >>> >>> I disagree. Boost MPI depends upon Boost.Serialization >>> but not the other way around. >> >> I didn't say they were interdependent, just that they were >> closely-related. But anyway, I think you're being shortsighted: The >> success of tools built on top of Boost.Serialization is an important >> indicator of the correctness and genericity of its design. > >> Boost.Serialization *is* dependent on Boost.MPI for a portion of its >> userbase, > ><off topic> what portion of the user base? (This is a rhetorical question >please don't spend any time answering it.) It's always bothered me >that we have no per library data/feedback on the interest/usage >on a library by library basis. I've spoken about this before and >I know you agree with me about it. But until this get's addressed >I think we just have to set these questions aside and recognize >that the answers are anyone's guess. > ><snip> > >> You can't be a generic serialization library without reference to real >> applications. Maybe you still haven't really decided whether serving >> Boost.MPI and its users is something you want to do. > > I think that >> might account for a good deal of the recurring friction we experience. >> It would be a good idea to settle on an answer to that question, along >> with the question of what other applications you're willing to >> support. > >I am acutely aware of this aspect of "generic library design". Every >post on this list reminds me of it. > >>> I only really have few observations/suggestions at this point. >>> >>> a) It would be helpful if there were a way to test the serialization >>> of the archive classes in boost MPI without having MPI installed. >>> If this is not possible, it would seem to me that the serialization >>> is intertwined with the data transport - rather than be separated >>> as it is in the stream/streambuf io/stream design. This would look >>> like a design flaw to me. >> >> Helpful to whom? I agree this is all a good idea, but I'm not sure >> how this relates to anything else we're discussing. > >It would permit me to use the MPI serialization as a use case >to verify that I hadn't broken anything. I know what your going >to say - concepts - but that is going to be a while before that >happens. > >>> b) user experience seems to show that archive >>> construction/destruction is a significant performance issue when a >>> new archive is made for each data transmission. On the other hand, >>> one has to do this since the current archive implemenation track >>> addresses of serialized obects so the same archive can't be use send >>> the same structure (maybe with changed data) multiple times. > >> I can't understand how you reach that conclusion. In my long >> explanation I thought I made it clear that Boost.MPI and its database >> get a great deal of its performance advantage from exactly that: >> sending the same structure multiple times with the same MPI type map. > >hmm - what about tracked objects? I suggested turning off tracking >and Matthias told me that it was needed to send pointers. But for this >to work an archive has to be reconstructed everytime to re-initialize >the tracking lists. I don't want to spend a lot of time on this as that >means I have to delve into the MPI serialization and I don't want >to do this. > >>> Given that MPI has a focus on performance, I wonder if this has been >>> considered. I looked a the documentation, code and examples and it >>> wasn't obvious to me how this is question was addressed - if at all. >> >> We've obviously misunderstood one another somewhere along the way. It >> would be good if we could get that cleared up. > >I think it would take too much time for me to understand. And if I did >come to understand it, I might have something to say about it. If I >said it, then it might start a thread which would cost even more time >which I don't have right now. > >Robert Ramey > > > > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] BoostSerialization callinga customserialize method
by Elli Barasch 27 Aug '10

27 Aug '10

Robert Ramey <ramey(a)rrsd.com> wrote: >Pooyan Dadvand wrote: > >> Can you please explain me more the idea of extradata structure? >> Consider that my extradata can be a double, ublas::vector, or even >> std::vector<weak_ptr<Element> > or any new type of variables. I >> have: >> >> std::vector<std::pair<VariableData, extradata> > mData >> ... >> ar << mData; >> >> >> and each element of vector can have a different type of data with >> different size or even have pointers. (It's a heterogeneous >> container) > >The above will work as written. > >Maybe what you want is: > >template<class T> >class mytype : std::vector<std::pair<VariableData, T> > { > template<class Archive> > void serialize(Archive &ar, const unsigned int version){ > ar << boost::serialization::base_object(*this); > } >}; > >then you can > >mytype<double> m_t >... >ar << m_t > >The possibilities are endless. This really isn't about the serialization >library >but about C++ > >Robert Ramey > > > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

[boost::wave] Hooks not called for conditionals
by Alden King 27 Aug '10

27 Aug '10

I am currently working on a project that uses Wave to pre-process and tokenize C/C++ code, but I am not getting everything that I expect from the preprocessing hooks. We use the preprocessing hooks to extract data about false-branches, macro calls and macro expansions so this is a major roadblock for us. I am trying to extract information about the true and false branch of #if 1 int foo; #elif 0 float foo; #else struct { } foo; #endif The first #if is seen by 'found_directive'. If that returns false, then I get #ifint foo; #eliffloat foo; #else struct { } foo; #endif Note that it skips the newline after the #if and #elif and that it doesn't reveal their conditions. If it returns true, then 'evaluated_conditional_expression also gets called and I get #if 1 // [Taken] int foo; #elif0 float foo; struct { } foo; Without the #else directive, the #endif directive, and the whitespace between #elif and it's condition. My problem is that the false branch is not seen by either function (the endif also has trouble sometimes). I therefore expected all tokens in the false branch to be processed by 'may_skip_whitespace' or 'skipped_token', but that is not the case. Could you please help me to find our how to get the tokens from the false branch of the conditional expression using the preprocessing hooks? I've attached my wave test program and a sample input file. Thanks.

2 1

Boost Serialization calling a custom serialize method
by Pooyan Dadvand 27 Aug '10

27 Aug '10

Hi, Im trying to use the boost serialization in our project Kratos (a Multi-physics finite element code) in which I found the following problem, I have a class Variable which is derived from VariableData as follow: Class VariableData { std::size_t mKey; public: ..... }; template<class TDataType> class Variable : public VariableData { .... } Now I have a container which holds a pairs, consist of VariableData pointer to the Variable and a void* pointer to its value: std::vector<std::pair<const VariableData*, void*> > which I want to serialize but as it can be seen I dont have the pointer to data in my variable and I might need to implement a costumized version of Serialized with void* pValue as an additional parameter for VariableData and Variable classes: template<class TArchiveType> Variable::serialize(TArchiveType &rArchive, const unsigned int Version, void* pValue) { rArchive & static_cast<TDataType>(pVAlue); } The problem here is the template definition of this method which make it impossible to be virtual. I note that the library uses get_extended_type_info for this porposed. But I dont know how is its correct way of use. Can anybody give me a hint about how I can handle this problem? Just to add some restriction: - I dont want to add a hierarchy of handlers instead of pair because it adds another pointer jump to the container and reduce its performance in normal use of it - I dont want to add a version of non template members for each archive type while it makes a lot of duplications and makes extra dependency to the archive types in a layer of code which is not expected to have this dependency Thanks, Pooyan. ____________________________________________________________________________ ____________________________________________________________________________ _______________________ Dr. Pooyan Dadvand Member of Kratos team International Center for Numerical Methods in Engineering - CIMNE Campus Norte, Edificio C1 c/ Gran Capitán s/n 08034 Barcelona, España Tel: (+34) 93 401 56 96 Fax: (+34) 93.401.65 17 web: <http://www.cimne.com> www.cimne.com <http://www.cimne.com/kratos/> www.cimne.com/kratos/ ____________________________________________________________________________ ____________________________________________________________________________ _______________________ AVISO IMPORTANTE Los datos de carácter personal contenidos en el mensaje, se registrarán en un fichero para facilitar la gestión de las comunicaciones de CIMNE. Se pueden ejercitar los derechos de acceso, rectificación, cancelación y oposición por escrito, dirigiéndose a nuestras oficinas de CIMNE, Gran Capitán s/n, Edificio C1 - Campus Norte UPC, 08034 Barcelona, España. AVÍS IMPORTANT Les dades de caràcter personal contingudes en aquest missatge es registraran en un fitxer per facilitar la gestió de les comunicacions del CIMNE. Es poden exercir els drets d'accés, rectificació, cancel·lació i oposició, per escrit a les nostres oficines del CIMNE, Gran Capità s/n, Edifici C1, Campus Nord UPC, 08034 Barcelona, Espanya. IMPORTANT NOTICE All personal data contained in this mail will be processed confidentially and stored in a file property of CIMNE in order to manage corporate communications. You may exercise the right of access, rectification, deletion and objection by letter sent to CIMNE, Gran Capitán, Edificio C1 - Campus Norte UPC, 08034 Barcelona, Spain.

5 17

[Hash] Custom hash_value for Pointers
by Hossein Haeri 27 Aug '10

27 Aug '10

Dear all, Should not the program in the P.S. output "I got used!"? If not, how can I ensure that it's size_t hash_value(B*) which gets called upon use of bPtrHasher's operator()? TIA, --Hossein P.S. namespace Bs { struct B { virtual string id() const {return "This is a B!";} }; struct D: B { string id() const {return "And, this one is a D.";} }; size_t hash_value(B* bptr) { cout << "I got used!" << endl; boost::hash<string> hasher; return hasher(bptr->id()); } } int main() { Bs::B* bp1 = new Bs::B; Bs::B* bp2 = new Bs::D; boost::hash<Bs::B*> bPtrHasher; size_t h1 = bPtrHasher(bp1), h2 = bPtrHasher(bp2); }

2 1

NDEBUG causes a compilation error in Boost.Interprocess
by Sergey Kurenkov 27 Aug '10

27 Aug '10

I use Boost 1.42 and gcc 4.3.1 on HP-UX 11.31. So today I defined NDEBUG and BOOST_DISABLE_ASSERTS in my makefile, ran make and got this error: ../../../src/libs/src/external/boost/1.42.0/boost/interprocess/sync/posix/semaphore_wrapper.hpp: In function 'void boost::interprocess::detail::semaphore_close(sem_t*)': ../../../src/libs/src/external/boost/1.42.0/boost/interprocess/sync/posix/semaphore_wrapper.hpp:102: error: 'assert' was not declared in this scope ../../../src/libs/src/external/boost/1.42.0/boost/interprocess/sync/posix/semaphore_wrapper.hpp: In function 'void boost::interprocess::detail::semaphore_destroy(sem_t*)': ../../../src/libs/src/external/boost/1.42.0/boost/interprocess/sync/posix/semaphore_wrapper.hpp:137: error: 'assert' was not declared in this scope If I do not set NDEBUG and BOOST_DISABLE_ASSERTS everything is OK. Seems like the problem is that in semaphore_wrapper.hpp there is a call to assert() and if NDEBUG is set then correct headers are not included.

2 1