Boost logo

Boost :

Subject: [boost] [type_erasure][docs]conceptdef.html terms
From: Larry Evans (cppljevans_at_[hidden])
Date: 2012-08-29 10:56:21


The doc:

http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost_typeerasure/conceptdef.html

states:

  When a concept is instantiated with a specific set of type bindings,
  each placeholder is bound to a cv-unqualified non-reference
  type. After replacing each placeholder in the template argument list
  with the type that it binds to, the following must hold.

    * The number of arguments of apply in the bound concept must be
      the same as the number of arguments in the unbound concept.

    * The arguments and return type of apply in the bound concept can
      be derived from the corresponding arguments and the return type
      in the unbound concept as follows: If the argument in the
      unbound concept is a placeholder with optional cv and reference
      qualifiers, then the argument in the bound concept can be found
      by replacing the placeholder. Otherwise, the argument in the
      unbound concept must be the same as the argument in the bound
      concept.

However, there is no apply in the builtin concept's:

  same_type (in same_type.hpp)
  null_construct (in constructible.hpp)
  destructible (in builtin.hpp)

so, shouldn't the paragraph qualify the word concept with the word
primitive, to make clear it's talking about item 3 in the list:

  There are three kinds of concepts.

    1. The library defines a number of predefined concepts.
    2. Any MPL Forward Sequence whose elements are concepts is also a
       concept.
    3. Users can define their own primitive concepts.

from the 2nd paragraph of conceptdef.html?
IOW, rephrase the 1st sentence to:

  When a *primitive* concept is instantiated with a specific set of type
  bindings,

I guess one could infer from the sentence 2 paragraphs up:

  Each primitive concept defines a single operation.

that the word concept in subsequent paragraphs means primitive
concept, but not every reader (in particular, this reader) would make
that inference unless he'd actually looked at the definition of some
of the predefined concepts.

BTW, the same_type doc uses the term 'built in concept'; however, the
conceptdef.html doc uses the term 'predefined concept'. It would be
helpful if the same term were used everywhere.

HTH.

-regards,
Larry


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk