Re: [boost] [function types] New tag type logic [update]

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-07-08 04:32:42

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Tobias Schwinger

> > That will remove any cv-qualifiers on a pointer to function 
> (as in a 
> > "const pointer to function"), but it won't remove the cv-qualifiers 
> > from a raw function type.  There is no way to add or remove such 
> > qualifiers without taking the type apart and putting it 
> back together with or without the cv-qualification.
> > 
> 
> Is either way defined behaviour? Got some standard references 
> for me, perhaps?

-----
8.3.5/4

A cv-qualifier-seq shall only be part of the function type for a nonstatic
member function, the function type to which a pointer to member refers, or the
top-level function type of a function typedef declaration.  The effect of a
cv-qualifier-seq in a function declarator is not the same as adding
cv-qualification on top of the function type, i.e., it does not create a
cv-qualified function type.  In fact, if at any time in the determination of a
type a cv-qualified function type is formed, the program is ill-formed.
-----

There might be more references, but this gives a significantly strong
implication that cv-qualification on function types is radically different than
normal cv-qualification.  The cv-qualifiers are modifying the implicit 'this'
parameter.  I.e. the cv-qualifiers don't modify the function type (all functions
are 'const' because C++ doesn't treat functions as first-class objects); they
modify an implicit formal parameter.  So attempting to remove cv-qualification
this way would be akin to transforming 'void (const int*)' into 'void (int*)'.

> > I'm not familiar with all that your library does, so, from 
> my point of 
> > view, there might be a runtime component to the library.  I assume 
> > that you mean compile-time overhead, but I don't see why 
> there has to be.
> 
> Oh! I'm sorry -- assumed there was enough context around.

There probably is, but I haven't been reading all of it.  Given the nature of
your library, I thought it unlikely that there was a runtime component and
therefore assumed that you were referring to static overhead.

> > Say you where going
> > to support them only on compilers that deal with the 
> properly.  All it 
> > takes is to defer them to the implementation of 
> > pointers-to-member-functions.  I.e. say that you have 
> > 'is_pointer_to_const_member_function', then you can make 
> 'is_const_function' without any (significant) overhead:
> > 
> > struct C { };
> > 
> > template<class T> struct is_const_function
> >     : is_pointer_to_const_member_function<T C::*> { };
> > 
> > Granted, you have to do a little more than that (by 
> eliminating those 
> > types that cannot be the subject of a pointer-to-member--such as 
> > references), but it isn't that hard.  It also isn't too much of a 
> > burden to say: this metafunction doesn't work on x, y, and 
> z compilers.
> > 
> 
> In this particular case it doesn't cost much. But if I'm 
> going to do a trivial thing as finding out whether 'int' is a 
> (any cv-qualified) function I need a second non-trivial 
> template instantiation and a couple of trivial ones as you 
> mentioned already. I'm not sure this feature is worth its 
> price. Further, if your compiler is smart enough you can 
> easily write it yourself if you need it.

Yes.  On the same token, however, I can just as easily write any other sort of
function type manipulation that I might need.  The point is that a library like
yours should prevent the need for me to do it.  If the feature is not used, the
only possible *significant* compile-time overhead that I see is preprocessing.
This can be solved by making headers more granular (not a commentary on your
library) and simply not including it.  If it is used, then the user pays for it
with a few template instantiations--just like anything else.  From an
implementation point-of-view (meaning the cost on your time personally),
supporting this would be fairly easy if you don't try to make it work on
compilers that are fundamentally broken in this area.

> > If that is the case, then you shouldn't be supporting open 
> variadics.  
> > Support for that adds significant overhead to the implementation.  
> > Granted, variadic function types are more common than cv-qualified 
> > function types, but they are still quite rare.
> 
> Can't really say 'printf' is a dark corner of the language... 

The type of 'printf' may have C linkage which you can't do anything with on any
conforming compiler.  Basically, 'printf' is untouchable (in this context) in
portable code.

> "Dark history", perhaps. And open variadics can be quite 
> useful. We shouldn't make assumptions on how many people use 
> them -- variadic functions have been there for a long time.

Trust me, I'm a big fan of the concept of variadics.  Given "reasonable"
language support, they are a very enabling feature for a variety of things.
(This is one of the reasons why I'm glad that C is still around.  IMO, C++ tends
to overlook the fundamental building blocks (e.g. procedural programming) as it
grows.  In some sense, C keeps C++ grounded.  Of course, C is not the be all and
end all of procedural programming.  By now, we should have nested functions,
with them comes closures, and with closures comes anonymous functions (i.e.
lambda functions).  These are fundamental building blocks.)  Unfortunately, we
don't yet have reasonable variadic support in C++.  We need typesafe variadic
functions, variadic templates, and variadic macros.  However right now, given
that argument lists are an iterative syntactic structure (currently at odds with
generic programming), that current variadic functions aren't typesafe (at odds
with generic programming), and that you can't portably pass anything to them
except POD's (at odds with generic programming)--it's a safe bet that function
type manipulation (which would likely be done in generic code) of variadic
function types will be extremely rare.  Variadic functions (specifically, how to
use them even to the point of how to invoke them) are way too semantically
dependent on extra-linguistic knowledge like documentation.  I certainly don't
think you should remove support for them--I just see its utility as on par with
cv-qualified function types--yet supporting it effectively doubles all of the
template specializations required.

I don't buy the 'cost' argument as opposed to the 'completeness' argument, but
I'm not terribly concerned over the lack of support.  However, I'm a would-be
user of a library, not the library author.  If I was the library author,
completeness would be a worthwhile goal in and of itself--it is a requirement
for mastery of the subject.  As a library author in other areas, the most
annoying limitations are often those corner cases that you can do nothing about
(and this isn't one of them), but present a barrior to completeness.  It's the
difference between "as good as can be given x, y, and z" and "ideal".  My
disagreement is more of a disagreement with perspective rather than over a
particular feature.

Regards,
Paul Mensonides