- Boost - lists.boost.org

[serialization] problem with boost/serialization/is_abstract.hpp
by Joaquín Mª López Muñoz 05 Nov '04

05 Nov '04

In MSVC 6.0, the following snippet fails: #include <boost/archive/text_iarchive.hpp> #include <boost/tuple/tuple.hpp> int main() { return 0; } complaining about is_abstract being already defined. The problem lies in the following lines inside boost/serialization/is_abstract.hpp: #ifndef BOOST_TT_IS_ABSTRACT_CLASS_HPP #if defined(__GNUC__) && (34 <= _GNUC__ * 10 + __GNU_MINOR) \ || defined(__MSVC_VER) && (1310 <= __MSVC_VER) \ || defined(__EDG_VERSION__) \ /**/ #include <boost/type_traits/is_abstract.hpp> #else // default to false if not supported namespace boost { template<class T> struct is_abstract { typedef mpl::bool_<false> type; BOOST_STATIC_CONSTANT(bool, value = is_abstract::type::value); }; } // namespace boost #endif #endif // BOOST_TT_IS_ABSTRACT_CLASS_HPP The code is *incorrectly* using __MSVC_VER where it should use _MSVC_VER (just one leading underscore). Thus boost::is_abstract is defined twice, as boost/type_traits.hpp is implicitly included by boost/tupe/tuple.hpp If nobody complains, I can fix this and commit it to the release and main branch. What worries me, though, is that the code above seems flawed to me (apart from the minor typo). What happens if the compiler is not one of those taken care of explicitly in boost/serialization/is_abstract.hpp? Could anyone please test the first snippet in some compiler other than MSVC, ICC for Windows, GCC or an EDG-based compiler? My thesis is that it will fail. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

7 7

Serialization support for mersenne_twister
by Neal D. Becker 05 Nov '04

05 Nov '04

I know I've mentioned this before. I'd really like to see this tiny bit of code added to mersenne_twister: template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & x; ar & i; } This would make it very easy to use our new serialization library with mersenne_twister. It costs nothing if you don't use it. If you are really paranoid, it could be surrounded by an #ifdef.

3 2

[spirit] select_p problem
by Vyacheslav E. Andrejev 05 Nov '04

05 Nov '04

Hi All, boost::spirit::select_p parser can not be compiled with boost::spirit::rule as argument. The problem is that metafunction boost::spirit::impl::as_embedded_parser<ParserT> returns const reference to boost::spirit::rule, not boost::spirit::rule itself, when PaerserT = boost::spirit::rule. So trying to compile parser_result<as_embedded_parser<rule<> > > deep inside the select_p implementation generates error message that const rule<>& has no result_type. I suggest to change parser_result definition as following: template <typename ParserT, typename ScannerT> struct parser_result { typedef typename boost::remove_reference<ParserT>::type::template result<ScannerT>::type type; }; -- ______________________________ Vyacheslav E. Andrejev System Architect, Excelsior, LLC

2 1

