test(void *data) vs test(void &data)

[Keith Thompson]

I just came across something strange.

Prototypes for routines:

1: void test(void *data)
2: void test(void &data)

The first one does compile in visual studio 2010 and the second does not.

They both seem conceptually the same, like untyped variable data in Delphi,
yet the first one is allowed and the second is not allowed.

Isn't that strange ?!
No.

Seems like case 2 is not yet implemented, either in the c/c++ language rules
or in the compiler ?!

The second form appears to be a reference parameter, a feature that
C++ has and C doesn't. C and C++ are two different languages.

If you didn't know that, I suggest that your vague opinion that they
"both seem conceptually the same" isn't worth much.

But if you really want to know why something doesn't compile,
you should post a complete source file along with the actual error
messages.

 

[Skybuck Flying]

This also seemed to be a very special api

Therefore I am going to give it a very special treatment ! =D LOL.

Problem is probably going to be solved nicely ! =D

Bye,
Skybuck =)

 

[Skybuck Flying]

So are you claiming that:

void test( void &data )
{
}

Does compile in either C or C++ but does not compile in either C or C++ ?

Just stuff it into a console program yourself.

Full source not needed.

Bye,
Skybuck.

 

[Skybuck Flying]

"Angel" wrote in message
["Followup-To:" header set to comp.lang.c.]

Ok,

Now I understand sort of... but it's a bit confusing... I guess this
pretty
much proves C is a bad language.

It's all about where the space is placed.

I guess the function should be written and interpreted as follows:

1: void test( void* data )

instead of

2: void test( void *data )

Interpretation of 1: call by value passing a void pointer.

Interpretation of 2: call by reference passing a void (which is not
allowed).

In C, all function parameters are always passed by value. It's up to the
programmer to pass a pointer value to the function if callback is
needed.

One could also argue that C programmer who write 2: test is a bad
programmer

"
Actually 2 is the better form, because

int* foo, bar;

will not have the effect you think it does.
"

A nice attempt at a twist.

But your twist will fail.

PointerType foo, bar;

Done.

Same as:

var
a,b : ^integer;

Type is behind the colon :.

I shall point this out to the programmer in question

"
If you don't actually know C, I'd recommend against that. You'll make
yourself look like a fool.
"

Only you made yourself look like a fool, by trying to twist it to something
it was not.

It was parameter of type.

Not

pointer to type, variable of type.

Bye,
Skybuck.

 

[James]

So are you claiming that:

void test( void &data )
{
}

Does compile in either C or C++ but does not compile in either C or C++ ?

It is C++.

[...]

 

[Skybuck Flying]

Just to put the last nail in your twist coffin.

void test( void *data, data2 )

as you suggested doesn't even compile which proves your twisting is
nonsense.

And just to add that extra nail into your twisting coffin so your zombie
doesn't come out:

Even if it was a variable declaration it's not allowed:

void *p, p2;

Why am I not surprised at all these C programmers assumptions and flaws ?!?

Because apperently you lazy fucks never test anything.

Here is some 15 year programming experience advice:

1. Every 10 lines of code I read contains at least 1 bug, easily fixeable
none the less.

2. You don't know if it works until you test it.

Concerning 1 I am either a motherfokking retard, or simply human.

I assure you it's the second one, if you don't believe that then oh my god
do you suck and do you still have a lot to learn.

But you don't have to... companies don't care about your bugs as long as the
software is done on time.

As long as people buy into it, they'll buy it and discover the bugs later.

Bye,
Skybuck.

 

[Nobody]

So are you claiming that:

void test( void &data )
{
}

Does compile in either C or C++ but does not compile in either C or C++ ?

In C++, "&" as a type qualifier is a reference, but you can't have a
reference to "void", so the above is invalid.

In C "&" as a type qualifier is invalid.

So the above isn't valid in either language.

 

[Skybuck Flying]

Now that that rotten zombie corpse of yours is firmly nailed into it's
coffin, there's still a little hole where it's stinking plant might grow
threw lol.

Gonna nail that little hole too.

There was some sense in what I wrote:

C typecasts require to be written as (int *)

So apperently C does see (int *) as a type.

Bye,
Skybuck.

 

[Skybuck Flying]

Though there could still be a tiny little slit where your stinking rotting
zombie body odor might leak through, so gonna nail that slit too ! =D

Now that that rotten zombie corpse of yours is firmly nailed into it's
coffin, there's still a little hole where it's stinking plant might grow
threw lol.

Gonna nail that little hole too.

There was some sense in what I wrote:

C typecasts require to be written as (int *)

So apperently C does see (int *) as a type.

*new* And that's why (void *) can also be considered a type.

Bye,
Skybuck.

 

[Skybuck Flying]

"James" wrote in message

So are you claiming that:

void test( void &data )
{
}

Does compile in either C or C++ but does not compile in either C or C++ ?

"
It is C++.
"

Right so type * and type & are almost conceptually the same.

type * can be used for "call by reference behaviour via pointers" (which
apperently is call by value via pointers)

type & can be used for "call by reference" ???

Does that mean & is truely call by reference ? hmmm....

Bye,
Skybuck.

 

[Skybuck Flying]

"Nobody" wrote in message

So are you claiming that:

void test( void &data )
{
}

Does compile in either C or C++ but does not compile in either C or C++ ?

"
In C++, "&" as a type qualifier is a reference, but you can't have a
reference to "void", so the above is invalid.
"

A pointer is a reference.

Do you think that's kinda odd ?

