 |
C++Talk.NET C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
wkaras@yahoo.com Guest
|
Posted: Sun Aug 21, 2005 4:52 pm Post subject: proposal for template type parameter constraint |
|
|
I would like to propose the following changes to the C++ Standard,
the goal of which are to provide an improved ability to specify
the constraints on type parameters to templates. Let me say from
the start that my knowledge of compiler implementation is very
limited. Therefore, my suggestions may have to be rejected
because they are difficult or impossible to implement.
The proposal is based on the concept of "type similarity". Type
A is said to be similar to type B if any usage of B is a valid
usage of A, and any usage of an instance of B is also a valid
usage of an instance of A. I suggest that the language be
amended to allow type parameters to templates to be required
to be similar to a previously declared class. The proposed
new syntax is show in this example:
template <typename A ~ class B>
class X
{
...
};
Class B must have been declared, but it may or may not be
completely defined in the program.
One obvious shortcoming of this idea is illustrated by
the template:
template <typename A>
class X
{
public:
static int foobar(A &a)
{ return(a.foo(a.bar())); }
};
A constraint on A is that A::bar() must return the same
type as the parameter to A::foo(). But requiring A to
be similar to a specific type would "over-constrain"
A::bar() to return and A::foo() to receive a specific
type. Therefore, I also propose that type parameters
can be constrained to be similar to class templates,
as illustrated by this example:
template <typename T>
class B
{
private:
B();
public:
T bar();
int foo(T t);
};
template <typename A ~ template
class X
{
public:
static int foobar(A &a)
{ return(a.foo(a.bar())); }
};
A type A is similar to a class template B if there is
an instantiation of B to which A is similar.
It would also be useful if the "implied" parameters
to the contraining template could be used in the
body of the template being declared, allowing
for something like:
template <typename T, typename R>
class B
{
private:
B();
public:
T bar();
R foo(T t);
};
template <
typename A ~ template
class X
{
public:
// Return value of foobar is the same as the return value of
// A::foo(), whatever that may be.
static R foobar(A &a)
{ return(a.foo(a.bar())); }
};
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
 |
Greg Guest
|
Posted: Sun Aug 21, 2005 11:22 pm Post subject: Re: proposal for template type parameter constraint |
|
|
[email]wkaras (AT) yahoo (DOT) com[/email] wrote:
| Quote: | I would like to propose the following changes to the C++ Standard,
the goal of which are to provide an improved ability to specify
the constraints on type parameters to templates. Let me say from
the start that my knowledge of compiler implementation is very
limited. Therefore, my suggestions may have to be rejected
because they are difficult or impossible to implement.
|
I see no reason why the Committee would reject any proposal merely
because it would be difficult or impossible to implement. :)
Before getting the the specifics of your proposal, you should first
describe the problem that you are trying to solve. Anyone evaluating
the proposal is first going to have to agree that there is a real
problem that is motivating this idea.
After describing the problem you should then outline potential
approaches available in C++ today, only to show how each one fails to
solve the problem in a reasonable way. Of course during this stage you
may actually find a reasonable solution, in which case you have no
reason to go any further. After all, if the problem can be resolved
using C++ as it is today, there would be reason to change the language.
The goal here is not to change the language, the goal is to solve a
problem.
Only after you have described the problem and C++'s lack of a
reasonable solution, should you get to your proposal, and how it solves
it.
| Quote: | The proposal is based on the concept of "type similarity". Type
A is said to be similar to type B if any usage of B is a valid
usage of A, and any usage of an instance of B is also a valid
usage of an instance of A. I suggest that the language be
amended to allow type parameters to templates to be required
to be similar to a previously declared class. The proposed
new syntax is show in this example:
template
class X
{
...
};
Class B must have been declared, but it may or may not be
completely defined in the program.
|
It sounds like the class template X wants to require that for any type
parameter A, class B be convertible to A and A be convertible to class
B.
The std::tr1 type traits library has an is_convertible template that
can be used to test two types for convertibility. Class X could use
this trait to test for "similarity" between class B and type A and on
the basis of the result decide whether to be instantiable or not. (The
template class X could specialize the "false" case with a private
constructor or provide an implemention only for the "true" case).
In any event, without a description of the motivating problem, there is
no reasonable way to evaluate this proposal.
Greg
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
 |
