On 27 August 2012 13:54, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
On Monday, August 27, 2012 11:38:52 Manu wrote:
> On 27 August 2012 11:12, Jonathan M Davis <
jmdavisProg@gmx.com> wrote:
> > and it makes no sense to use them with function pointers or function
> > literals.
>
> If that were true, we wouldn't be having this discussion.
unless you're not really using them like function pointers, otherwise you
wouldn't have been using the default arguments in the first place.
How do I use a function pointer 'like a function pointer' by your reasoning?
Is dynamic linkage not a valid use of function pointers?
It's possibly the most common use. Shared code is not exactly uncommon, just that it's often automated with compiler sugar these days.
Manually binding dynamic code has become rare, but it's still valid.
Default arguments just do not make sense with function pointers, because they
don't follow the function pointer, because it's a _pointer_ and has no
knowledge of what it's pointing to. It's only at the declaration point of the
function that the default argument exists, and that has _nothing_ to do with
the function pointer.
Clearly, since it's a function pointer, I don't own the function its self, or I'd just call that directly.
However, as you say, at the declaration point of the function pointer, I can likewise inform the compiler of the default args.
If the default args were worked into the variable declaration, that might work just as well as if it were in the type.
I don't really care so much HOW it works, only that it does. I think 99% of my cases would be addressed by the def args living in the variable declaration.
You might as well ask a reference of type Object what
the arguments used to construct the derived class that it actually refers to
were as expect a function pointer to have any clue about default arguments to
the function that it points to.
I agree, in principle, but I've still lost a thoroughly useful feature. Move it perhaps (to the declaration?), but don't re-move it (cough).