----- Original Message ----- From: "Rob Stewart" <stewart@sig.com> Greetings Rob, my apologies for being hotheaded earlier. To: <boost@lists.boost.org> Cc: <boost@lists.boost.org> Sent: Monday, May 24, 2004 5:29 PM Subject: Re: [boost] Ranged type mini-library submission
From: christopher diggins <cdiggins@videotron.ca>
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