A pointer to void is allowed, but a reference to a void is not allowed ?!?

Really odd in my book.

<snip drivel>

Bye,
Skybuck.

 

[jacob navia]

Le 18/06/11 22:34, Skybuck Flying a écrit :

Hello,

I just came across something strange.

Prototypes for routines:

1: void test(void *data)
2: void test(void &data)

The first one does compile in visual studio 2010 and the second does not.

They both seem conceptually the same, like untyped variable data in
Delphi, yet the first one is allowed and the second is not allowed.

Isn't that strange ?!

Seems like case 2 is not yet implemented, either in the c/c++ language
rules or in the compiler ?!

Bye,
Skybuck.

You shouldn't be able to define a reference to void. Even if lcc-win
supports references, I should NOT compile your code... an explicit test
for the void type was missing.

Fixed.

Thanks for the discussion.

 

[Paul]

So are you claiming that:

void test( void &data )
{
}

Does compile in either C or C++ but does not compile in either C or C++ ?

Just stuff it into a console program yourself.

Full source not needed.

No

void test( void* &data){;}

 

[jacob navia]

Le 19/06/11 06:49, Skybuck Flying a écrit :

in message



"
In C++, "&" as a type qualifier is a reference, but you can't have a
reference to "void", so the above is invalid.
"

A pointer is a reference.

Do you think that's kinda odd ?

A pointer to void is allowed, but a reference to a void is not allowed ?!?

Really odd in my book.

<snip drivel>

Bye,
Skybuck.

This is clear from the definition of a reference. A reference is a
pointer to an existing object that must exist. Therefore a reference to
an inexistent object can't exist.

Plain logic. In your specific case, you can't build a void object,
so you can't have a reference to one.

On the other hand, pointers can be NULL or point to incomplete objects,
they haven't any of the constraints of references. References and
pointers are surely NOT the same.

 

[Stephen Sprunk]

Just to put the last nail in your twist coffin.

void test( void *data, data2 )

as you suggested doesn't even compile which proves your twisting is
nonsense.

Since you didn't quote the article you're replying to, we have no idea
whether that's actually what was suggested, nor who said it.

Any competent C programmer will know the above won't work.

And just to add that extra nail into your twisting coffin so your zombie
doesn't come out:

Even if it was a variable declaration it's not allowed:

void *p, p2;

What "Angel" discussed was this:

int* foo, bar;

This is near-universally considered bad style specifically because it is
misleading. The type of foo is (int *) but the type of bar is (int);
the * binds to the right, not to the left. When written this way:

int *foo, bar;

it is more obvious _to humans_ what the result will be, even though
they're identical to the compiler. Returning to your line at top:

void test( void *data, data2 )

This declares a function returning void taking two parameters, one named
data of type (void *) and one named data2 of type (void). An object of
type (void) is invalid. If you want two parameters of type (void *),
you need to write this:

void test( void *data, *data2 )

Why am I not surprised at all these C programmers assumptions and flaws ?!?

It is your inability to read, or at least to understand what you read,
that is flawed.

S

 

[Stephen Sprunk]

"James" wrote in message

"
It is C++.
"

Right so type * and type & are almost conceptually the same.

They may or may not be in C++; that is a different language discussed in
a different newsgroup.

They are not the same in C, since one is valid and the other is not.

type & can be used for "call by reference" ???

Not in C. If you have a question about C++, ask in a C++ newsgroup.

S

 

[Stephen Sprunk]

"Nobody" wrote in message


"
In C++, "&" as a type qualifier is a reference, but you can't have a
reference to "void", so the above is invalid.
"

A pointer is a reference.

C does not have "reference" types. C++ may have such, but that is a
different language discussed in a different newsgroup.

C does have the concept of "pass by reference", but that just means that
a pointer (not a "reference") to an object is passed instead of the
object itself. The C++ folks might use different terminology, but that
is better discussed in a C++ newsgroup.

S

 

[Stephen Sprunk]

This is clear from the definition of a reference. A reference is a
pointer to an existing object that must exist. Therefore a reference to
an inexistent object can't exist.

Jacob, please do not post off-topic material. If you must feed the
troll, at least do so where it is topical.

S

 

[Stephen Sprunk]

I just came across something strange.

Prototypes for routines:

1: void test(void *data)
2: void test(void &data)

The first one does compile in visual studio 2010 and the second does not.

They both seem conceptually the same, like untyped variable data in
Delphi, yet the first one is allowed and the second is not allowed.

Isn't that strange ?!

Seems like case 2 is not yet implemented, either in the c/c++ language
rules or in the compiler ?!

& is not a valid type specifier in C, period.

It might or might not be valid in C++, but since you haven't
cross-posted this to a C++ newsgroup, responding to that would be off-topic.

C and C++ are different languages. There is no language called "C/C++".

S

 

[Stephen Sprunk]

Now I understand sort of... but it's a bit confusing... I guess this
pretty much proves C is a bad language.

No, this just proves you don't understand it and therefore have no
standing to make any judgment about how "bad" it might be.

It's all about where the space is placed.

I guess the function should be written and interpreted as follows:

1: void test( void* data )

instead of

2: void test( void *data )

Interpretation of 1: call by value passing a void pointer.

Interpretation of 2: call by reference passing a void (which is not
allowed).

Incorrect. The two are identical: they both declare a function
returning void with one parameter named data of type pointer-to-void.

One could also argue that C programmer who write 2: test is a bad
programmer

Actually, the latter is better style. If you don't understand why,
that's just more evidence that you don't understand C.

S