Boost logo

Boost :

From: Eric Friedman (ebf_at_[hidden])
Date: 2003-11-12 18:33:10

Andy Little wrote:
> Hi
> The metafunction naming style that instantly came to mind for me
> and honestly thought was in use ( as a newbie to MPL) was to add a '_t'
> to the name, hence
> MyWidget_t<X,Y,Z>::type;

This is not the convention used by MPL.

> the precedent for this is the "wchar_t", "time_t","clock_t" etc types.

These types you cite as 'precedent' are not metafunctions. They are
regular types. That is, you *never* write:


> Its also much shorter to type and the suffix reflects the position of the
> ::type in the useage.
> The user feels a natural urge to 'fill in' the "_t" with a "::type".
> of course you could do more typing, but redundant typing is redundant :-)
> MyWidget_type<X,Y,Z>::type;

I don't see how either the name MyWidget_t or MyWidget_type suggests to
the user a metafunction (i.e., that a trailing ::type is required). As I
wrote in my previous post, I believe this is because they are nouns.

A noun suggests a completed state, whereas what needs to be conveyed is
a transformation (i.e., a function from one type to another).

> (steering clear of the name metafunction as I may be using incorrectly )

I think you may be.

> with the metawidget returning a value the obvious choice is "_v"
> MyWidget_v<X,Y,Z>::value;

I don't think this is obvious. I don't even think I've seen it before.

> this extends the "wchar_t" precedent of course to fit the MPL world

Again, I think you're off with your 'precedent' here. Further, adding a
trailing _v is not an MPL convention.

> As a newbie to metafunctions I find the "make_x" style odd. I dont want to
> "make" anything.

Yes, you do. You want to make a recursive variant type. As I said,
though, I'm not committed to "make"; I just haven't seen another verb
that's better.

> That suggests run time hence "weak" from an MPL point of view. Hopefully as
> a user by the time I use it it has already been "made"
> I see MPL types as "hard immutable" things "metamorphed", "ground from"
> ,"chiselled f rom" my arguments at compile time,
> unlike the weak and wibbly wobbly entities of runtime.

I think the trailing ::type is a good indicator that there is no runtime
behavior here.

> Apologies for wading in... but I feel much better with that off my chest :-)

No problem, but what I'm aiming for is to choose a name that is most
likely to prevent misuse that is difficult to identify. I'd argue even
an ambiguous name is better than one that is falsely unambiguous: the
the former will quickly send the user to the documentation; the latter
will leave the user confused.

So again: "I plan to leave the names as make_recursive_variant, etc.
unless someone proposes another verb phrase that is better."


Boost list run by bdawes at, gregod at, cpdaniel at, john at