Regarding Exported Concept Maps proposed by David Abrahams and Doug
Gregor
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2918.html).

Is there any advantage over the following?

concept LessThanComparable<typename T>
{
     bool operator<(T const& x, T const& y);
}

template <LessThanComparable T>
inline bool operator>(T const& x, T const& y) { return y < x; }

template <LessThanComparable T>
inline bool operator<=(T const& x, T const& y) { return !(y < x); }

template <LessThanComparable T>
inline bool operator>=(T const& x, T const& y) { return !(x < y); }

Petr

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 30 Jan., 01:14, Petr <petr.ka...@volny.cz> wrote:
> Regarding Exported Concept Maps proposed by David Abrahams
> and Doug Gregor
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2918.html).

( I liked the spirit of that proposal. Why should defaulted functions
(from concepts) only be accessible in constrained function
templates? )

> Is there any advantage over the following?
>
> concept LessThanComparable<typename T>
> {
>      bool operator<(T const& x, T const& y);
> }
>
> template <LessThanComparable T>
> inline bool operator>(T const& x, T const& y) { return y < x; }
>
> template <LessThanComparable T>
> inline bool operator<=(T const& x, T const& y) { return !(y < x); }
>
> template <LessThanComparable T>
> inline bool operator>=(T const& x, T const& y) { return !(x < y); }

Advantage? Well, it's definitely different.

Using your approach, the concept definition and the operator templates
are fairly isolated from both pieces of code: the part that defines a
user-defined type and the part that uses this user-defined type. You
can define and use it without ever having seen this concept and
operator template definition. So, users don't automatically get the
other operators. Instead, you'd force them to

   - include a header (containing the concept and operator templates)

   - make sure that these operator templates are found during name
     lookup (no ADL here)

so they can write a>b and have it work like intended.

The proposal of David and Doug achieves the following: As the provider
of a user-defined type you explicitly state that you want the
defaulted functions from the LessThanComparable to be accessible to
users without them forcing to do anything special. Typically you'd
place the "export concept_map"-line right under the definition of your
type and operator< so that this is automatically visible to every user
of your type. Now, if you write a>b somewhere (a and b being objects
of your type) the compiler will look for this operator in various
scopes and namespaces INCLUDING the associated namespace of your type
(this is ADL in action). This associated namespace will contain
operator> for your type due to the exported concept_map. Bingo!

So, the difference is exported concept_maps is something you use in
combination with WRITING types and your approach (being a conceptized
version of std::relops) is something that requires explicit action on
the USER side of things: at least making sure that name lookup will
find these operator templates because ADL won't help you in this
situation.

Cheers,
SG


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 30 Jan., 01:14, Petr <petr.ka...@volny.cz> wrote:
> Regarding Exported Concept Maps proposed by David Abrahams and Doug
> Gregor
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2918.html).
>
> Is there any advantage over the following?
>
> concept LessThanComparable<typename T>
> {
>      bool operator<(T const& x, T const& y);
>
> }
>
> template <LessThanComparable T>
> inline bool operator>(T const& x, T const& y) { return y < x; }
>
> template <LessThanComparable T>
> inline bool operator<=(T const& x, T const& y) { return !(y < x); }
>
> template <LessThanComparable T>
> inline bool operator>=(T const& x, T const& y) { return !(x < y); }

I think the answer to your question is "yes":

Concepts where designed to provide a single container
of requirements, associated functions, associated types,
etc. and with your replacement this means that concept
LessThanComparable has only one associated function
(operator <), but additionally you provide a set of
functions in terms of the concept - this is a different
message for concepts. Given the analogy to classes this
would mean that *all* algorithms of namespace std which
require LessThanComparable solely (e.g. std::min) would
somehow belong to the very same concept - that looks
rather odd to me.

In C++ we have currently only one way to extend features
of a class: By providing them in the same namespace to
which the class belongs. Concepts should not be required
to use the same workaround to create a wrapper to a set
of functionalities. I consider functions like std::min not
as direct part of concept LessThanComparable, but instead
as second-level derivatives that can be derived from this
concept. Such functions may come quite different domains.
But <, <=, >, and >= are all operators, which are somehow
equivalent and should stay together.

Another problem is that different look-up paths will
happen with both approaches. Consider a refined
concept

concept SomeThing<typename T> : LessThanComparable<T> {
   bool operator>(T const& x, T const& y);
}

If operator> is part of LessThanComparable and I use
the function

template <LessThanComparable T>
bool is_greater(T const& x, T const& y) { return x > y; }

with a type that models SomeThing this will consider
the concept map for SomeThing to find the implementation
of > in the current std::LessThanComparable concept,
but it will only consider the free operator> in your alternative
suggestion.

HTH & Greetings from Bremen,

Daniel Kr   gler


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]