void * vs char *

[Ian Collins]

Re: void * vs char *

Francine.Neary@ googlemail.com wrote:

>

>>>void call(void *p)
>>>{
>> printf("%d\n",p->a);

>>
> struct s *ps = p;

>
A rose by any other name... I don't see that this gains anything in
terms of clarity or brevity over "printf("%d\n", ((struct s*)p)->a);" -
in fact it just leads to an additional pointer floating around.
>

You said "I still need to explicitly cast p to a (struct s*) to avoid a
compile-time error", which I showed by example to be incorrect. That's
the thing with a void*, you can use implicit conversion. What harm does
a temporary pointer cause?

>

>>Now change call to
>>
>>void call( char* );
>>
>>And see what your compiler has to say. If you don't get two
>>incompatibl e type warnings, you haven't turned your warning level high
>>enough.

>
As this conversion is lossless, I don't see why the compiler should
take it upon itself to warn me about it!
>

Keith answered this better than I could.

--
Ian Collins.

[Richard Heathfield]

Re: void * vs char *

Francine.Neary@ googlemail.com said:

On Mar 19, 7:35 pm, Richard Heathfield <r...@see.sig.i nvalidwrote:

>Nevertheless , it represents a considerable gain in correctness over
>printf("%d\n ", p->a), wouldn't you agree?

>
Well, yes :)
>
The whole point of that example was that it was code that used a void
* but wouldn't compile unless you added in an explicit cast.

But it was lousy code. Sorry, but it was. That simply isn't the kind of
place where void * is a win.

Several examples of putting void * to good use can be seen in the
standard library: memcpy, memcmp, memset, qsort and bsearch all spring
to mind.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[Richard Heathfield]

Re: void * vs char *

Ian Collins said:

>

>[...]
>>
>I think you're looking at a copy of the 1990 standard. C99 dropped
>implicit int.
>>
>Yes, "main()" is legal in C90 (Ian was partly mistaken on that
>point), but in my opinion "int main(void)" is better.
>>

Where I'm sitting, C == C99 :)

You must have a very small seat. :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[Ian Collins]

Re: void * vs char *

Francine.Neary@ googlemail.com wrote:

On Mar 19, 7:35 pm, Richard Heathfield <r...@see.sig.i nvalidwrote:
>

>>Nevertheles s, it represents a considerable gain in correctness over
>>printf("%d\n" , p->a), wouldn't you agree?

>
>
Well, yes :)
>
The whole point of that example was that it was code that used a void
* but wouldn't compile unless you added in an explicit cast.
>

But it didn't!

>

>>--

>

*Please* don't quote signatures.

--
Ian Collins.

[Francine.Neary@googlemail.com]

Re: void * vs char *

On Mar 19, 7:59 pm, Richard Heathfield <r...@see.sig.i nvalidwrote:

Francine.Ne...@ googlemail.com said:
>

On Mar 19, 7:35 pm, Richard Heathfield <r...@see.sig.i nvalidwrote:

Nevertheless, it represents a considerable gain in correctness over
printf("%d\n", p->a), wouldn't you agree?

>

Well, yes :)

>

The whole point of that example was that it was code that used a void
* but wouldn't compile unless you added in an explicit cast.

>
But it was lousy code. Sorry, but it was. That simply isn't the kind of
place where void * is a win.

Ease up there! I wasn't submitting it to a good code contest - it was
just an example to illustrate a point, proof-of-context if you like.

Several examples of putting void * to good use can be seen in the
standard library: memcpy, memcmp, memset, qsort and bsearch all spring
to mind.
>
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Francine.Neary@googlemail.com]

Re: void * vs char *

On Mar 19, 8:58 pm, Ian Collins <ian-n...@hotmail.co mwrote:

The whole point of that example was that it was code that used a void
* but wouldn't compile unless you added in an explicit cast.

>
But it didn't!

Didn't what?

*Please* don't quote signatures.

Sorry - I'll try to be careful with that in future.

[Francine.Neary@googlemail.com]

Re: void * vs char *

