Hi,

Today I found a way to emulate concept based overloading in a specific
case in C++03. As always, it has probably been found before by many, but
I was so excited that I had to write it down:) The essence is the
following. We start from this:

template <typename Input_ConstView2, typename Output_View2>
void copy(
const Input_ConstView2& input,
const Output_View2& output)
{
// Copy..
}

And end up with this:

template <
typename Element,
typename Input_ConstView2,
typename Output_View2>
void copy(
const ConstView2<Element, Input_ConstView2>& input,
const View2<Element, Output_View2>& output)
{
// Copy...
}

The former is an unrestricted template, while the latter matches only
specific classes. However, the classes can contain any type that models
the concepts (View2 and ConstView2) and they itself model the same
concepts. Thus this kind of emulates concept based overloading. The
technique can also be used to recover associated types of concepts to
template parameter level, which can be quite useful. This technique
works in this specific case where the views are of small size.

If you have the time, have a look at the full text at:

http://kaba.hilvi.org/Programming_C+...t_Wrapping.htm

Comments?

--
http://kaba.hilvi.org

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 24 août, 01:58, Kaba <n...@here.com> wrote:

> The former is an unrestricted template, while the latter matches only
> specific classes. However, the classes can contain any type that models
> the concepts (View2 and ConstView2) and they itself model the same
> concepts. Thus this kind of emulates concept based overloading.

Concepts are structural subtyping and are perfectly implicit.
I fail to see how your approach does it. It is nothing but an explicit
subtyping technique.

It is perfectly possible to implement real concept-like overloading in
C++03, though, via compile-time reflection, with has a few limitations
(not possible to detect operator= and constructors).


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Mathias Gaunard wrote:
> On 24 août, 01:58, Kaba <n...@here.com> wrote:
>
> > The former is an unrestricted template, while the latter matches only
> > specific classes. However, the classes can contain any type that models
> > the concepts (View2 and ConstView2) and they itself model the same
> > concepts. Thus this kind of emulates concept based overloading.
>
> Concepts are structural subtyping and are perfectly implicit.
> I fail to see how your approach does it. It is nothing but an explicit
> subtyping technique.

That's right. An object of a class that models the concept is explicitly
wrapped up in an object of a specific class for the purposes of
overloading. The similarities to concept based overloading are that:

1) An existing function that has been written for the wrapped classes
works automatically for a newly created class modeling the concept
(given that it has been wrapped).

2) Everytime the existing function in 1) matches a call, we can be sure
that the types of the arguments model the right concepts.

Do you mean to say that the technique is not similar to concept based
overloading at all? If so, please elaborate.

Btw, this technique is also similar to what is possible with the
curiously recurring template pattern. With expression templates (for
vectors in R^n, for example) one can use crtp to enable something like
this:

//! Returns the sum of elements.

template <int N, typename Real, typename Expression>
Real sum(const VectorExpression<N, Real, Expression>& x);

However, when using the crtp, one has to transmit all the needed type
information from the derived class to the superclass via the template
parameters. In the case of the View2 example the views have inner cursor
(iterator) classes which would need too much typing for me:

// Crtp approach

template <typename Derived_Element, typename Derived_View2, typename
Derived_ConstCursor, typename Derived_Cursor>
class View2
{
public:
typedef Derived_ConstCursor ConstCursor;
typedef Derived_Cursor Cursor;
//...
};

Thus I ended up in a wrapping approach instead:

template <typename Contained_Element, typename Contained_View2>
class View2
{
public:
typedef typename Contained_View2::ConstCursor ConstCursor;
typedef typename Contained_View2::Cursor Cursor;
//...
};

However, in exchange for the reduction in template parameters (the
Contained_Element was intentionally left as a parameter), I now need to
explicitly wrap the object to an object of a class of the ConstView2
family. That is not problematic in my case: the produced types from
views in views quickly become so complex anyway that it is unpractical
to write their types down (I am anxiously waiting for the automatic type
deduction in C++0x :). I avoid this by using template functions to
produce those temporary view objects with complex types. The wrapping
then fits there transparently.

> It is perfectly possible to implement real concept-like overloading in
> C++03, though, via compile-time reflection, with has a few limitations
> (not possible to detect operator= and constructors).

Define what you mean by _real_ concept-like overloading. How does that
technique work?

--
http://kaba.hilvi.org


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 29 août, 06:38, Kaba <n...@here.com> wrote:

