From: Ed Brey (edbrey_at_[hidden])
Date: 2001-08-20 08:29:33
From: "Daryle Walker" <darylew_at_[hidden]>
> on 8/17/01 8:58 AM, Ed Brey at edbrey_at_[hidden] wrote:
> > I just took a look at your update in the files section (version 11). I
> > still have a couple concerns. One problem is the existence of two
> > first-class interfaces, one a set of classes of the form
> > base_from_member_n and the other the class base_from_member. To be
> > minimal and complete the former interface should be dropped. The only
> > exception is that if there are still a significant number of compilers
> > still around that chock on the latter. Do you know of any (even MSVC6
> > works here!)? I think this would have to be pretty major before we should
> > allow expanding the interface (only to have to deprecated, but still
> > maintain, it later) to appease them, since the obvious workaround of just
> > implementing the pattern by hand is quite reasonable.
> Looking at <boost/config.hpp>, the BOOST_NO_MEMBER_TEMPLATES macro is
> defined for GCC <= 2.08, Sunpro <= 5.0, and MSVC++ <= 6.
For MSVC, this would be a good place to make use of BOOST_MSVC6_MEMBER_TEMPLATES, since this usage of member templates doesn't appear to break it. The other two compilers are old, so there are no compatibility reasons to use the multi-class interface.
> The one-constructor template classes let the developer specify the exact
> type of the constructor argument(s). The multi-constructor template class
> cannot; it depends exclusively on argument lookup. Could a compiler screw
> up argument type guessing, especially for references and/or arrays?
The compiler will just pick up the type of the argument that is being passed by the caller. If the caller wants something different, he can just do a static_cast. Given that this is rare, such a case is more convenient than having to specify the constructor signature for each argument, whether needed or not.
Actually, what really needs to be done is for base_from_member to use type traits so that arguments are copied by reference when appropriate.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk