Re: future C standards

"jacob navia" <jacob@xxxxxxxxxx> wrote in message news:g4tsu1$nl1$1@xxxxxxxxxxx
Wojtek Lerch wrote:
"jacob navia" <jacob@xxxxxxxxxx> wrote in message news:g4tl47$7gu$1@xxxxxxxxxxx
Wojtek Lerch wrote:
Another problem I have with your rules is that they never mention any pointer types. That seems to imply that anything other than an exact match is not accepted for pointer arguments; but I would expect function overloading to allow matching a parameter defined as a pointer to a qualified type with an actual argument that points to a less-qualified type;
....
Can you tell me with an example what you mean
here?

void overloaded foo( const char *string );
char *p;
foo( p ); // The type of "p" is NOT "const char*"

Did you forget to comment on this one?

In general, I would expect that if a function-call expression is a valid way to call a regular function with a particular signature, then it should be considered a possible call to an overloaded function with the same signature. But from your remark about void pointers I assume that you don't want to make that promise:

void fun1( void * );
void overloaded fun2( void * );

fun1( "hello" ); // Correct, an implicit conversion occurs
fun2( "hello" ); // Invalid, the type of "hello" is not void*

In your example the designer of the overloaded function
specified a void pointer, and NOT a char *. If you make
this (admittedly rather strange) requirement, why should
the compiler tell the overloaded function otherwise?

What requirement? That you can pass a char* to a function that takes a void*? What's so strange about it? C has allowed it since void was invented.

Note that the example function you propose:

fun1(void *);

will never be able to do ANYTHING with that pointer besides passing it
along to some other function!

Why wouldn't it be able to convert it to a different pointer type? And then maybe do something with the result?

Don't forget this is just an example. Its purpose was not to demonstrate the usefulness of void pointers. In real life, a function could have more arguments. And, most likely, a different name.

Of course there are functions that need a void pointer. free() for
instance. But why overloading them?

Currently in standard C if you define

void fn(void *);

you can pass it ANY pointer, it is generic already. Why would you
need a generic function?

It's your claim that generic functions are worth adding to C, not mine. But imagine a case like this:

void overloaded writedata( struct stream1 *stream, const void *buf, size_t buflen );
void overloaded writedata( struct stream2 *stream, const void *buf, size_t buflen );

Does this sound like a potentially legitimate pattern of using overloaded functions?

Given that your justification for function overloading is to let programmers avoid having to remember multiple names for functions that perform similar operations on different types, I'd say that that gain is completely lost if programmers will now have to know the exact types of parameters of the function variant they want to call, and write an explicit cast because the compiler will not perform the implicit conversions that would normally happen if the function weren't overloaded.

This is absolutely not true. I specified a LOT of conversions,
specially for numbers and actual types!

What I see as problematic is automatic pointer conversion!

Explicit casts are potentially much more evil than explicit function names.


Yes, so why use them?

Because if you insist on exact matching of pointer types, something as simple as

void overloaded fun( const char *string );

fun( "Hello" );

doesn't work without an explicit cast (or a temporary variable with the matching type).

Avoid such ambiguities with a set of overloaded functions
that cover all cases you want to handle in your functions.

You mean you want me to have two functions, one that takes a pointer to const and the other a pointer to non-const? What if the function needs three pointer parameters -- will I have to write eight identical functions just to avoid explicit casts?

Does your implementation accept any pointer types other than an exact match?

No. I know this may seem like a big limitation, and it is a big
limitation.

Yes it definitely is. My personal opinion is that it's big enough to make your proposal unacceptable.

Why?

Because it introduces too many restrictions to how an overloaded function can be called, compared to how an equivalent normal function can be called today.

Unacceptable for what?

Unacceptable for adding to the standard. If I were on the committee, I'd vote against any proposal that introduced similar limitations.

I have used it extensively specially for numerical software and
it works like a charm. Many applications are possible. I do not
see why you should be forced to promote pointers.

I see however that some pointer promotions may be useful,
for instance using signed/unsigned char pointers as equivalent.

I'm not promoting "pointer promotions", whatever exactly you mean by that; all I'm saying is that those implicit conversions that already happen in a call to a normal function should also have a chance of happening in a call to an overloaded function. My expectation is that a function that is declared as overloaded but has only one variant should behave identically to a regular function. There's no need to invent new "pointer promotions" or introduce an equivalence between signed/unsigned pointers or any other unnecessary differences between overloaded functions and normal functions. Differences beteween the behaviour of two kinds of functions should be kept to a minimum.

Can you show me a place where pointer promotion is really needed?

I don't know if you consider the implicit pointer conversions that C already applies to assignment and argument passing to be "really needed"; but in my personal opinion, they are.

But I want to avoid any complicated rules. If you
need it, you just add an explicit cast to the call and you are
all set!

Another way to avoid complicated rules is to drop your proposal altogether. ;-)

Well, that is what many people "propose". Let's do nothing because
if we do something to improve the power of expression of the
language it will be bad because it will miss feature XXX that
is present in C++ or whatever other language I like.

I don't know about anybody who proposes just that; but I do agree that doing nothing is better than dumping a half-baked, under-specified "proposal" on the committee and insisting that they write a proper specification for it and force all compilers to implement it.

I remark that you skip the parts of my message where I gave the
basic philosophy of the proposal and why I do not want pointer
promotion.

I'm still waiting for an explanation of why you don't want let me pass a char* to a function that takes a const char* -- or did I miss it?

.

Relevant Pages

  • Re: confusion: casting function pointers
    ... pointer from the 'actual/other modules' that takes arguments of type ... list to types of void *). ... int main{ ... without a prototype, a number of special "promotion" rules take ...
    (comp.lang.c)
  • Re: [RFC] timers, pointers to functions and type safety
    ... * they have callback of type void ... callback is called by the code that even in theory has no ... cast to unsigned long and cast back in the callback. ... number - not a pointer cast to unsigned long, not an index in array, etc. ...
    (Linux-Kernel)
  • Re: Can I Trust Pointer Arithmetic In Re-Allocated Memory?
    ... You can't do pointer arithmetic on a void* value. ... qsort behaves in a manner consistent with its specification. ... actually works as advertised...but doesn't mean that the cast is ...
    (comp.lang.c)
  • Re: void pointers
    ... A void pointer is an address of a region of memory (which may or may not ... This creates an array of 5 pointers to void. ... This is casting an int to a void *. ...
    (comp.lang.c)
  • Re: The void** pointer breaking symmetry?
    ... void** is a generic pointer type that can be implicitly converted ... because dereferencing the void ** variable once gives ...
    (comp.lang.c)