November 2008 - Boost - lists.preview.boost.org

Re: [boost] llvm anyone?
by Giovanni Piero Deretta 13 Nov '08

13 Nov '08

On Wed, Nov 12, 2008 at 4:34 PM, Marshall Clow <marshall(a)idio.com> wrote: > At 10:29 AM -0500 11/12/08, Neal Becker wrote: >> >> Anyone testing on llvm compiler? (I'm trying it now on linux F9 x86_64 >> llvm-2.4) > > I believe that the llvm support for C++ is best described as "currently > quite limited". > I expect this to change over the next year or so, though. The clang front end is certainly only in an experimental stage, but LLVM also support the gcc front end (LLVM-gcc) which means that its C++ support should be about as good as native GCC. As the backend is quite different and there might be some small differences in the front end, it might still make sense to test on it. -- gpd

6 5

[OT] Contact with Jeff Garland
by Robert Kawulak 13 Nov '08

13 Nov '08

Hi Jeff, I was not able to contact you via e-mail -- could you please write to me how can I reach you? Best regards, Robert

1 0

[spirit] Where is SPIRIT_VERSION?
by Robert Ramey 12 Nov '08

12 Nov '08

In the new headers for spirit - I only find SPIRIT_VERSION in some "classic" file. Basically I would like to compile something conditionally on SPIRIT_VERSION. Another point: Wouldn't it have made a lot more sense just to make a new directory and namespace "spirit2" and avoid the the convolution that occurs now and the associated warning. The warning doesn't work for all compilers. Robert Ramey

2 3

Compiling program_options v1.35 on msvc9.0 fix
by Okko Willeboordse 12 Nov '08

12 Nov '08

Hi All, My co-worker Evert van de Waal noticed the following; I have had some problems compiling program_options v1.35 on visual C++ 9.0 (2008) Express. It seems that this compiler does not correctly export some global variables when compiling to DLL, leading to unresolved dependencies. I have had to make a few changes: In file *options_description.hpp*, line 158: Replaced static const unsigned m_default_line_length; with BOOST_STATIC_CONSTANT (unsigned, m_default_line_length = 80); This is an old fix that I found in the mail archives (2005), seems to have been erroneously dropped from the base-line. In file *options_description.cpp*: removed the declaration of m_default_line_length. In file *value_semantic.cpp*: a singleton variable was defined but not properly linked by vc9.0. I changed the implementation to (line 17) BOOST_PROGRAM_OPTIONS_DECL string& arg() { static string* str=0; if (!str) { str = new string; *str = "arg"; } return *str; } >From line 79 (after making the change above), I changed the only use of arg to: std::string untyped_value::name() const { return arg(); } In file *details/value_semantic.hpp*: I changed the declaration of the variable arg to (line 13): BOOST_PROGRAM_OPTIONS_DECL std::string& arg(); After these changes, program_options links properly, and I was able to run the demo code. Please note that also the pre-compiled version of boost 1.35 for the vc9.0 compiler from http://www.boost-consulting.com/download/windows suffers from these problems: the program_options DLL is unlinkable due to unresolved references to m_default_line_length and arg. Cheerio, Evert van de Waal

1 0

Silent change in boost 1.36 alignment_of<> template with gcc 4.3
by Jon Biggar 12 Nov '08

12 Nov '08

In boost 1.36, boost::alignment_of<> was changed to use the builtin __alignof__() if gcc version was 4.3 or greater rather than using calculating alignement using: template <typename T> struct alignment_of_hack { char c; T t; alignment_of_hack(); }; Unfortunately, this broke some code I had written that did structure introspection, because gcc's __alignof__() returns 8 for double on the x86 architecture, but actually only aligns doubles on 4 byte boundaries inside structures. What do people think about adding a struct_alignment_of<> template that uses the old logic to compute alignment inside a struct? -- Jon Biggar jon(a)floorboard.com jon(a)biggar.org jonbiggar(a)gmail.com

6 12

[serialization] non-tracking wrapper?
by David Abrahams 12 Nov '08

12 Nov '08

I'm wondering if it's even possible to create a wrapper that turns off tracking for the type it wraps. Is tracking "scoped" so that subobjects of non-tracked types are also not tracked? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 6

[Graph] Some help in trying to fix the broken leda wrapper
by Sandeep Gupta 12 Nov '08

12 Nov '08

Hi, This is a repost and I hope this time it gets someone attention. I have spend some time trying to make the leda wrapper work with the new version of leda. I had some success with it. However finally i got stuck with this error that I couldn't make any sense of boost_1_36_0/boost/concept_ > > check.hpp:91: error: request for member > 'error_type_must_be_a_signed_integer_type' in > '((boost::SignedInteger<leda::edge_struct* > const*>*)this)->boost::SignedInteger<leda::edge_struct* const*>::x', which > is of non-class type 'leda::edge_struct* const*' It is instantiated from eventually from boost/concept_check.hpp: In destructor 'boost::SignedInteger<T>::~SignedInteger() [with T = leda::edge_struct* const*]': /home/san/ArtOfLearning/boost_1_36_0/boost/concept/detail/general.hpp:29: instantiated from 'static void boost::concept::requirement<Model>::failed() [with Model = boost::SignedInteger<leda::edge_struct* const*>]' It doesn't seems like a big problem. I am sure the original author of leda wrapper or anybody well versed with the internals can point me in the right direction. Thanks sandeep On Mon, Nov 3, 2008 at 10:41 PM, Sandeep Gupta <gupta.sandeep(a)gmail.com>wrote: > Hi, > Not sure how much interest is in leda wrapper of BGL. But the new version > of leda broke the leda wrapper. I have made some quick fixes. However i got > stuck at this error: > > boost_1_36_0/boost/concept_check.hpp:91: error: request for member > 'error_type_must_be_a_signed_integer_type' in > '((boost::SignedInteger<leda::edge_struct* > const*>*)this)->boost::SignedInteger<leda::edge_struct* const*>::x', which > is of non-class type 'leda::edge_struct* const*' > > Hopefully its the last one. After this technically the wrapper should > compile. I have briefly tested it with connecte components routines. > If there is interest i will happy to post the changes.. > > thanks > sandeep > >

3 4

llvm anyone?
by Neal Becker 12 Nov '08

12 Nov '08

Anyone testing on llvm compiler? (I'm trying it now on linux F9 x86_64 llvm-2.4)

2 1

Re: [boost] [Boost-users] [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st
by vicente.botet 12 Nov '08

12 Nov '08

----- Original Message ----- From: "Fabio Fracassi" <f.fracassi(a)gmx.net> To: <boost-users(a)lists.boost.org> Cc: <boost(a)lists.boost.org> Sent: Monday, November 10, 2008 11:30 AM Subject: Re: [Boost-users] [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st > I have a tendency to yes, because even now it is better than what we have > now (which is not saying that signals1 was bad!), on the other hand I > think that the missing documentation is crucial. I think that a mini review would ensure that the documentation is updated as we expect. Vicente

1 0

Fw: [Boost-users] [signals2][review] The review of the signals2library (formerly thread_safe_signals) begins today, Nov 1st
by vicente.botet 12 Nov '08

12 Nov '08

forwarding to boost(a)list.boost.org ----- Original Message ----- From: "Frank Mori Hess" <frank.hess(a)nist.gov> To: <boost-users(a)lists.boost.org> Sent: Monday, November 10, 2008 4:25 PM Subject: Re: [Boost-users] [signals2][review] The review of the signals2library (formerly thread_safe_signals) begins today, Nov 1st > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Monday 10 November 2008 05:30 am, Fabio Fracassi wrote: >> * Automatic connection management: >> This is great, even if it wasn't required for thread safety reasons, I >> prefer using shared_ptr based connection tracking over boost::trackable, >> since it enables me to track (and thus safely use) 3d party classes. > > One issue that has occurred to me with the shared_ptr use, is it requires > the > use of boost::shared_ptr. So, if someone's program is instead always > using > std::shared_ptr for example, that could be a bit of an annoyance. One > solution would be to make it support anything that provides the > shared_ptr/weak_ptr interface by making slotN::track() a template and > doing > some type erasure inside the library. Unfortunately, neither the > shared_ptr > or weak_ptr interface provides a typedef for it's associated > weak_ptr/shared_ptr type, and I would need to get both the weak_ptr and > shared_ptr type from the single argument passed to slotN::track(). So, > I'd > have to add some template traits classes that could determine if a class > is a > shared_ptr or weak_ptr, and the type of its associated weak_ptr or > shared_ptr. I could provide specializations of the traits classes for the > shared_ptr/weak_ptr implementations I know about (boost, std, tr1, etc), > otherwise the user would have to provide a specialization. > > The other option would be to add yet another template parameter to the > signal > class for the shared_ptr type, but it has too many parameters already. > >> I haven't done a comparison, but the Docu seems to be mostly the same as >> the original signals. Thus for the usecases that are documentated there >> its high quality, but I miss the same for the new features: >> >> * I miss tutorial quality examples for some of the new features: >> ** Howto use boost::threads with signals2 >> ** Howto use postconstructors/predestructors (and what for?) >> ** An example using signal::extended_slot_type > > Yes, it seems clear I'm not going to get away with the minimal porting job > I > did on the Boost.Signals documentation. Speaking of the postconstructor > stuff, I'm not entirely happy with the deconstruct_ptr interface. Maybe > I'd > like it better if it looked more like make_shared/allocate_shared and had > a > helper for declaring it as a friend, as has been recently proposed on > boost-devel for make/allocate_shared. > >> * The class reference pages (e.g. >> doc/html/boost/signals2/connection.html) are missing from the TOC > > That's just how boostbook does it. The TOC links to the header synopsis, > and > the class names in the header synopsis link to the class reference pages. > I > do remember having a little trouble navigating through it myself initially > though. > >> * Do the portable syntax examples need to be supported (... so >> prominently)? Maybe they could be moved to an appendix? > > I agree they don't, although most of the other additions to the docs > people > have been asking for would seem to take precedence. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFJGFJu5vihyNWuA4URAsUpAJ0TVggC9K9Zy76p1AxtfnxA1VomsgCeL1Z8 > TrXkG8+WbKkBDS7SiUF+0+Y= > =zb8l > -----END PGP SIGNATURE----- > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

1 0