August 2005 - Boost-users - lists.boost.org

Re: [Boost-users] Question concerning boost::tuples::length (1.32)
by Douglas Gregor 05 Aug '05

05 Aug '05

On Aug 5, 2005, at 4:39 AM, Daniel Kruegler wrote: > Dear newsgroup, > > can you please explain me, **which** mailing list I can post to? > > According to a previous mail of Gmane Autoauthorizer I was > supposed to reply to your answer of my initial mail to get posting > access. > The posting said: > > "You are now authorized to post to the > gmane.comp.lib.boost.user newsgroup." You'll also need to sign up for the mailing list itself: http://lists.boost.org/mailman/listinfo.cgi/boost-users Once you've done that, you can turn off mail delivery and read/post through GMane. Doug

1 0

Re: [Boost-users] optional + serialize
by Jasper, Alexander 05 Aug '05

05 Aug '05

Hi Robert! thanks for the reply. I've to agree with you that my solution to problem was an ugly hack. It certainly is very inefficient and not exception safe. Furthermore it requires T::operator=. I took a look at the file you mentioned. But unfortunately I lack the knowledge of boost internals and, more important, I'm unfamiliar with the highly advanced c++ stuff, like inplace new or however the collection stuff is done. Therefore I, unfortunately, cannot suggest a better solution. I guess I've to bear with that performance hit, for now. I hope s.o. with better boost knowledge than me will address this issue in a future version. kind regards Alex > -----Ursprüngliche Nachricht----- > Von: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org]Im Auftrag von > Robert Ramey > Gesendet: Donnerstag, 4. August 2005 01:49 > An: boost-users(a)lists.boost.org > Betreff: Re: [Boost-users] optional + serialize > > > > a) I've read your post > b) I see your point that the serialization of optional > doesn't handle types > without default constructors > c) I agree that it should be fixed. > d) don't like the way you fixed it. I'm sure should work but > I don't like > the usage of the heap. For a better way to do this take a look at > collections_load_imp.hpp which adderss this problem in a > different context. > > Its too late to fixe for 1.33. > > Robert Ramey > > Jasper, Alexander wrote: > > Hi Jeff, All! > > > > thanks a lot for the reply. I assume the bug fix is in 1.33? > > > > I'm still having issues with boost.optinal and boost.serialize > > working together (in 1.32). > > Is for deserialization of boost::optional<T> T required to have > > default ctor?. > > > > This prevents boost::optional<boost::posix_time::time_period> from > > being serialized. The extraction code fails to compile. I would an > > ugly way around this (please see my last email). Does anybody have > > ideas for better solutions? > > > > I've attached a modified version of #include > > <boost/serialization/optional.hpp> to this email, that contains code > > changes to make to work with types w/o T having a default ctor. But > > I'm really unhappy with that solution and I don't know what I broke > > with this change... > > > > thanks in advance > > > > Alex > > > >> -----Ursprüngliche Nachricht----- > >> Von: boost-users-bounces(a)lists.boost.org > >> [mailto:boost-users-bounces@lists.boost.org]Im Auftrag von > >> Jeff Garland > >> Gesendet: Freitag, 29. Juli 2005 15:40 > >> An: boost-users(a)lists.boost.org > >> Betreff: Re: [Boost-users] questions concerning optional + > date_time > >> +serialize > >> > >> > >> On Fri, 29 Jul 2005 15:21:38 +0200, Jasper, Alexander wrote > >>> ... > >>> Another thing is that I'm unable to serialize not_a_date_time > >>> ptimes. The extractions fails here. I'm using the binary > >> archive. Is > >>> that supported? The documentation of date time only states > >>> compatibility with text and XML archive... > >> > >> There was a recent (jun 21) bug-fix in date-time that was > >> preventing correct > >> serialization of special values -- even with text archives -- > >> so it's likely > >> that's what you are seeing. I haven't tried the binary > >> archive, but there's > >> no reason it shouldn't work. I believe you should be able to > >> just pickup the > >> latest version of gregorian/greg_serialize.hpp and > >> posix_time/time_serialize.hpp to try it out. > >> > >> Jeff > >> _______________________________________________ > >> Boost-users mailing list > >> Boost-users(a)lists.boost.org > >> http://lists.boost.org/mailman/listinfo.cgi/boost-users > >> > > > > > > > > > >> _______________________________________________ > >> Boost-users mailing list > >> Boost-users(a)lists.boost.org > >> http://lists.boost.org/mailman/listinfo.cgi/boost-users > > > >