Contacting Chuck Allison [if you don't know how to contact Chuck Allison ignore]
by Vesa Karvonen 04 Nov '04

04 Nov '04

Hi, I would like to query whether The C++ Source (http://www.artima.com/cppsource/index.jsp) would be interested in publishing an article on Lazy Template Metaprogramming. I tried e-mailing the ChuckAllison(a)mailblocks.com -address, but haven't received any response in about 24-hours. So, if you know how to contact Chuck Allison, please forward this message to him. Regards, Vesa Karvonen _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/

2 1

RE: [boost] [Boost-bugs] [ boost-Bugs-1059388 ] shared_ptr::operator->() const return type should be const
by Eyal Farago 04 Nov '04

04 Nov '04

I think you're wront about this, shared_ptr should behave just like a pointer (in this aspect). it really doesn't matter if the pointer is const or not, what matters is the constness of the pointee. typedef int* pint_t; const pint_t p = new int(1); //p is const(same as int * const) int &ref_to_int = *p; //but *p isn't eyal. -----Original Message----- From: SourceForge.net [mailto:noreply@sourceforge.net] Sent: Wednesday, November 03, 2004 12:29 PM To: noreply(a)sourceforge.net Subject: [boost] [Boost-bugs] [ boost-Bugs-1059388 ] shared_ptr::operator->() const return type should be const Bugs item #1059388, was opened at 2004-11-03 13:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1059388&group_… Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roland (vzaznobin) Assigned to: Peter Dimov (pdimov) Summary: shared_ptr::operator-> () const return type should be const Initial Comment: shared_ptr::operator-> () const return type should be const const T * operator-> () const; T * operator-> (); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1059388&group_… ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: [boost] [serialization] problemwithboost/serialization/is_abstract.hpp
by JOAQUIN LOPEZ MU?Z 04 Nov '04

04 Nov '04

----- Mensaje original ----- De: Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> Fecha: Jueves, Noviembre 4, 2004 7:58 pm Asunto: Re: [boost] [serialization] problemwithboost/serialization/is_abstract.hpp > Joaquín Mª López Muñoz writes: > > In MSVC 6.0, the following snippet fails: > > > > #include <boost/archive/text_iarchive.hpp> > > #include <boost/tuple/tuple.hpp> > [...] > > complaining about is_abstract being already defined. The problem > > lies in the following lines inside > boost/serialization/is_abstract.hpp:> > > #ifndef BOOST_TT_IS_ABSTRACT_CLASS_HPP > > #if defined(__GNUC__) && (34 <= _GNUC__ * 10 + __GNU_MINOR) \ > > || defined(__MSVC_VER) && (1310 <= __MSVC_VER) \ > > || defined(__EDG_VERSION__) \ > > /**/ > > #include <boost/type_traits/is_abstract.hpp> > > #else > > First of all, the whole thing is a huge hack and can cause an ODR > violation on 1-2-3. We should really fix type_traits to fall back to > something like the code below, but that is definitely out for the > release. Yep, I'll take care of this as soon as Boost 1.32 is out -I need it for my own purposes :) > > Having said that, the #else branch is simply missing this: > > # define BOOST_TT_IS_ABSTRACT_CLASS_HPP > [...] > > If nobody complains, I can fix this and commit it to the release and > > main branch. > > Please! Together with the #define, if you can. Consider it done in approx. 12 hours from now. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

small library proposal -- rebind template args and function pointer types
by James Harris 04 Nov '04

04 Nov '04

Hello Boost Members, I have written a small library of meta-functions that allow rebinding of template arguments and function pointer return/argument types. I am posting in an attempt to guage interest and hopefully receive pointers on the library proposal process. The library provides the following meta-functions: rebind<int index, class rebind_type, class source_type> -- rebind template arguments rebind_func_arg<int index, class rebind_type, class func_type> -- rebind argument type of func/method ptr rebind_func_return<class rebind_type, class func_type> -- rebind return type of func/method ptr rebind_method_class<class rebind_type, class func_type> -- rebind class portion of method ptr // --- rebind<> example ------------------------------------------------ template <class A, class B, class C> class foo { }; typedef foo<int, int, int> source_type; typedef rebind<1, char, source_type>::type rebound_type; // rebound_type equates to foo<int, char, int> // --- rebind_func_arg<> example --------------------------------------- typedef int (*func_ptr)(int); typedef rebind_func_arg<0, char, func_ptr>::type rebound_type // rebound_type equates to int (*)(char) // rebind_func_args also works with pointer-to-method types // --- rebind_func_return<> example ------------------------------------ typedef int (*func_ptr)(int); typedef rebind_func_return<char, func_ptr>::type rebound_type // rebound_type equates to char (*)(int) // rebind_func_return also works with pointer-to-method types // --- rebind_method_class<class rebind_type, class func_type> --------- typedef int (foo::*method_ptr)(int); typedef rebind_method_class<bar, method_ptr>::type rebound_type; // rebound_type equates to int (bar::*)(int); -- end examples -- I have tested the code using MSVC 7.1 and GCC 3.3.2-1. Please let me know if this library would be useful to any of you, or otherwise any reason why it is not required or, of course any tips/suggestions/questions that you might have. Kind Regards, James Harris.

4 3

Documentation Bug
by Joshua Berne 04 Nov '04

04 Nov '04

Quick bug in the documentation links for "www.boost.org"'s "Nightly CVS" link. All the library links that don't link to pages under docs/html are broken, since the directory http://www.boost.org/regression-logs/cs-win32_metacomm/ seems to contain only the doc directory, and not the full distribution. (The same aspect of the lib links, that they link to ../../libs/... outside of the doc/html dir, is also breaking the "put a symbolic link to docs/html in my home dir" approach to viewing the boost documentation.. but i'm not sure that's a behaviour anyone endorses.) Hope this helps. - Josh

1 0

surprising accessability of free locking functions for mutex
by Roland Schwarz 04 Nov '04

04 Nov '04

Having followed the discussion about the availability of direct locking of mutexes, I am somewhat surprised that there are free functions available for this purpose. Is this by intent? Is using them simply bad practice? I.e.: boost::mutex m1; boost::detail::thread::lock_ops<boost::mutex>::lock(&m1); is e legal statement. (And indeed is locking the mutex.) Yes I've seen the "detail". Does this imply: Anything that is detail definitely should not go into user programs? I am asking this not for pure 'academic' reasons. What I am trying to do is to find out whether it is possible to write a small wrapper over the existing classes to support a kind of cancellability for my threads, until the "real thing" will be available. Thank you. Roland

2 1

RE: [boost] recursive mutex and condition
by Ben Hutchings 04 Nov '04

04 Nov '04

James Ahlborn <james.ahlborn(a)med.ge.com> wrote: > hey, > I was wondering if any of the boost developers could tell me > if recursive mutexes are supposed to work with conditions? I don't believe so. If waiting for a condition releases the mutex only once, this can result in deadlock, and if it releases the mutex completely the protected data can be seen while its invariant is broken. There seems to be no right way to use recursive mutexes with condition variables. <snip> > I'm testing this on red hat 7.3 and fedora core 2. My guess as to > why it's broken is because the boost condition uses posix recursive > mutexes There's no such thing. > internally, which also seem to fail the recursive mutex/condition > test (at least on the OS's mentioned above). Anyone have any > thoughts on this? <snip> I think you should avoid using recursive mutexes. Read <http://groups.google.com/groups?selm=3434E6BA.ABD%40zko.dec.com>. Ben.

4 4