Suppose there are two concepts C1 and C2 that have exactly the same
requirements, but different semantics. C1 and C2 have been developed
separately without the developers ever knowing of the other concept. If
I got both of these libraries I could pass an object of class A
implementing concept C1 to a function taking an object of a class
implementing concept C2. But because the semantics are different, the
consequences would be quite surprising.

So, it seems it could be useful to have a notation by which to tag the
classes to say that they implement a given concept. Then only those
classes would accepted that really state to implement the concept.
Something on the lines of:

class Rabbit
: implements AnimalConcept
{
};

No?

--
Kalle Rutanen
http://kaba.hilvi.org

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Let me rephrase my question:

class Snuffy (implements RabbitConcept)
{
public:
   template <RabbitConcept Rabbit>
   void haveSexWith(Rabbit& rabbit);
};

class John (implements HumanConcept)
{
public:
   template <HumanConcept Human>
   void haveSexWith(Human& human);
};

class Sarah (implements HumanConcept)
{
public:
   template <HumanConcept Human>
   void haveSexWith(Human& human);
};

Now, while John can correctly have sex with himself and Sarah, you
wouldn't want John to have sex with Snuffy, would you?!

--
Kalle Rutanen
http://kaba.hilvi.org

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Apr 12, 4:31 am, REkalleMOunderscoreVErutane...@hotmail.com (Kaba)
wrote:

> class John (implements HumanConcept)
> {
> public:
>    template <HumanConcept Human>
>    void haveSexWith(Human& human);
>
> };

This code doesn't mean that John can have sex with humans.
It means that John can have sex with other people that, like him, can
have sex with someone.

Since Snuffy can have sex too, John can have sex with Snuffy.
C++ doesn't care about zoophilia.

Actually your concept would just be a type that has a member
haveSexWith which can take as a parameter any other type that has such
a member.


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Kaba wrote:
> Suppose there are two concepts C1 and C2 that have exactly the same
> requirements, but different semantics. C1 and C2 have been developed
> separately without the developers ever knowing of the other concept. If
> I got both of these libraries I could pass an object of class A
> implementing concept C1 to a function taking an object of a class
> implementing concept C2. But because the semantics are different, the
> consequences would be quite surprising.
>
> So, it seems it could be useful to have a notation by which to tag the
> classes to say that they implement a given concept. Then only those
> classes would accepted that really state to implement the concept.
> Something on the lines of:
>
> class Rabbit
> : implements AnimalConcept
> {
> };

That notation is the concept_map, no?

class Rabbit {};

concept_map AnimalConcept<Rabbit> {};

Don't use auto concepts if you want explicit conformance
notation as above.

-- James

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

on Wed Apr 11 2007, Kaba <REkalleMOunderscoreVErutanenME-AT-hotmail.com> wrote:

> Suppose there are two concepts C1 and C2 that have exactly the same
> requirements, but different semantics. C1 and C2 have been developed
> separately without the developers ever knowing of the other concept. If
> I got both of these libraries I could pass an object of class A
> implementing concept C1 to a function taking an object of a class
> implementing concept C2. But because the semantics are different, the
> consequences would be quite surprising.

That's one good reason we don't use auto concepts for everything.
http://www.generic-programming.org/languages/conceptcpp/tutorial/

> So, it seems it could be useful to have a notation by which to tag the
> classes to say that they implement a given concept. Then only those
> classes would accepted that really state to implement the concept.
> Something on the lines of:
>
> class Rabbit
> : implements AnimalConcept
> {
> };
>
> No?

That's what concept maps are for.

  class Rabbit {};
  concept_map AnimalConcept<Rabbit> {};

Separating the concept_map from the class allows retroactive concept
mapping.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Don't Miss BoostCon 2007! ==> http://www.boostcon.com

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Apr 12, 1:39 am, Kaba <REkalleMOunderscoreVErutane...@hotmail.com>
wrote:
> Suppose there are two concepts C1 and C2 that have exactly the same
> requirements, but different semantics. C1 and C2 have been developed
> separately without the developers ever knowing of the other concept. If
> I got both of these libraries I could pass an object of class A
> implementing concept C1 to a function taking an object of a class
> implementing concept C2.

If the type fulfills the requirements for C1, then it fulfills the
requirements for C2 since they are the same.
That seems normal then that it can be usable with such a class.


>  But because the semantics are different, the
> consequences would be quite surprising.

I don't see how that would be problematic.
Requirements are a set of preconditions the type must fulfill to be
usable with a specific template. They're not tags or anything of the
like.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

on Thu Apr 12 2007, "Mathias Gaunard" <loufoque-AT-gmail.com> wrote:

> On Apr 12, 1:39 am, Kaba <REkalleMOunderscoreVErutane...@hotmail.com>
> wrote:
>> Suppose there are two concepts C1 and C2 that have exactly the same
>> requirements, but different semantics. C1 and C2 have been developed
>> separately without the developers ever knowing of the other concept. If
>> I got both of these libraries I could pass an object of class A
>> implementing concept C1 to a function taking an object of a class
>> implementing concept C2.
>
> If the type fulfills the requirements for C1, then it fulfills the
> requirements for C2 since they are the same.
> That seems normal then that it can be usable with such a class.
>
>
>>  But because the semantics are different, the
>> consequences would be quite surprising.
>
> I don't see how that would be problematic.  Requirements are a set
> of preconditions the type must fulfill to be usable with a specific
> template. They're not tags or anything of the like.

Actually, the OP put his finger on something very important.  There
are input iterators that masquerade, in all syntactic aspects, as
forward iterators (istreambuf_iterator is one, IIRC).  Pass a pair of
these to std::vector's constructor, and _very_ bad things happen,
because vector will try to take advantage of semantic properties of
forward iterators (you can traverse the same element twice), that
aren't offered by input iterators.

Again, that's why we make people explicitly declare auto concepts
explicitly, if that's what you want.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Don't Miss BoostCon 2007! ==> http://www.boostcon.com

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

> Since Snuffy can have sex too, John can have sex with Snuffy.
> C++ doesn't care about zoophilia.

Poor Snuffy.

--
Kalle Rutanen
http://kaba.hilvi.org

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

> That's one good reason we don't use auto concepts for everything.
> http://www.generic-programming.org/languages/conceptcpp/tutorial/

Thanks, understood.

--
Kalle Rutanen
http://kaba.hilvi.org

---
[ 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.comeaucomputing.com/csc/faq.html                      ]