1 0

Re: [Boost-users] program options config file format?
by Lawry, Brian 05 Aug '05

05 Aug '05

> Matthias Kaeppler wrote: >> Hi, >> the program_options reference talks about >> being able to parse config files, but >> doesn't mention a thing about its layout. >> No examples are shown how a file has to >> look like to be parsable by program_options. Example layout: ..\libs\program_options\example\multiple_sources.cfg (used by multiple_sources.cpp in same directory). >> Any ideas? Besides the layout, which characters >> are treated as comments? > Anyone? > Matthias Kaeppler The only character I've found that indicates a comment is the '#' (pound/hash/sharp). One other thing I've noticed is that the option names are case-sensitive, at least by default. HTH. Brian Lawry Mfg Software Engineer Compressor Controls Corp blawry(a)cccglobal.com

2 1

Re: [Boost-users] Fw: shared_array EXC_BAD_ACCESS
by Christopher Hunt 05 Aug '05

05 Aug '05

Hi Rene/Peter, I'm happy to report that 1.33rc1 solves the EXC_BAD_ACCESS problem I was having on Mac OS X and does not require me to ensure that boost/config.hpp is included prior to any Carbon includes. Misc. comments on the build: (i) There are a lot of warnings re. "use of `long double' type; its size may change in a future release". May I suggest either fixing the problem or disabling the warning for gcc using the -Wno-long-double. Personally I dislike seeing any warnings come up as a user of boost or any other library. As a user, I'm only really interested in errors. Perhaps there should be a "developer" build option that shows warnings which is not the default. (ii) The following was reported duing my build (I'm installing alongside 1.32) - is this ok? ...failed updating 22 targets... ...skipped 26 targets... ...updated 4318 targets... I'll continue using 1.33rc1 to see if anything else comes up. Thanks for a great library and please let me know if there is anything else I can do for you guys. Cheers, -C On 03/08/2005, at 5:18 AM, boost-users-request(a)lists.boost.org wrote: > Rene Rivera wrote: >> Peter Dimov wrote: >>> I'm forwarding the following post from boost-users >>> >>> http://lists.boost.org/boost-users/2005/08/12938.php >>> >>> since it describes a pretty severe configuration problem on Mac OS X >>> that apparently leads to inconsistent definitions of >>> BOOST_HAS_THREADS and all kinds of interesting ODR violations. >> >> I think that problem is fixed. The original post doesn't mention the >> Boost version so it's hard to be sure. The checks for threading and >> the type of target getting built is considerably more complicated now >> than just the TARGET_CARBON check :-) >> >> It would be awesome if the original poster could test with 1.33 to >> make sure it's fixed.

1 0

Question about traversing mpl vectors
by Stephen Gross 05 Aug '05

05 Aug '05

Let's say I've got some mpl::vector. If I grab a begin iterator on it, and increment that iterator past the elements in the vector, what happens? For instance: ================================================== using boost; typedef mpl::vector<int, char> t; typedef mpl::begin<t>::type element0; // Should deref to 'int' typedef mpl::next<element0>::type element1; // Should deref to 'char' typedef mpl::next<element1>::type element2; // What happens? typedef mpl::next<element2>::type element3; // " typedef mpl::next<element3>::type element4; // " ================================================== Will boost let me iterate past the 'end' of an mpl::vector? Am I supposed to take care of bounds checking? Thanks, --Steve Stephen Gross Case Western School of Medicine Cleveland, OH "By Grabthar's hammer, by the sons of Worvan, you shall be avenged." - Dr. Lazarus

2 1

C++ Template Metaprogramming Book
by Eduardo Bezerra 05 Aug '05

05 Aug '05

