Re: Does any widely-known program to extract template parameters requirements from source code already exist?
On Nov 7, 1:54 pm, Pavel Shved <Pavel.Sh...@gmail.com> wrote:
On 7 , 12:43, James Kanze <james.ka...@gmail.com> wrote:
On Nov 6, 10:33 am, Pavel Shved <Pavel.Sh...@gmail.com> wrote:
Is there a program of wide use that automatically extracts
template parameters requirements from source code of template
functions?
It's fundamentally impossible. How can a program divine the
intent of the author?
Fundamentally - it IS possible.
Fundamentally, it is NOT. The information simply isn't there
for any tool to extract.
I gave a simple example in my posting: std::list requires that
the class over which it is instantiated by Assignable. Most
implementations never use assignment. How could a tool
determine that an assignment operator is necessary (and that it
must return T&) if there isn't the slightest reference to it in
the code.
Imagine the (infinite) set of all possible C++ types; we are
to deduce a subset of it: which of them can be used as
template parameters. We have a procedure to check whether a
single class statisfies original requirements - mere
experiment (compiling our class against the function in
question).
The problem is where to find the original requirements. There's
not necessarily any trace of them in the code, so the procedure
will have to read the comments. Except that the requirements
may not even have been copied into the source as comments; most
of the implementations of std::list simply refer to the standard
for the requirements.
[...]
Would the following form of requirement statisfy you?
vv
a) T has member function operator<(.) visible in public scope which
return type is implicitely castable to bool and which argument is
implicitely castable from T with no ambiguity that cannot be resolved
by standard rules; or there is [bool] operator>( ]T[ , ]T[ ) in one of
the wrapping namespaces with no ambiguity etc...
Certainly not. First, it requires operator< to be a member
function, which certainly isn't necessary. Secondly, it doesn't
take into account possible conversions. A class like:
class C
{
public:
explicit C( int i ) : myI( i ) {}
operator int() const { return myI ; }
private:
int myI ;
} ;
will work for your function, for example, and there's not an
operator< in site.
Most importantly, of course, even a human, just reading your
code, cannot determine what the requirements are. Do you
"require" support for all of the comparison operators, or simply
<? (In other words, is the fact that you just use <, and none
of the others, an accident of the implementation, or is it a
contractual restriction.)
Secondly, of course, the function has very definite
requirements with regards to the semantics of some of the
operators. Requirements which I don't think any tool could
deduce.
Does the persistance of unsolvable equations forces us not to solve
linear ones? ;-)
False analogy. In this case, we have the requirements. They
must exist before anyone can write the code. Rather than asking
a tool to produce a necessarily incomplete, and possibly
incorrect version of them, doesn't it make more sense to require
the author to publish them with his code?
For class templates, some requirements apply to the class
itself, others just to specific functions in the class---how
would you distinguish?
Why should we distinguish? We'd rather gather them!
Because it's important. The implementations of std::list that
I've seen all use operator<, and very few use operator=. Never
the less, it is legal to instantiate an std::list over a type
which doesn't support operator<, but not over a type which
doesn't support operator=. The requirement for the first is
limited to certain functions; the requirement for the second
applies to the class.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34