wkaras@yahoo.com Guest
|
Posted: Mon Aug 22, 2005 7:55 pm Post subject: Re: proposal for template type parameter constraint |
|
|
Greg wrote:
| Quote: | wkaras (AT) yahoo (DOT) com wrote:
I would like to propose the following changes to the C++ Standard,
the goal of which are to provide an improved ability to specify
the constraints on type parameters to templates. Let me say from
the start that my knowledge of compiler implementation is very
limited. Therefore, my suggestions may have to be rejected
because they are difficult or impossible to implement.
I see no reason why the Committee would reject any proposal merely
because it would be difficult or impossible to implement. :)
Before getting the the specifics of your proposal, you should first
describe the problem that you are trying to solve. Anyone evaluating
the proposal is first going to have to agree that there is a real
problem that is motivating this idea.
After describing the problem you should then outline potential
approaches available in C++ today, only to show how each one fails to
solve the problem in a reasonable way. Of course during this stage you
may actually find a reasonable solution, in which case you have no
reason to go any further. After all, if the problem can be resolved
using C++ as it is today, there would be reason to change the language.
The goal here is not to change the language, the goal is to solve a
problem.
Only after you have described the problem and C++'s lack of a
reasonable solution, should you get to your proposal, and how it solves
it.
|
Since I wish to continue to be both employed and married, I cannot
dedicate the time it would take to write a reasonable formal proposal
to the Committee. I unfortunately cannot even fully comply with
your requests made above.
The template itself is of course a statement of the contraints on
the type parameters to the template. But I think it's a well known
problem that it's hard for a compiler to emit helpful error messages
without a more concise statement of the constraints. I believe
there is a technique that involves writing a short member function
that contains all usage of the type parameters in the template. But
aren't there issues with this approach with avoiding runtime
artifacts? And, I think my suggestion may permit the compiler to
emit diagnostics indicating that an "is similar to" contraint is
over or under-constraining the type parameter in comparison to
how the definition of the template itself constrains the type
parameter.
If anybody has links to good pages that have detailed discussion
with examples of the "dummy function" approach to type
parameter constraint, please post.
If it's feasable to contrain type parameters with class templates,
and extract implied parameters that can be used in the body of
the template being declared, my guess is that this would prove
to be a very useful capability.
| Quote: | The proposal is based on the concept of "type similarity". Type
A is said to be similar to type B if any usage of B is a valid
usage of A, and any usage of an instance of B is also a valid
usage of an instance of A. I suggest that the language be
amended to allow type parameters to templates to be required
to be similar to a previously declared class. The proposed
new syntax is show in this example:
template
class X
{
...
};
Class B must have been declared, but it may or may not be
completely defined in the program.
It sounds like the class template X wants to require that for any type
parameter A, class B be convertible to A and A be convertible to class
B.
... |
The main reason I chose the term "similar" is so I could recyle the
~ token. But maybe it's a bad choice because it applies symmetry.
When I say A is similar to B, I'm basically saying that B's public
interface is a subset of A's. So A being similar to B definitely
doesn't imply that B is similar to A.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
 |
wkaras@yahoo.com Guest
|
Posted: Tue Aug 23, 2005 2:26 pm Post subject: Re: proposal for template type parameter constraint |
|
|
[email]wkaras (AT) yahoo (DOT) com[/email] wrote:
| Quote: | I would like to propose the following changes to the C++ Standard,
the goal of which are to provide an improved ability to specify
the constraints on type parameters to templates.
... |
A flaw in what I've proposed is that it there are likely to be
practical situations when there are constraints on how multiple
type parameters that cannot be expressed as contraints on
an individual type parameter. The solution that occurs to
me is add the rule that, if a type parameter to the template
being declared has the same name as a type parameter to
a template used as a constraint, the actual parameter for
both must be the same. A simple example:
template <typename P>
class Child
{
public:
// Get/set parent.
void parent(P *p);
P *parent(void) const;
};
template <typename C>
class Parent
{
public:
// Return children.
vector<C *> children(void) const;
};
template <
class Parent ~ template
class Child ~ template<class Parent> Child >
class Do_stuff_with_trees
{
...
};
Unrelated thought: multiple constraints may be desirable:
template <typename Whip ~ class Floor_wax ~ class Dessert_topping>
...
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
 |
G.J. Giezeman Guest
|
Posted: Tue Aug 23, 2005 2:51 pm Post subject: Re: proposal for template type parameter constraint |
|
|
[email]wkaras (AT) yahoo (DOT) com[/email] wrote:
| Quote: | I would like to propose the following changes to the C++ Standard,
the goal of which are to provide an improved ability to specify
the constraints on type parameters to templates.
|
Are you familiar with the proposal by Bjarne Stroustrup and Gabriel Dos
Reis to add concepts to the language? See
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1782.pdf
That paper (and the papers it is based on) seem relevant to your proposal.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
wkaras@yahoo.com Guest
|
Posted: Tue Aug 23, 2005 11:47 pm Post subject: Re: proposal for template type parameter constraint |
|
|
G.J. Giezeman wrote:
| Quote: | wkaras (AT) yahoo (DOT) com wrote:
I would like to propose the following changes to the C++ Standard,
the goal of which are to provide an improved ability to specify
the constraints on type parameters to templates.
Are you familiar with the proposal by Bjarne Stroustrup and Gabriel Dos
Reis to add concepts to the language? See
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1782.pdf
That paper (and the papers it is based on) seem relevant to your proposal.
.... |
Thanks for the link, I'll have to try to read it carefully. But,
after quickly skimming through, I still think my suggestion has
some advantages. I'm use to describing the interface to a type
by writing a class interface declaration, not by trying to list
all possible uses of the type. Look at example of documenting
the constraints on a template parameter using a "reference class".
http://www.geocities.com/wkaras/gen_cpp/avl_tree.html
Maybe others would disagree, but I find this much more clear
than the way the Standard documents constraints on STL
type parameters.
I also don't see how their proposal
can be used to capture constraints on how multiple types interact
with each other.
One point that is brought into focus when comparing the two approaches
is that, with my approach, implicit conversions must be considered
when determining if an actual template type parameter is similar
to the constraining class or template. For example, if the
constraining
class has the member function:
long foo(int a);
it is OK if the actual parameter type has the member function:
int foo(long a);
Of course, since Dr. Stroustup has actually written a C++ complier,
there's a much better chance that his approach can be succesfully
implemented.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Douglas Gregor Guest
|
Posted: Tue Aug 23, 2005 11:56 pm Post subject: Re: proposal for template type parameter constraint |
|
|
[email]wkaras (AT) yahoo (DOT) com[/email] wrote:
| Quote: | I would like to propose the following changes to the C++ Standard,
the goal of which are to provide an improved ability to specify
the constraints on type parameters to templates. Let me say from
the start that my knowledge of compiler implementation is very
limited. Therefore, my suggestions may have to be rejected
because they are difficult or impossible to implement.
|
What you propose may be addressed by existing proposals to introduce
"Concepts" into C++. There are two active proposals in this area:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1758.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1782.pdf
Doug
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
 |