just an example to illustrate a point, proof-of-context if you like.

Oops meant concept of course.

[Francine.Neary@googlemail.com]

Re: void * vs char *

On Mar 19, 7:33 pm, Keith Thompson <k...@mib.orgwr ote:

You seem to be arguing that the compiler should shut up about implicit
conversions that don't lose any information; in other words, you want
C's type checking to be even weaker than it is. You're certainly
entitled to that opinion, but it's not one many people share. If you
want a generic pointer type, use void*. There are plenty of
mechanisms that let you be sloppy with types if you do it
deliberately; *I* want the compiler to warn me if I do it
accidentally.

That's an interesting way to put it. Maybe that's what's happening -
I've been forced to use Java for the last couple of years, which has
this horrible over-bearing strict typing, so maybe I'm reacting
against that now and trying to push the liberating flexibility that C
gives me...

However, I'm not completely sure it should be the job of the compiler
and not some optional lint tool to pick through my code for places
where I might just have meant something else.

[Ian Collins]

Re: void * vs char *

Francine.Neary@ googlemail.com wrote:

On Mar 19, 8:58 pm, Ian Collins <ian-n...@hotmail.co mwrote:
>

>>>The whole point of that example was that it was code that used a void
>>>* but wouldn't compile unless you added in an explicit cast.

>>
>>But it didn't!

>
>
Didn't what?
>

Require an explicit cast. I used implicit conversion from void*.

--
Ian Collins.

[Richard Heathfield]

Re: void * vs char *

Francine.Neary@ googlemail.com said:

On Mar 19, 7:59 pm, Richard Heathfield <r...@see.sig.i nvalidwrote:

>Francine.Ne... @googlemail.com said:
>>

The whole point of that example was that it was code that used a
void * but wouldn't compile unless you added in an explicit cast.

>>
>But it was lousy code. Sorry, but it was. That simply isn't the kind
>of place where void * is a win.

>
Ease up there! I wasn't submitting it to a good code contest - it was
just an example to illustrate a point, proof-of-context if you like.

Sure, but the point is that it doesn't illustrate your point well,
because it's like saying "screwdrive rs are a waste of time - I tried
hammering a nail in with one and hey, I might as well have used a
hammer". Your illustration did not provide a reason not to use void *.
It just showed that there are circumstances where void * may not be
appropriate - and we already knew that.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

[Francine.Neary@googlemail.com]

Re: void * vs char *

On Mar 19, 9:34 pm, Richard Heathfield <r...@see.sig.i nvalidwrote:

Francine.Ne...@ googlemail.com said:
>

On Mar 19, 7:59 pm, Richard Heathfield <r...@see.sig.i nvalidwrote:

Francine.Ne...@ googlemail.com said:

>

The whole point of that example was that it was code that used a
void * but wouldn't compile unless you added in an explicit cast.

>

But it was lousy code. Sorry, but it was. That simply isn't the kind
of place where void * is a win.

>

Ease up there! I wasn't submitting it to a good code contest - it was
just an example to illustrate a point, proof-of-context if you like.

>
Sure, but the point is that it doesn't illustrate your point well,
because it's like saying "screwdrive rs are a waste of time - I tried
hammering a nail in with one and hey, I might as well have used a
hammer". Your illustration did not provide a reason not to use void *.
It just showed that there are circumstances where void * may not be
appropriate - and we already knew that.

Maybe you're right! I guess the issue I have is that I'm not really
convinced that void * should exist at all. I mean, char * can double
up perfectly well as both a pointer to char and a "generic pointer",
but for some reason if you work with char * you need to do a lot of
extra explicit casting. At the very least, there seems to be a lot of
duplication between the function of void * and char *, whereas I
always think minimality and efficiency is a virtue.

[Francine.Neary@googlemail.com]

Re: void * vs char *

On Mar 19, 9:27 pm, Ian Collins <ian-n...@hotmail.co mwrote:

Francine.Ne...@ googlemail.com wrote:

On Mar 19, 8:58 pm, Ian Collins <ian-n...@hotmail.co mwrote:

