From: christopher diggins (cdiggins_at_[hidden])
Date: 2004-05-18 08:59:05
----- Original Message -----
From: "Jeff Garland" <jeff_at_[hidden]>
Sent: Tuesday, May 18, 2004 9:24 AM
Subject: Re: [boost] Ranged type mini-library submission
> On Tue, 18 May 2004 00:17:40 -0400, christopher diggins wrote
> > I detect some frustration, I mean you no disrespect, I hold your
> > work and comments in very high esteem.
> No frustration, sorry it transmitted that way. Your statement was very
> broad, and implied that there are 'many problems' inheriting a template
I should not have made such a sweeping statement.
> And yet I see it done sucessfully all the time in modern C++.
It definitely is a powerful technique that I have used often. I am very
hesitant about using it in libraries destined for public consumption when
there exist alternatives which are more intuitive for naive programmers.
> Since I'm basically unaware of 'problems' with this approach your
> hit me much like the ever recurring programming guildeline: "Don't use
> multiple inheritance because it might create problems". Complete bunk
> needs to be corrected...
> > I just changed the code by removing the public constraints typedef
> > and adding a static function get_constraints() so that it can be
> > invoked using instances of an object as well.
> Well, ok, but I still don't like it.
I respect that, but my concern in this instance is whether Joe Average
programmer will like it and understand it quickly.
> > The problem with parameter inheritance, as least in this case, is
> > that it surprises programmers by causing an object to have an
> > interface.
> This is really a matter of documentation. If I get used to calling
> to find the max then I'm going to use my handy code editor to propagate
> code around. As soon as I hit mytype2 that doesn't have constraints with
> max function I'll be just as stumped as if mytype2::max didn't compile.
> I start looking at the docs and code to figure out what went wrong. But
> I shouldn't expect a type with a name like 'divisible_by_four' to
> have a min/max interface.
I don't doubt that someone of your level of expertise would figure things
out quickly, but my concern is with the lowest common denominator of
experience. We are writing a library for the public, not for ourselves.
> > Most programmers when confronted with code such as
> > mytype::max() expect that max will be available for all instances of
> > mytype.
> I assume here mytype refers to the constrained_value template? Because
> given user type generated from this template mytype::max will be available
> all instances.
I stand corrected, I should have said all parameterizations.
> > On the other hand, mytype::get_constraints().max() is
> > generally understood to not always be readily available in a
> > parameterized type.
> Really? Let's say I've never seen the documentation for constrained_value
> I'm just reading some code I didn't write. For me, I have to think for an
> extra nano-second ( little joke :) about the meaning of this code:
> I'm thinking let's see, a static function that returns an object with a
> function. As opposed to just -- yeah, get the max.
> > I don't see how the advantage of the shorthand justifies the case for
> > parameter inheritance here.
> I'll turn it around the other way -- I don't see how the 'longhand' makes
> interface any clearer. The interface still needs a description the user
> understand. In any highly flexible template design this is always more
An interface, as I am using the term here, is the set of public functions
and public fields. An inteface for a parameterized type is generally
understood to have functions or fields whose type is variant on a parameter.
It is not generally understood or assumed that functions may or may not
exist in a parameterized type.
> One last point. By inheriting from the policy, we can both have our way.
> can specilize your constraint policy to have a public method
> that returns an object and I can have my min/max. Now that's power ;-)
Your technique is most definitely more powerful but I am still concerned for
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk