Re: [Boost-users] [fusion] .at<N>() template member in containers?

Subject: Re: [Boost-users] [fusion] .at<N>() template member in containers?
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-10-08 22:28:04

On Fri, Oct 8, 2010 at 7:23 AM, Frank Mori Hess <frank.hess_at_[hidden]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thursday 07 October 2010, OvermindDL1 wrote:
>> To be frank, you should *never* have any function be a member function
>> unless it absolutely cannot be created externally, you will have
>> better compile times, better encapsulation,
>
> In the case he's talking about (similar to Boost.Tuple get()), a template
> parameter has to be specified for the function, which means ADL won't work,
> so you have to fully qualify a free function call (or use "using"). Â What's
> less annoying to use?
>
> boost::tuples::tuple tup;
>
> tup.get<1>();
>
> or
>
> boost::tuples::get<1>(tup);
>
>> and it prevents you from
>> doing nice things like the above.
>
> And of course, adding a member function doesn't prevent anything, it's not an
> either-or question. Â For example, having member swap() methods doesn't
> prevent a free-function swap() from existing.

But using a function where you pass in, say, a fusion container, but
the function calls a member function on it, but you pass an adapted,
say, boost::array or some other custom type that was adapted to a
fusion container, will fail to compile.  Not putting member functions
like that in the first place prevents someone from making that
mistake.