This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: testing techniques for verifying includes in std:: namespace


>>     - The "archetypes" part, which tests that an algorithm does not try
>> to use any operations on its input types that aren't stated in the
>> concept requirements. For example, this would detect a "for (; first <
>> last; ++first)" error in an algorithm that is meant to take input
>> iterators. This kind of checking is unnecessary in ConceptGCC, because
>> the compiler itself will diagnose the error when the template is parsed.
>>
>>     - The "concept checks" part, which tests that the user has provided
>> types that meet the minimum stated requirements of the algorithm. For
>> example, this would detect an attempt to use adjacent_find on an input
>> iterator. This kind of checking is unnecessary in ConceptGCC, because
>> the compiler checks that the user-provided types meet the stated
>> requirements of the algorithm before the algorithm is instantiated.
>
> Thanks for the clarification.
>
> I was thinking that eventually, there would be negative tests to verify
> these two parts.
>
> No?

I don't really see any point in doing this for C++0x. It is *extremely*
hard to write archetypes that come anywhere close to the same level of
type-checking we get from constrained templates. Likewise with the
"concept checks"... the compiler's type-checking is better than what we
can do, and it's automatic.

Like traits, tag dispatching, and SFINAE, concept checking and archetypes
are great techniques that are being completely replaced by concepts.

  Cheers,
  Doug


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]