> Define what you mean by _real_ concept-like overloading. How does that
> technique work?

With meta-functions that check whether a type fulfills certain
criteria using compile-time reflection techniques and SFINAE to do the
overloading.

See http://neoscientists.org/~tschwinger...pt_traits/doc/
for an implementation.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

on Thu Aug 28 2008, Mathias Gaunard <loufoque-AT-gmail.com> wrote:

> On 24 août, 01:58, Kaba <n...@here.com> wrote:
>
>> The former is an unrestricted template, while the latter matches only
>> specific classes. However, the classes can contain any type that models
>> the concepts (View2 and ConstView2) and they itself model the same
>> concepts. Thus this kind of emulates concept based overloading.
>
> Concepts are structural subtyping and are perfectly implicit.

Actually, that's not quite true. Don't forget that concepts have
semantic requirements that can't be deduced by the compiler. There many
input iterators that look, structurally, exactly like forward
iterators. If you don't do something explicit to distinguish them, it
has severe consequences. Try

std::vector<int>(b, e);

on your favorite standard library where b and e are mis-labeled input
iterators, and you'll see why. Expect a crash or worse. That's part of
why concepts in C++0x are not "auto" by default. From my P.O.V., having
to explicitly state concept conformance is the norm.

> I fail to see how your approach does it. It is nothing but an explicit
> subtyping technique.

I haven't looked at the code, but IMO there are two things required to
make it an interesting technique from a Generic Programming point of view:

* it would have to be *non-intrusive*, so you could establish
conformance of a type T to a concept X without altering T or X.

* it would have to be able to establish conformance of all instances of
a template to a given concept, i.e., "all vector<T> instances model
RandomAccessContainer."

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Mathias Gaunard wrote:
> On 29 août, 06:38, Kaba <n...@here.com> wrote:
>
> > Define what you mean by _real_ concept-like overloading. How does that
> > technique work?
>
> With meta-functions that check whether a type fulfills certain
> criteria using compile-time reflection techniques and SFINAE to do the
> overloading.
>
> See http://neoscientists.org/~tschwinger...pt_traits/doc/
> for an implementation.

To moderators: I'm a bit irritated by your manner to cencor any "thank
you"-messages in this forum (this has happened to me several times in
here). In my opinion, those are not superfluous but essential in forming
a discussion that has a start, a middle, and an end. Cencoring the
message that brings the thread to a closure on the part of the OP sends
the thread in a middle-limbo and gives an impression of the OP ignoring
the replies. What I wish to be able to communicate through with this
kind of post is that I have read and understood the reply.

{ In short, [thank you] is a rejection reason documented in the charter.
Discussion about the moderation policy is always on-topic. -mod/sk }

--
http://kaba.hilvi.org


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Sep 2, 7:03 am, Kaba <n...@here.com> wrote:

[...]

> To moderators: I'm a bit irritated by your manner to cencor any "thank
> you"-messages in this forum (this has happened to me several times in
> here). In my opinion, those are not superfluous but essential in forming
> a discussion that has a start, a middle, and an end. Cencoring the
> message that brings the thread to a closure on the part of the OP sends
> the thread in a middle-limbo and gives an impression of the OP ignoring
> the replies. What I wish to be able to communicate through with this
> kind of post is that I have read and understood the reply.
>

As a rule of thumb, you can always solve this problem by writing a
short summary for your discussion, and please do use some C++
keywords to express your points. After that, attach your "thank you"
message and everything will be fine. ;-)

Of course, this also helps for other who read your discussion later.

> { In short, [thank you] is a rejection reason documented in the charter.
> Discussion about the moderation policy is always on-topic. -mod/sk }

Hope this post is "on-topic", and I agree with you that post only
contains
"thank you" should always be rejected. Thank you for your time.

Regards,

Jiang


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 30 août, 16:58, David Abrahams <d...@boostpro.com> wrote:

> > Concepts are structural subtyping and are perfectly implicit.
>
> Actually, that's not quite true. Don't forget that concepts have
> semantic requirements that can't be deduced by the compiler. [...]
> That's part of
> why concepts in C++0x are not "auto" by default. From my P.O.V., having
> to explicitly state concept conformance is the norm.

That's true, indeed.
But emulating non-auto concept-like behaviour doesn't seem like a real
challenge to me (SFINAE and traits have done that for a long time
already), so when I read of emulating concepts I mostly thought of
auto ones.



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]