Re: [boost] Ranged type mini-library submission

From: christopher diggins (cdiggins_at_[hidden])
Date: 2004-05-25 22:24:38

----- Original Message ----- 
From: "Rob Stewart" <stewart_at_[hidden]>

Greetings Rob, my apologies for being hotheaded earlier.

To: <boost_at_[hidden]>
Cc: <boost_at_[hidden]>
Sent: Monday, May 24, 2004 5:29 PM
Subject: Re: [boost] Ranged type mini-library submission

> From: christopher diggins <cdiggins_at_[hidden]>
> >
> >     template
> >     <
> >       class constraints_policy,
>               ^^^^^^^^^^^^^^^^^^
> I think the usual naming convention would make that
> "Constraints" or something similar.

I prefer the _policy extension as I feel it adds to the documentation and
has no penalty to the user is never required to be typed. But I am open to
the possibility of changing it if there are strong feelings one way or
another.

> >       bool implicit_conversion_policy = true
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^
> ditto: "ImplicitConversion"
>
> >     >
> >     class constrained_value {
> >       private:
> >         struct unused_struct { };
>
> Why the "_struct" suffix?  Wouldn't "unused" suffice?

Just trying to be as clear as possible. I do have a tendency to be overly
verbose, so I would appreciate hearing how strongly you or others feel about
that.

> >       public:
> >         typedef constrained_value<constraints_policy,
> > implicit_conversion_policy> self;
> >         typedef typename constraints_policy::value value;
> >         typedef typename mpl::if_c<implicit_conversion_policy, value,
> > unused_struct>::type value_parameter;
>
>           typedef Constraints constraints_policy;
>           typedef ImplicitConversion conversion_policy;
>
> >         static constraints_policy get_constraints() { return
> > constraints_policy(); }
> >         constrained_value() { }
> >         constrained_value(const self& x) { assign(x.get_value()); }
> >         constrained_value(value_parameter x) { assign(x); }
>
> What if the type is not a built-in?  That is, what if copying is
> expensive?

I did not anticipate this secnario. I imagined the type only used with small
value types. This is somewhat implied by the name constrained_value. This is
perhaps an oversight on my part. Would you be able to give a concrete
example of a type with more expensive copy semantics which would be an
appropriate contender? I am not being argumentitive, but simply cautious.

> Use TypeTraits to determine whether to pass by value
> or by reference.

How specifically would be the best way to accomplish that? I am not
sufficiently familiar with the technique of using TypeTraits in this manner.

> >         const value get_value() const { return m; }
> >         operator value() { return m; }
>
> Why return by value?  Why not const reference?  Even better, use
> TypeTraits to determine whether to return by value or by
> reference.

You are correct that I should be at least using const reference at this
point. I have just made the changes to const references where appropriate.
If I can envision an appropriate scenario for using TypeTraits that
justifies the increased complexity then I could be easily swayed on this
point.

> >         self& operator=(const self& x) { assign(x.get_value()); return
> > *this; }
> >         self& operator=(value_parameter x) { assign(x); return *this; }
>
> Use TypeTraits here, too.
>
> >         void assign(unused_struct x) { }
> >         void assign(value_parameter x) { constraints_policy::assign(x,
m); }
>
> And here.
>
> Also, it you've shown the arguments in the reverse order from
> what I'd expect.  The assignment operator puts the destination on
> the left, so I'd expect m on the left.

Thank you for pointing that convention out to me.

> >       private:
> >         value m;
> >     };

Thank you very much for the helpful feedback and suggestions. And again my
apologies for having been belligerent before.

Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com