Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Are concepts like interfaces for templates?
38 views
Skip to first unread message
K. Frank
May 7, 2016, 8:30:11 PM5/7/16
to
Hello Group!
I (often) think of template classes as providing
compile-time "polymorphism." Is it fair to think
of concepts as interfaces for templates?
If so, is it highly precise to think of concepts
as interfaces for templates, or would it be more
just a useful analogy, but "don't push it to far?"
Thanks.
K. Frank
I (often) think of template classes as providing
compile-time "polymorphism." Is it fair to think
of concepts as interfaces for templates?
If so, is it highly precise to think of concepts
as interfaces for templates, or would it be more
just a useful analogy, but "don't push it to far?"
Thanks.
K. Frank
Öö Tiib
May 7, 2016, 9:10:48 PM5/7/16
to
On Sunday, 8 May 2016 03:30:11 UTC+3, K. Frank wrote:
> Hello Group!
>
> I (often) think of template classes as providing
> compile-time "polymorphism." Is it fair to think
> of concepts as interfaces for templates?
No ... I have had impression that the concepts are sets of constraints to
> Hello Group!
>
> I (often) think of template classes as providing
> compile-time "polymorphism." Is it fair to think
> of concepts as interfaces for templates?
any types. IOW ordinary class type or even fundamental type may fit with
a concept.
The checks of constraints is currently sometimes done by using
various template metaprogamming tricks, type traits and std::enable_if.
The concepts will hopefully simplify that.
>
> If so, is it highly precise to think of concepts
> as interfaces for templates, or would it be more
> just a useful analogy, but "don't push it to far?"
Marcel Mueller
May 8, 2016, 3:13:55 AM5/8/16
to
On 08.05.16 02.29, K. Frank wrote:
> I (often) think of template classes as providing
> compile-time "polymorphism." Is it fair to think
> of concepts as interfaces for templates?
From the programmers point of view I wold say yes.
> I (often) think of template classes as providing
> compile-time "polymorphism." Is it fair to think
> of concepts as interfaces for templates?
From the technical point of view they are totally different.
> If so, is it highly precise to think of concepts
> as interfaces for templates, or would it be more
> just a useful analogy, but "don't push it to far?"
'interface'.
Marcel
Chris Vine
May 8, 2016, 11:41:39 AM5/8/16
to
types, namely those that meet the concept requirements. If you find
unnecessary OO an abstraction which you particularly like (I don't, I
find it often adds obscurity) then I guess interfaces is one way of
thinking about them, as a subset of the set of all inheritable
implementation specifications.
However at the end of the day they are just a named set of type
constraints. So why not think of them as they are?
K. Frank
May 8, 2016, 12:50:26 PM5/8/16
to
Hello All!
> On Sat, 7 May 2016 17:29:59 -0700 (PDT)
> "K. Frank" <...> wrote:
> > Hello Group!
> >
> > I (often) think of template classes as providing
> > compile-time "polymorphism." Is it fair to think
> > of concepts as interfaces for templates?
> >
> > If so, is it highly precise to think of concepts
> > as interfaces for templates, or would it be more
> > just a useful analogy, but "don't push it to far?"
>
Öö Tiib:
> IOW ordinary class type or even fundamental type may fit with
a concept.
Yes, good point. A class need not know or care about
a concept it satisfies. The concept could well be
defined after the class. (See below.)
Marcel Mueller:
> Well, at the end the question is, what you summarize
> with the term 'interface'.
By "interface" I mean pretty much what java interfaces
are, or what you get in c++ when you derive from a
pure abstract base class:
struct InterfaceA {
virtual void methodA1() = 0;
virtual void methodA2() = 0;
virtual void methodA3() = 0;
};
struct ClassImpA : InterfaceA {
void methodA1() {}
void methodA2() {}
void methodA3() {}
};
On Sunday, May 8, 2016 at 11:41:39 AM UTC-4, Chris Vine wrote:
> Concepts are type classes. They describe a subset of the set of all
> types, namely those that meet the concept requirements. If you find
> unnecessary OO an abstraction which you particularly like (I don't, I
> find it often adds obscurity) then I guess interfaces is one way of
> thinking about them, as a subset of the set of all inheritable
> implementation specifications.
>
> However at the end of the day they are just a named set of type
> constraints. So why not think of them as they are?
Well, yes, this is certainly true. But my question is
driven by why you would want to use a concept.
I guess from the perspective of using a function argument,
concepts are like interfaces:
template <typename T "satisfies ConceptA"> void f (T& someA) {
// do stuff that relies on ConceptA
// true, ConceptA is a named set of type constraints,
// but why would I care to name it? Because I care
// that for the purposes of this function someA "is a"
// ConceptA.
}
vs.
void f (InterfaceA& someA) {
someA.methodA3();
someA.methodA1();
}
But from the perspective of defining a class, concepts
and interfaces are different:
struct ClassImpA : InterfaceA { ... };
ClassImpA had better implement InterfaceA, and the
compiler will check that it does. Note, in particular,
that for a ClassImpA to be passed to f (InterfaceA&),
InterfaceA has to be defined in the translation unit
of ClassImpA.
But a class that satisfies a concept need not know
about the concept (and the concept may not even have
been defined yet), and, as Öö reminds us, even fundamental
types can satisfy concepts.
struct SomeClassThatHappensToSatisfyConceptA {
// or maybe it doesn't ...
};
Speaking of which, are there any concept proposals
that permit or encourage classes to formally specify
which concepts they intend to satisfy (and will be
verified to satisfy)?
Thanks for everyone's thoughts on this.
K. Frank
> On Sat, 7 May 2016 17:29:59 -0700 (PDT)
> "K. Frank" <...> wrote:
> > Hello Group!
> >
> > I (often) think of template classes as providing
> > compile-time "polymorphism." Is it fair to think
> > of concepts as interfaces for templates?
> >
> > If so, is it highly precise to think of concepts
> > as interfaces for templates, or would it be more
> > just a useful analogy, but "don't push it to far?"
>
> IOW ordinary class type or even fundamental type may fit with
a concept.
a concept it satisfies. The concept could well be
defined after the class. (See below.)
Marcel Mueller:
> Well, at the end the question is, what you summarize
> with the term 'interface'.
are, or what you get in c++ when you derive from a
pure abstract base class:
struct InterfaceA {
virtual void methodA1() = 0;
virtual void methodA2() = 0;
virtual void methodA3() = 0;
};
struct ClassImpA : InterfaceA {
void methodA1() {}
void methodA2() {}
void methodA3() {}
};
On Sunday, May 8, 2016 at 11:41:39 AM UTC-4, Chris Vine wrote:
> Concepts are type classes. They describe a subset of the set of all
> types, namely those that meet the concept requirements. If you find
> unnecessary OO an abstraction which you particularly like (I don't, I
> find it often adds obscurity) then I guess interfaces is one way of
> thinking about them, as a subset of the set of all inheritable
> implementation specifications.
>
> However at the end of the day they are just a named set of type
> constraints. So why not think of them as they are?
driven by why you would want to use a concept.
I guess from the perspective of using a function argument,
concepts are like interfaces:
template <typename T "satisfies ConceptA"> void f (T& someA) {
// do stuff that relies on ConceptA
// true, ConceptA is a named set of type constraints,
// but why would I care to name it? Because I care
// that for the purposes of this function someA "is a"
// ConceptA.
}
vs.
void f (InterfaceA& someA) {
someA.methodA3();
someA.methodA1();
}
But from the perspective of defining a class, concepts
and interfaces are different:
struct ClassImpA : InterfaceA { ... };
ClassImpA had better implement InterfaceA, and the
compiler will check that it does. Note, in particular,
that for a ClassImpA to be passed to f (InterfaceA&),
InterfaceA has to be defined in the translation unit
of ClassImpA.
But a class that satisfies a concept need not know
about the concept (and the concept may not even have
been defined yet), and, as Öö reminds us, even fundamental
types can satisfy concepts.
struct SomeClassThatHappensToSatisfyConceptA {
// or maybe it doesn't ...
};
Speaking of which, are there any concept proposals
that permit or encourage classes to formally specify
which concepts they intend to satisfy (and will be
verified to satisfy)?
Thanks for everyone's thoughts on this.
K. Frank
Chris Vine
May 8, 2016, 1:54:19 PM5/8/16
to
On Sun, 8 May 2016 09:50:12 -0700 (PDT)
"K. Frank" <kfran...@gmail.com> wrote:
[snip]
The main purpose is to provide reasonable diagnostics from the compiler
which approximate to the diagnostics you get from C++'s type system with
respect to non-template types.
You can also use type classes for choosing function overloads based on
the type constraints imposed and for ambiguity resolution. I don't know
if the C++ concepts proposal does that (it probably does). It quite
probably also does other things that I don't know about, for which you
can find papers. They have been a moving target, which apparently will
miss C++17, which is a shame.
"K. Frank" <kfran...@gmail.com> wrote:
[snip]
> Well, yes, this is certainly true. But my question is
> driven by why you would want to use a concept.
That wasn't your original question (but it is a reasonable one to ask).
> driven by why you would want to use a concept.
The main purpose is to provide reasonable diagnostics from the compiler
which approximate to the diagnostics you get from C++'s type system with
respect to non-template types.
You can also use type classes for choosing function overloads based on
the type constraints imposed and for ambiguity resolution. I don't know
if the C++ concepts proposal does that (it probably does). It quite
probably also does other things that I don't know about, for which you
can find papers. They have been a moving target, which apparently will
miss C++17, which is a shame.
Öö Tiib
May 8, 2016, 2:14:03 PM5/8/16
to
On Sunday, 8 May 2016 19:50:26 UTC+3, K. Frank wrote:
>
> But a class that satisfies a concept need not know
> about the concept (and the concept may not even have
> been defined yet), and, as Öö reminds us, even fundamental
> types can satisfy concepts.
>
> struct SomeClassThatHappensToSatisfyConceptA {
> // or maybe it doesn't ...
> };
>
> Speaking of which, are there any concept proposals
> that permit or encourage classes to formally specify
> which concepts they intend to satisfy (and will be
> verified to satisfy)?
Not to my knowledge. Generally we assume that certain patterns are
>
> But a class that satisfies a concept need not know
> about the concept (and the concept may not even have
> been defined yet), and, as Öö reminds us, even fundamental
> types can satisfy concepts.
>
> struct SomeClassThatHappensToSatisfyConceptA {
> // or maybe it doesn't ...
> };
>
> Speaking of which, are there any concept proposals
> that permit or encourage classes to formally specify
> which concepts they intend to satisfy (and will be
> verified to satisfy)?
used when we talk about "compile-time polymorphism". Patterns like
for example CRTP. CRTP example from C++ standard library:
class Device : std::enable_shared_from_this<Device>
{
// ...
};
As result we have a class Device that indeed fulfills certain constraints
but if we want to have a concept about those constraints then we will
still need to define it separately. Also my impression is that patterns
like CRTP will remain in use after concepts.
0 new messages