Douglas Gregor Guest
|
Posted: Thu Aug 25, 2005 3:14 pm Post subject: Re: proposal for template type parameter constraint |
|
|
[email]wkaras (AT) yahoo (DOT) com[/email] wrote:
| Quote: | G.J. Giezeman wrote:
Are you familiar with the proposal by Bjarne Stroustrup and Gabriel Dos
Reis to add concepts to the language? See
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1782.pdf
That paper (and the papers it is based on) seem relevant to your proposal.
...
Thanks for the link, I'll have to try to read it carefully. But,
after quickly skimming through, I still think my suggestion has
some advantages. I'm use to describing the interface to a type
by writing a class interface declaration, not by trying to list
all possible uses of the type. Look at example of documenting
the constraints on a template parameter using a "reference class".
http://www.geocities.com/wkaras/gen_cpp/avl_tree.html
|
At the risk of sounding pushy, I'd like to note that the other concepts
proposal I mentioned in my reply, N1758,
http://www.open-std.org/jtc1/s c22/wg21/docs/papers/2005/n1758.pdf
uses a syntax that is more similar to the "class interface declaration"
that you're proposing. Requirements are written using
"pseudo-signatures", which essentially look like the declaration part
of an out-of-line function definition. For instance, CopyConstructible
would look like this:
template<typename T>
concept CopyConstructible
{
T::T(const T&);
};
| Quote: | Maybe others would disagree, but I find this much more clear
than the way the Standard documents constraints on STL
type parameters.
|
FWIW, I agree with you. Even though we've been using "valid
expressions" (or "usage patterns") for documenting requirements in the
STL and similar libraries for ~10 years, I think the class interface
declaration/pseudo-signature approach is more readable.
| Quote: | I also don't see how their proposal
can be used to capture constraints on how multiple types interact
with each other.
|
Both of the concepts proposals can capture constraints on interactions
between multiple types, because "concepts" can have multiple template
parameters.
| Quote: | One point that is brought into focus when comparing the two approaches
is that, with my approach, implicit conversions must be considered
when determining if an actual template type parameter is similar
to the constraining class or template. For example, if the
constraining
class has the member function:
long foo(int a);
it is OK if the actual parameter type has the member function:
int foo(long a);
|
This is the precise reason for the "pseudo-" in "pseudo-signature"
Conversions absolutely must be allowable, otherwise it would truly be a
nightmare to get everything to match up exactly. N1758 basically says
that if you can convert from the pseudo-signature arguments to the
actual arguments, and then convert the actual return type to the
pseudo-signature return type, then you have a match. If you're familiar
with the Boost.Function library, it's like turning the pseudo-signature
into a boost::function<...> object.
| Quote: | Of course, since Dr. Stroustup has actually written a C++ complier,
there's a much better chance that his approach can be succesfully
implemented.
|
When we wrote N1758 we refused to write anything that we didn't already
know how to implement in a C++ compiler. Jeremy Siek has already
implemented most of the ideas in N1758 in the compiler for his generic
programming language, G, so we're on pretty firm ground. I'm sure
Stroustrup and Dos Reis have an implementation in mind for their
proposal as well. Similarities between your ideas and these proposals
would indicate, then, that your ideas could be implemented in a C++
compiler. Where your ideas differ from what is in the proposals (e.g.,
because there's something you want to do but can't with the extensions
in those proposals) we'd have to think a bit more about how to
implement them.
In any case, there are two active proposals before the C++ committee
for concepts, which are similar in spirit to what you are proposing.
The best way to get your ideas heard is probably to critique those
proposals (either privately, here, or comp.std.c++), suggesting changes
where you think that they can be improved. We're always open to
suggestions and more community involvement can never be a bad thing.
Doug
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|