I'm reading the C++ Template Metaprogramming book and I'm not understanding the following code from page 65-66: template <class T> struct param_type : mpl::eval_if < typename boost::is_scalar<T>::type , mpl::indentity<T> , boost::add_reference<T const> > {}; template <class T> struct param_type : mpl::eval_if < boost::is_scalar<T> --> ^^^^^^^^^^^^^^^^^^^^^^^ <-- , mpl::indentity<T> , boost::add_reference<T const> > {}; After reading again and again the explanation I still don't get why we don't need to use typename ....::type anymore. The text explains that all Boost's integral metafunctions suply a nested ::value, but how it is used in this context ? Any help would be greatly appreciated. Best regards, Eduardo

3 2

Mac OSX 10.4, Carbon.h, boost::shared_ptr, and BOOST_HAS_PTHREADS
by Rush Manbert 05 Aug '05

05 Aug '05

Hi all, I am writing all of this down because I was only able to find cryptic references to this problem in the Boost archives, and in the Apple Xcode-Users archives. I also want to ask whether my solution to the problem makes sense. I am developing a cross platform static library on OSX 10.4.2 using Xcode 2.1. The Xcode IDE includes a mechanism for unit testing that I am using. The unit test target is setup by Xcode, and one of the things it does is to include Carbon.h as a "prefix include". This means that the compiler command line includes "-include <path>/Carbon.h" and this header file is read BEFORE anything else. Everything had been going great until I wrote a test using boost::shared_ptr. I began to see all sorts of strange behaviors. After a while I turned on Guard Malloc in the debugger. That was when it started catching bad access errors in pthread_mutex_init, which was being called as a result of creating a boost:shared_ptr. It turns out that in the constructor for: template<class P, class D> shared_count(P p, D d) it executes this: pi_ = new sp_counted_base_impl<P, D>(p, d); Class sp_counted_base_impl is derived from sp_counted_base, and sp_counted_base has a data member declared as: #if defined(BOOST_HAS_THREADS) || defined(BOOST_LWM_WIN32) mutable mutex_type mtx_; #endif In the constructor for sp_counted_base, the constructor for mutex_type (lightweight_mutex) was being called. It in turn called pthread_mutex_init, passing the address of its mutex member, which is a 44 byte buffer. The memory access problem, though, is that when operator new called malloc, it did so as if sp_counted_base did NOT contain the mutex data member. This means that the 44 byte buffer wasn't allocated, and because Guard Malloc is very clever, the access outside of the allocated space was caught. I searched around and found messages where people said they saw problems like this because the Carbon headers were included before the Boost headers. This certainly fit my situation. I managed to change the order of header inclusion and everything started working. The class memory was allocated including space for mtx_ and the mutex init worked. This is really a lousy solution, though, so I kept poking around. I put things back so that Carbon.h was included on the command line, and assumed I would need to live with that. I added -DBOOST_HAS_THREADS to my compiler flags. The test still failed because the mutex memory had not been allocated. Because of this, I looked for anywhere where BOOST_HAS_THREADS could be #undef-ed. I found two possibilities, both in boost/config/suffix.hpp. It appeared that in my case BOOST_HAS_PTHREADS was not defined. This led me to boost/config/macos.hpp. I found this little code snippet: // // BSD runtime has pthreads, sigaction, sched_yield and gettimeofday, // of these only pthreads are advertised in <unistd.h>, so set the // other options explicitly: // # define BOOST_HAS_SCHED_YIELD # define BOOST_HAS_GETTIMEOFDAY # define BOOST_HAS_SIGACTION I tried including <unistd.h> ahead of shared_ptr.hpp, but that still failed the same way. I edited macos.hpp and added a fourth #define to this section: # define BOOST_HAS_PTHREADS When I built with the modified header, everything worked as expected. The mutex space was allocated. I don't want to change the Boost headers, though, so undid the change to macos.hpp. I went back to my test target in Xcode and changed the compiler flag -DBOOST_HAS_THREADS to -DBOOST_HAS_PTHREADS. I rebuilt my test code and everything works perfectly. So it *appears* that defining BOOST_HAS_PTHREADS on the compiler command line is the general case solution for this problem, but I'm looking for opinions more expert than mine. If this is indeed true, then does anyone know why the macro isn't just defined in boost/config/platform/macos.hpp? Have I opened myself up to other problems by doing this? Any help would be appreciated. - Rush

2 4

[Serialization] 1.33 RC1 Problem linking void_cast_register
by Richard Jennings 04 Aug '05

04 Aug '05

