March 2005 - Boost - lists.preview.boost.org

Singleton is documented!
by Jason Hise 04 Mar '05

04 Mar '05

The singleton library is finally documented! A complete tutorial in using the library along with an extensive reference section are provided. A tutorial on extending the library is forth-coming. The new zip is available in the <a href="http://boost-sandbox.sourceforge.net/vault/">sandbox</a> under the singleton folder, and should be extracted into the boost root directory. As always, suggestions are welcome. -Jason

6 17

Looking for some WINDOWS help
by Jody Hagins 04 Mar '05

04 Mar '05

Whenever I get a spare moment, I try to get my typeid/type_info tests working on windows (I am convinced that if I had started programming under that environment, I would have chosen a different line of work). Right now I am struggling a bit with the DLL library that is part of testing type_info. Everything works fine, except when it doesn't ;-> The documentation of LoadLibrary() says it returns NULL on failure. However, I can feed it some files (like a valid .LIB that is not a DLL) and before LoadLibrary() returns, it displays a dialog box saying "Bad Image." I guess this could be an exception that BCB is intercepting and turning into a dialog box, but the docs say nothing about an exception. Also, I look on google, and find that people have similar problems from within Java (though I could not find any solutions). How do I prevent that from happening? Thanks in advance!

2 1

Re: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE
by JOAQUIN LOPEZ MU?Z 04 Mar '05

04 Mar '05

----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Viernes, Marzo 4, 2005 0:32 am Asunto: Re: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE > Jonathan Turkanis wrote: > > Hi, > > > > <boost/shared_ptr.hpp> contains the following in the public section > > of the class definition (reformatted): > > > > // Tasteless as this may seem, making all members public > > // allows member templates to work in the absence of member > > // template friends. (Matthew Langston) > > > > #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS > > > > private: > > > > template<class Y> friend class shared_ptr; > > template<class Y> friend class weak_ptr; > > > > > > #endif > > > > T * px; // contained pointer > > detail::shared_count pn; // reference counter > > > > This has become a pretty common technique, I believe. I > certainly use > > it a lot, at any rate. > > > > I'd like to suggest two macros which would allow code like the above > > to be simplified as follows: > > > > BOOST_PRIVATE: > > BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) > > BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) > > > > T * px; // contained pointer > > detail::shared_count pn; // reference counter > > This doesn't look any better to me than the original, sorry. ;-) Well, I think there are situations were it'd improve readability: Example 1: previous section was not public #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private: template<class Y> friend class shared_ptr; template<class Y> friend class weak_ptr; #else public: #endif Example 2: derivation class Derived: #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private else public #endif Base { ... }; Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[mpl-docs] portability trap
by Tobias Schwinger 04 Mar '05

04 Mar '05

Hi, This code: #include <boost/mpl/vector.hpp> #include <boost/mpl/pop_front.hpp> #include <boost/mpl/assert.hpp> #include <boost/mpl/equal.hpp> using namespace boost; // Doc says: pop_front returns a vector typedef mpl::pop_front< mpl::vector<bool,char,int> >::type v; // Doc says: vectors have a type member equal to itself BOOST_MPL_ASSERT(( mpl::equal< v, v::type > )); fails to compile with GCC ( v::type is mpl::vector3<bool,char,int> ) and compiles fine with other compilers. Examples for false conclusions that could be easily drawn from the current documentation: "Oh great - I do not need mpl::identity when using v with mpl::eval_if" "Let's inherit from 'v::type' so I can save the '::type' later" "::type always gives the numbered form of my current sequence so I can use it with partial specialization" I got trapped by this in two different places (and I still hope not to be surpassingly stupid ;-). Shouldn't this behaviour be documented in some way ? Regards, Tobias

2 2

Re: [boost] Looking for some WINDOWS help
by JOAQUIN LOPEZ MU?Z 04 Mar '05

04 Mar '05