>

>>The whole point of that example was that it was code that used a void
>>* but wouldn't compile unless you added in an explicit cast.

>

>But it didn't!

>

Didn't what?

>
Require an explicit cast. I used implicit conversion from void*.

Well, that's true, though the net result was you saved a pair of
parentheses in your source code, and in exchange picked up an extra
pointer to carry round!

[Ian Collins]

Re: void * vs char *

Francine.Neary@ googlemail.com wrote:

On Mar 19, 9:34 pm, Richard Heathfield <r...@see.sig.i nvalidwrote:

>>
>>Sure, but the point is that it doesn't illustrate your point well,
>>because it's like saying "screwdrive rs are a waste of time - I tried
>>hammering a nail in with one and hey, I might as well have used a
>>hammer". Your illustration did not provide a reason not to use void *.
>>It just showed that there are circumstances where void * may not be
>>appropriate - and we already knew that.

>
Maybe you're right! I guess the issue I have is that I'm not really
convinced that void * should exist at all. I mean, char * can double
up perfectly well as both a pointer to char and a "generic pointer",
but for some reason if you work with char * you need to do a lot of
extra explicit casting. At the very least, there seems to be a lot of
duplication between the function of void * and char *, whereas I
always think minimality and efficiency is a virtue.
>

No, void* serves as a generic pointer, to have char* double up (and
don't forget it used to, before void* was added to the language) adds
complexity.

void foo( char* );

Does foo() expect an generic pointer, or does foo() only expect a char*?
void* removes the ambiguity and adds clarity.

Efficiency is completely irrelevant.

--
Ian Collins.

[Ian Collins]

Re: void * vs char *

Francine.Neary@ googlemail.com wrote:

On Mar 19, 9:27 pm, Ian Collins <ian-n...@hotmail.co mwrote:
>

>>Francine.Ne.. .@googlemail.co m wrote:
>>

>>>On Mar 19, 8:58 pm, Ian Collins <ian-n...@hotmail.co mwrote:

>>

>>>>>The whole point of that example was that it was code that used a void
>>>>>* but wouldn't compile unless you added in an explicit cast.

>>

>>>>But it didn't!

>>

>>>Didn't what?

>>
>>Require an explicit cast. I used implicit conversion from void*.

>
Well, that's true, though the net result was you saved a pair of
parentheses in your source code, and in exchange picked up an extra
pointer to carry round!
>

The net result was I was able to use implicit conversion from void* and
didn't have to resort to (explicit, as all casts are) casting.

I'm not sure where you get the issue with the temporary pointer from.
It's just that, a temporary variable. In the trivial example you posted
it is used exactly once, in a more complex case, it would be used
wherever the passed parameter is dereferenced.

--
Ian Collins.

[Al Balmer]

Re: void * vs char *

On 19 Mar 2007 14:13:36 -0700, Francine.Neary@ googlemail.com wrote:

>On Mar 19, 7:33 pm, Keith Thompson <k...@mib.orgwr ote:

>You seem to be arguing that the compiler should shut up about implicit
>conversions that don't lose any information; in other words, you want
>C's type checking to be even weaker than it is. You're certainly
>entitled to that opinion, but it's not one many people share. If you
>want a generic pointer type, use void*. There are plenty of
>mechanisms that let you be sloppy with types if you do it
>deliberately ; *I* want the compiler to warn me if I do it
>accidentally .

>
>That's an interesting way to put it. Maybe that's what's happening -
>I've been forced to use Java for the last couple of years, which has
>this horrible over-bearing strict typing, so maybe I'm reacting
>against that now and trying to push the liberating flexibility that C
>gives me...
>
>However, I'm not completely sure it should be the job of the compiler
>and not some optional lint tool to pick through my code for places
>where I might just have meant something else.

With most compilers, the "linting" level is controllable. Find a set
of switches you like. However, keep in mind that compilers actually
aren't always smart enough to distinguish warnings from errors.

--
Al Balmer
Sun City, AZ