My application that works with 1.32 is failing to link with 1.33 RC1 due to boost::serialization::void_cast_register (specialised for my classes) being an unresolved external. In my case the void_cast_register call and the BOOST_CLASS_EXPORT macro are in one module while the serialization is done in another module, with all modules linked in one application. The code below also shows this problem, however if I add an archive class and header to the example then it will compile and link ok. Obviously this is when serialization is in the same module as the void_cast_register call. Any suggestions about what I need to add to make the application link? Richard ************************************************************************ ******* #pragma hdrstop #include <boost/serialization/is_abstract.hpp> #include <boost/serialization/serialization.hpp> #include <boost/serialization/export.hpp> #pragma link "libboost_serialization-bcb-mt-d-1_33.lib" class Z { public: virtual void DoSomething() =0; }; BOOST_IS_ABSTRACT(Z) class A : public Z { public: void DoSomething(){}; private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned intversion) { ar & boost::serialization::make_nvp("A", m_A); } int m_A; }; class B : public Z { public: void DoSomething(){}; private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned intversion) { ar & boost::serialization::make_nvp("B", m_B); } int m_B; }; BOOST_CLASS_EXPORT(A) BOOST_CLASS_EXPORT(B) int main(int argc, char* argv[]) { boost::serialization::void_cast_register<A, Z>(0,0); boost::serialization::void_cast_register<B, Z>(0,0); return 0; } Errors: [Linker Error] Unresolved external 'const boost::serialization::void_cast_detail::void_caster& boost::serialization::void_cast_register<A, Z>(const A *, const Z *)' referenced from D:\PROJECTS\...\SOURCE\TEST\BUILD\MAIN.OBJ [Linker Error] Unresolved external 'const boost::serialization::void_cast_detail::void_caster& boost::serialization::void_cast_register<B, Z>(const B *, const Z *)' referenced from D:\PROJECTS\...\SOURCE\TEST\BUILD\MAIN.OBJ

3 3

Boost.Spirit question
by Brad Retzlaff 04 Aug '05

04 Aug '05