----- Mensaje original ----- De: Jody Hagins <jody-boost-011304(a)atdesk.com> Fecha: Viernes, Marzo 4, 2005 0:37 am Asunto: [boost] Looking for some WINDOWS help > > Whenever I get a spare moment, I try to get my typeid/type_info tests > working on windows (I am convinced that if I had started programming > under that environment, I would have chosen a different line of > work). > Right now I am struggling a bit with the DLL library that is part of > testing type_info. Everything works fine, except when it doesn't > ;-> > > The documentation of LoadLibrary() says it returns NULL on > failure. > However, I can feed it some files (like a valid .LIB that is not a > DLL)and before LoadLibrary() returns, it displays a dialog box > saying "Bad > Image." I guess this could be an exception that BCB is > intercepting and > turning into a dialog box, but the docs say nothing about an > exception. > Also, I look on google, and find that people have similar problems > fromwithin Java (though I could not find any solutions). > > How do I prevent that from happening? > With SetErrorMode, I think. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] Re: [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE
by JOAQUIN LOPEZ MU?Z 04 Mar '05

04 Mar '05

Hi Jonathan! ----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Viernes, Marzo 4, 2005 0:08 am Asunto: [boost] Re: [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE > JOAQUIN LOPEZ MU?Z wrote: [...] > > The macros I'm using are: > > > BOOST_PRIVATE_IF_MEMBER_TEMPLATE_FRIENDS > > BOOST_PROTECTED_IF_MEMBER_TEMPLATE_FRIENDS > > These would be okay with me. But sometimes I use a macro for > specifying the type > of derivation, and > > struct derived_class > : BOOST_PRIVATE_IF_MEMBER_TEMPLATE_FRIENDS base_class > { }; > > seems a bit long. Yep it is long, but BOOST_PRIVATE covers too much semantic scape: what if in the future a similar workaround is needed to make up for another, unrelated defficiency? This is not hypothetical, in fact I'm already using BOOST_MULTI_INDEX_PRIVATE_IF_USING_DECL_FOR_TEMPL_FUNCTIONS that does the same thing (turning private into public) in some compilers that do not support in-class using declarations for template functions. Admittedly, it'd be nicer if we can come up with a shorter, yet descriptive name. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo PS: OT: Jonathan, weren't you going to promote a scopeguard impl to boost/detail? I'm waiting for that so that I can reduce my own codebase :)

2 1

[congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE [repost]
by Jonathan Turkanis 03 Mar '05

03 Mar '05

[I'm reposting this because I misspelled 'config' in the subject line] Hi, <boost/shared_ptr.hpp> contains the following in the public section of the class definition (reformatted): // Tasteless as this may seem, making all members public // allows member templates to work in the absence of member // template friends. (Matthew Langston) #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private: template<class Y> friend class shared_ptr; template<class Y> friend class weak_ptr; #endif T * px; // contained pointer detail::shared_count pn; // reference counter This has become a pretty common technique, I believe. I certainly use it a lot, at any rate. I'd like to suggest two macros which would allow code like the above to be simplified as follows: BOOST_PRIVATE: BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) T * px; // contained pointer detail::shared_count pn; // reference counter Here BOOST_PRIVATE would expand to "private" for compilers that support template friends and to "public" otherwise; BOOST_BEFRIEND_TEMPLATE would expand to a template friend declaration where supported, and to nothing otherwise. It might be desirable to have two macros BOOST_BEFRIEND_TEMPLATE_CLASS and BOOST_BEFRIEND_TEMPLATE_STRUCT to avoid compiler warnings. Jonathan

1 1

[config] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE [repost][repost]
by Jonathan Turkanis 03 Mar '05

03 Mar '05

Hi, <boost/shared_ptr.hpp> contains the following in the public section of the class definition (reformatted): // Tasteless as this may seem, making all members public // allows member templates to work in the absence of member // template friends. (Matthew Langston) #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private: template<class Y> friend class shared_ptr; template<class Y> friend class weak_ptr; #endif T * px; // contained pointer detail::shared_count pn; // reference counter This has become a pretty common technique, I believe. I certainly use it a lot, at any rate. I'd like to suggest two macros which would allow code like the above to be simplified as follows: BOOST_PRIVATE: BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) T * px; // contained pointer detail::shared_count pn; // reference counter Here BOOST_PRIVATE would expand to "private" for compilers that support template friends and to "public" otherwise; BOOST_BEFRIEND_TEMPLATE would expand to a template friend declaration where supported, and to nothing otherwise. It might be desirable to have two macros BOOST_BEFRIEND_TEMPLATE_CLASS and BOOST_BEFRIEND_TEMPLATE_STRUCT to avoid compiler warnings. Jonathan

1 0

Re: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE
by JOAQUIN LOPEZ MU?Z 03 Mar '05

03 Mar '05

----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Jueves, Marzo 3, 2005 9:49 pm Asunto: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE > Hi, > > <boost/shared_ptr.hpp> contains the following in the public > section of the class > definition (reformatted): > > // Tasteless as this may seem, making all members public > // allows member templates to work in the absence of member > // template friends. (Matthew Langston) > > #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS > > private: > > template<class Y> friend class shared_ptr; > template<class Y> friend class weak_ptr; > > > #endif > > T * px; // contained pointer > detail::shared_count pn; // reference counter > > This has become a pretty common technique, I believe. I certainly > use it a lot, > at any rate. FWIW, I've also been forced to use a similar workaround. > > I'd like to suggest two macros which would allow code like the > above to be > simplified as follows: > > BOOST_PRIVATE: > BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) > BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) > > T * px; // contained pointer > detail::shared_count pn; // reference counter > BOOST_PRIVATE seems a little to uninformative a name to me. The macros I'm using are: BOOST_PRIVATE_IF_MEMBER_TEMPLATE_FRIENDS BOOST_PROTECTED_IF_MEMBER_TEMPLATE_FRIENDS (well, I'm using lib-specific variations of these names, but you get the idea.) As for your proposal, I like it: there are at least three libraries that would benefit from it. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] Re: RPC library
by Iain Hanson 03 Mar '05

03 Mar '05

On Thu, 2005-03-03 at 13:54 +0000, Jarl Lindrud wrote: > Iain Hanson <Iain.Hanson <at> videonetworks.com> writes: > > > > > So anything less than CORBA should not be considered? For RPC, Yes. > > My experience with CORBA is that you _do_ pay for things you don't need. Try > building a simple server/client app with my RPC library, and then build it with > ACE TAO, and I wonder which method you'll find to be simpler/easier/faster... Here is an example CORBA client. And it doen not matter which ORB you use. #include <iostream> #include "echoC.hpp" // generated from the idl file int main ( int ArgV , char * ArgV ) { try { // _var types are smart ptrs to ref counted objects. CORBA::ORB_var Orb = CORBA::ORB_init ( ArgC , ArgV , "TAO"); // get IOR from a file so we can talk to server CORBA::Object_var Factory_Object = Orb->string_to_object ( ArgV [ 1 ] ); // This is a CORBA safe downcast My::Echo_Factory_var Factory = My::Echo_Factory::_narrow ( Factory_Object.in( ) ); My::Echo_Server_var EchoServer = Factory->get_server ( ArgV [ 2 ] ); CORBA::String_var Echoed = EchoServer-> ( "Hello World" ); } catch ( CORBA::Exception & E ) { std::cerr << "CORBA exception raised!" << std::endl; } } I don't think 5 lines of code is exactly heavyweight. I could of done it in 3 lines if I did not use a factory, but that would have been unrealistic. I won't show the server but it 2 classes the factory publicly inherits from Echo_Factory and implements a single function get_server. Likewise like for EchoServer. > Which code is less invasive, more intuitive, and more proportional to the task? > And oh I forgot, don't forget to first build all of ACE and TAO, and then link > the whole shebang to your own 5 lines of code. To me it feels like I'm getting > far, far more than I asked for. But that's just me :-) ACE is nothing to do with CORBA. It just happens to be what TAO uses internally. Building Open source or installing per build libs has nothing to do with how easy it is to use. Your comparing apples and carrots. >If you need scaleability, then obviously CORBA is one of the few >options you have. But if you don't need scaleability, or naming >services, or whatever, what's wrong with using something much simpler? Because when you app grows you will have to re-write it. More likely, is that won't happen and people will re-invent the again. Take a look at the development of SOAP :-(. /ikh

2 1