I've having a hard time getting my parser to work correctly. I'm trying to create a script parser to create tests, actions, and groups defined in a file. I have the grammer working except for one small issue. I can't get rid of the closing quote on my sentence. It skips the first one just fine. I'm using spirit 1.6.2 The script is below named script.txt: ---------------------- Groups {G100, "This is group G100", G200, "This is group G200" } Actions {A100, "This is an action" } Tests {T100, "This is a test", 0, 5, "VDC" } TestFlow {a } ---------------------------------- I want to have the option of using double quotes (") around strings for the discriptions in Groups, Actions, and Tests section to make it easier to read. I use comma as a delimiter. Here is my spirit code below: ---------------------------------- #include <iostream> #include <fstream> #include <vector> #if defined(_DEBUG) //#define BOOST_SPIRIT_DEBUG #endif // defined(_DEBUG) #include "boost/spirit.hpp" #include <boost/spirit/core.hpp> #include <boost/spirit/utility.hpp> #include <boost/spirit/symbols.hpp> //////////////////////////////////////////////////////////////////////////// /// // used namespaces using namespace boost::spirit; using namespace std; namespace { void my_action(char const* first, char const* last) { std::string str(first, last); std::cout << str << std::endl; } void my_number(float val) { std::cout << val << std::endl; } } struct script_grammar : public grammar<script_grammar> { template <typename ScannerT> struct definition { definition(script_grammar const& self) { Group_Composite = Group >> BeginBrace >> +Group_Action_Parms >> EndBrace; Action_Composite = Action >> BeginBrace >> +Group_Action_Parms >> EndBrace; Test_Composite = Test >> BeginBrace >> +Test_Parms >> EndBrace; TestFlow_Composite = TestFlow >> BeginBrace >> +TestFlow_Parms >> EndBrace; Group = as_lower_d[str_p("groups")]; Group_Action_Parms = Token[&my_action] >> Comma >> Token[&my_action] >> !Comma; Action = as_lower_d[str_p("actions")]; Test = as_lower_d[str_p("tests")]; Test_Parms = Token[&my_action] >> Comma >> Token[&my_action] >> Comma >> real_p[&my_number] >> Comma >> real_p[&my_number] >> Comma >> Token[&my_action] >> !Comma; TestFlow = as_lower_d[str_p("testflow")]; TestFlow_Parms = Token; BeginBrace = ch_p('{'); EndBrace = ch_p('}'); Comma = ch_p(','); Token = +Token_Sub; Token_Sub = alnum_p; //(alnum_p - ch_p(34)); // ^ ch_p('\"')); first = *( Group_Composite | Action_Composite | Test_Composite ) >> TestFlow_Composite; BOOST_SPIRIT_DEBUG_RULE(Group_Composite); BOOST_SPIRIT_DEBUG_RULE(Action_Composite); BOOST_SPIRIT_DEBUG_RULE(Test_Composite); BOOST_SPIRIT_DEBUG_RULE(TestFlow_Composite); BOOST_SPIRIT_DEBUG_RULE(Group); BOOST_SPIRIT_DEBUG_RULE(Group_Action_Parms); BOOST_SPIRIT_DEBUG_RULE(Action); BOOST_SPIRIT_DEBUG_RULE(Test); BOOST_SPIRIT_DEBUG_RULE(Test_Parms); BOOST_SPIRIT_DEBUG_RULE(TestFlow); BOOST_SPIRIT_DEBUG_RULE(TestFlow_Parms); BOOST_SPIRIT_DEBUG_RULE(BeginBrace); BOOST_SPIRIT_DEBUG_RULE(EndBrace); BOOST_SPIRIT_DEBUG_RULE(Comma); BOOST_SPIRIT_DEBUG_RULE(Token); BOOST_SPIRIT_DEBUG_RULE(first); BOOST_SPIRIT_DEBUG_RULE(Token_Sub); } rule<ScannerT> Group_Composite, Action_Composite, Test_Composite, TestFlow_Composite, Group, Group_Action_Parms, Action, Test, Test_Parms, TestFlow, TestFlow_Parms, BeginBrace, EndBrace, Comma, Token, Token_Sub; rule<ScannerT> first; rule<ScannerT> const& start() const { return first; } }; }; struct skip_grammar : public grammar<skip_grammar> { template <typename ScannerT> struct definition { definition(skip_grammar const& /*self*/) { skip = space_p | ch_p('\"') ; BOOST_SPIRIT_DEBUG_RULE(skip); } rule<ScannerT> skip; rule<ScannerT> const& start() const { return skip; } }; }; template<typename GrammarT> void parse(GrammarT const& g, char const* filename) { ifstream in(filename); if (!in) { cerr << "Could not open input file: " << filename << endl; return; } in.unsetf(ios::skipws); // Turn off white space skipping on the stream vector<char> vec; std::copy( istream_iterator<char>(in), istream_iterator<char>(), std::back_inserter(vec)); vector<char>::const_iterator start = vec.begin(); vector<char>::const_iterator end = vec.end(); skip_grammar skip; parse_info<vector<char>::const_iterator> result = parse(start, end, g, skip); if (result.full) cerr << filename << " Parses OK" << endl; else { cerr << filename << " Fails Parsing" << endl; for (int i = 0; i < 50; i++) { if (result.stop == end) break; cerr << *result.stop++; } cerr << endl; } } // main entrypoint int main(int argc, char* argv[]) { // Start grammar definition cerr << "Start of Parsing ..." << endl; // main driver code script_grammar g; if (2 == argc) parse(g, argv[1]); else cerr << "No filename given" << endl; return 0; } The output looks like this: Start of Parsing ... G100 This is group G100" G200 This is group G200" A100 This is an action" T100 This is a test" 0 5 VDC" c:\script.txt Parses OK I'm trying to get rid of the quote on the end. Please help. Thanks, Brad Brad Retzlaff Design Engineer Functional Test Development Plexus Technology Group 55 Jewelers Park Dr. PO Box 677 Neenah, WI 54957 Phone: (920) 720-6733 Fax: (920) 751-5366 http://www.plexus.com <http://www.plexus.com/>

1 0

program options config file format?
by Matthias Kaeppler 04 Aug '05

04 Aug '05

Hi, the program_options reference talks about being able to parse config files, but doesn't mention a thing about its layout. No examples are shown how a file has to look like to be parsable by program_options. Any ideas? Besides the layout, which characters are treated as comments? -- Matthias Kaeppler

1 1