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

[Nobody]

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

Really odd in my book.

You can have a pointer to void, but you can't have a void. Thus a
reference to void would be meaningless; what could it refer to?

 

[Skybuck Flying]

How it works is irrelevant.

The example was about void.

Therefore the int example was wrong to begin with.

Any further discussion about it is useless.

And it wasn't even about variable declarations but parameters.

Bye,
Skybuck.

 

[Skybuck Flying]

This just makes it worse.

This means the call by reference call has to be written as:

void test (void ** data);

test( p );

which would be the same as the other example.

That's a whole lot of stars for something which is really easily implemented
in pascal and does exactly the same thing and a whole lot user friendly.

No need to type *data everywhere.

You C programmers just like making things unnecessarily difficult for
yourself, or you don't even know it... which makes you kinda look retarded.

Give pascal a try if you never haven't ! =D

Bye,
Skybuck =D

 

[Skybuck Flying]

"Nobody" wrote in message

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

Really odd in my book.

"
You can have a pointer to void, but you can't have a void. Thus a
reference to void would be meaningless; what could it refer to?
"

Same thing as the pointer ofcourse, duh !

C/C++ just sucks and is being inconsistent ! LOL.

Bye,
Skybuck =D

 

[Skybuck Flying]

I did cross post it to c++.

Take your own conclusions.

Bye,
Skybuck.

 

[Skybuck Flying]

Also what do you think the ++ hint at in c++ ?!?

Behehehehehehehe.

You response is so stupid I am not even going to respond to it because it's
far below my level of what I will expect.

Bye,
Skybuck.

 

[Jamie]

& 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

Actually, I've done C/C++ for years. You may have a little miss
understanding here.

C++ is everything C can do with added fluff, which is why they gave
it the "++" extension in the first place.

C++ is an extension to C language, which is why you see the C/C++ all
over the place. They are not two different languages. C++ has the Class
model and a few other things that stands above C but it can also do what
C does.

I wouldn't use a C++ compiler that refused to support the basic
operations of C language..

Sorry, but so many get steered off on the wrong road when it comes to
the history of languages..

It's the same in delphi land. Delphi isn't the language, it's the
package over all, the language base is enhanced Pascal and thus follows
the stream of that. Just because it has classes,objects and others that
Pascal did not have, does not change the fact that it is still a Pascal
oriented language and C++ is still a C oriented language.

Jamie

 

[Skybuck Flying]

Well for once in my life, you actually make me happy ! =D

Bye,
Skybuck =D

"Jamie" wrote in message

& 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

Actually, I've done C/C++ for years. You may have a little miss
understanding here.

C++ is everything C can do with added fluff, which is why they gave
it the "++" extension in the first place.

C++ is an extension to C language, which is why you see the C/C++ all
over the place. They are not two different languages. C++ has the Class
model and a few other things that stands above C but it can also do what
C does.

I wouldn't use a C++ compiler that refused to support the basic
operations of C language..

Sorry, but so many get steered off on the wrong road when it comes to
the history of languages..

It's the same in delphi land. Delphi isn't the language, it's the
package over all, the language base is enhanced Pascal and thus follows
the stream of that. Just because it has classes,objects and others that
Pascal did not have, does not change the fact that it is still a Pascal
oriented language and C++ is still a C oriented language.

Jamie

 

[James Kuyper]

Actually, I've done C/C++ for years. You may have a little miss
understanding here.

C++ is everything C can do with added fluff, which is why they gave
it the "++" extension in the first place.

No, it is not. C has many features that render it incompatible with C,
and not merely an extension of it. See Annex C of the the C++ standard
for a list. In the meantime, C has gone it's own way, adding many
features in C99 that are incompatible with C++ (while adding a few
features that make it more compatible).

C++ is an extension to C language, which is why you see the C/C++ all
over the place. They are not two different languages. C++ has the Class
model and a few other things that stands above C but it can also do what
C does.

I wouldn't use a C++ compiler that refused to support the basic
operations of C language..

The following is very carefully designed to make many different points
in a program that is as small as possible. I make no claim that it is an
example of good programming practice

It is syntactically valid code in both C and C++, conforms strictly to
the C99 standard, and is well-formed code according to both the C++98
and C++03 standards. It's behavior under C90 is technically undefined,
but only by reason of it's use of __cplusplus, an identifier which a C90
compiler could, in principle, have reserved for it's own incompatible
usage - but such compilers are rare, and probably non-existent.

You can compile and link both modules as C code, or as C++ code; the
resulting executables are guaranteed by the applicable standards to exit
with an failure status, for two entirely different sets of reasons,
depending upon which language is used (note that many compilers
automatically infer the language to be used from the extension on the
filename - you might need to rename the files to get them to actually
compile in one language rather than the other).

If you compile the first module with C, and the second with C++, it is
guaranteed to return a successful exit status. If C++ were really just
an extension to C, then what I've said about how this program's behavior
varies with the programming language would be impossible.

shared.h:
=========
#ifndef SHARED_H
#define SHARED_H

extern char tag;
extern int enumer[2];

typedef void voidvoid(void);

int Cnmtyp(void);
int Cfunc(voidvoid*);

#endif

First module:
=============
#ifdef __cplusplus
extern "C" {
#endif

#include "shared.h"

char tag = 0;

static int hidden(voidvoid *pfunc)
{
(*pfunc)();
tag = sizeof 'C' == sizeof(int);
return Cnmtyp() && enumer[0] && enumer[1];
}

int Cfunc(voidvoid* pfunc)
{
struct tag
{
enum { enumer, other } in;
int integer;
} out;

out.integer = sizeof(tag) == 1 && sizeof(enumer) == sizeof out.in;

return hidden(pfunc) && out.integer;
}

#ifdef __cplusplus
}
#endif

Second module:
==============
#ifdef __cplusplus
extern "C" {
#endif

#include "shared.h"

int enumer[2] = {0, 1};

static void Cppname_Cpptype(void)
{
enumer[0] = sizeof 'C' == 1;
return;
}

#ifdef __cplusplus
}
#endif

int Cnmtyp(void)
{
struct tag
{
enum { enumer, other } in;
int integer;
} out;

out.integer = sizeof(enumer) == 2 * sizeof(int);

return out.integer && sizeof(tag) == sizeof out;
}

static voidvoid Cppname_Ctype;

static void Cppname_Ctype(void) {
Cppname_Cpptype();
}

int main(void) {
return Cfunc(&Cppname_Ctype) && tag;
}

As an exercise for the student: explain precisely why three different
conditional expressions in the above code are guaranteed to have
different values in C and C++, and why two other conditionals will have
different values except in the unlikely case that sizeof(int)==1.

 

[Stephen Sprunk]

"Nobody" wrote in message


"
You can have a pointer to void, but you can't have a void. Thus a
reference to void would be meaningless; what could it refer to?
"

Same thing as the pointer ofcourse, duh !

C/C++ just sucks and is being inconsistent ! LOL.

There is no such language as C/C++.

C does not have "references", so they are off-topic here.

If you wish to discuss C++, go to a C++ newsgroup.

S

 

[Stephen Sprunk]

Actually, I've done C/C++ for years. You may have a little miss
understanding here.

C++ is everything C can do with added fluff, which is why they gave it
the "++" extension in the first place.

They're still different languages.

C++ is an extension to C language,

It started out that way, but it is now specified in a separate standard
and is now sufficiently different that it isn't the same thing. In
fact, there is valid C code that is not valid C++ code--or has a
different meaning entirely.

I wouldn't use a C++ compiler that refused to support the basic
operations of C language..

Most, if not all, C++ compilers have a separate mode capable of
compiling C. That doesn't they're the same language, though. In fact,
that one has to invoke a separate mode is strong evidence they are
different languages. One of the most popular compilers, GCC, can also
compile Objective C, Java, Fortran and Ada; that doesn't mean those are
also all the same language.

Just because [Delphi] has classes,objects and others that Pascal did
not have, does not change the fact that it is still a Pascal oriented
language and C++ is still a C oriented language.

I am not disputing that C++ is a C-like or C-based language. So are C#
and Java, for that matter. They're still separate languages.

It's been too long since I've used Delphi to comment on its relation to
Pascal. I don't see what relevance that has to a discussion about
whether there is a single "C/C++" language, though.

S

 

[jacob navia]

Le 19/06/11 20:25, Stephen Sprunk a écrit :

C does not have "references", so they are off-topic here.

I introduced references into lcc-win because they are useful.
Beyond this guy trolling here, his discussion allowed me to plug a hole
in my implementation, you could actually write

int fn(void &foo);

because lcc-win did not test explicitly for a void pointer.

Now I wonder what other problems may be lurking in my implementation there.


References allow you to use a much safer kind of pointers than plain
ones. They must be initialized at their definition point, and they can't
change afterwards, they always point to the same object.

Now, if you get a reference into a function it is NOT necessary to test
for NULL since references can never be NULL.

This is obviously an extension but I think it is justified.

 

[Stephen Sprunk]

This just makes it worse.

What just makes what worse? You didn't quote anything, so we don't know
the context of your statement.

This means the call by reference call has to be written as:

void test (void ** data);

test( p );

That depends on what you're trying to accomplish.

which would be the same as the other example.

What other example?

You C programmers just like making things unnecessarily difficult for
yourself, or you don't even know it... which makes you kinda look retarded.

It only looks difficult to you because you (quite obviously) don't
understand it.

Give pascal a try if you never haven't ! =D

My first real language (IMHO, BASIC doesn't count) was Pascal, and I was
a professional Delphi programmer for a while. I resisted learning C for
years, but once I finally understood it, I never went back.

S

 

[Stephen Sprunk]

How it works is irrelevant.

How what works?

The example was about void.

What example?

Therefore the int example was wrong to begin with.

What int example?

Any further discussion about it is useless.

It's certainly useless to try to discuss things with someone who doesn't
quote articles they're replying to.

And it wasn't even about variable declarations but parameters.

What wasn't?

S

 

[Stephen Sprunk]

Le 19/06/11 20:25, Stephen Sprunk a écrit :

I introduced references into lcc-win because they are useful.

Useful or not, they are not C.

S

 

[Shao Miller]

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

It looks to me like you are using Windows.

It's fairly common in Windows for API functions to return an error code
with an integer type, then to work with other objects through pointers.

As a silly example, instead of:

void * malloc(size_t);

You might be asked to use something more like:

int AllocateObject(void *, size_t);

With 'malloc', it either returns a null pointer or it doesn't. With
this 'AllocateObject', the return value might represent one of:
- Success; the pointer has been populated
- Insufficient memory
- Memory quota exceeded
- Invalid size specified
- etc.

On Windows, I believe that all pointer representations are the same (per
running OS), so you can:

int * ip;
int status;

status = AllocateObject(&ip, 10);
/* Check 'status'... */

and 'AllocateObject' will have no problem manipulating 'ip' without
knowing its original type. But that's outside of Standard C.

 

[Tim Rentsch]

C has many features that render it incompatible with C, [snip]

Aha! Now we know why so many new students of C keep
getting compilation errors...

 

[Shao Miller]

A nice attempt at a twist.

But your twist will fail.

PointerType foo, bar;

Done.

...
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.

And in Windows drivers (and possibly elsewhere in Windows C
programming), it's quite popular to use 'typedef's to produce pointer types.

typedef struct _SOME_STRUCT SOME_STRUCT, * PSOME_STRUCT;

(Though I wish they would have avoided a naming convention of an
underscore followed by a capital letter!)

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.

Poster Angel didn't state that. They stated (it's up above) that:

int* foo, bar;

"will not have the effect you think it does." See that semi-colon,
there? See that it has 'int' and not 'void'?

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;

See that you are using 'void' here and not 'int'?

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

Because apperently you lazy [...] never test anything.

That's a pretty general and nasty thing to post, in my opinion.

In my reading of the exchange, it seemed that you thought that the
positioning of the "pointer star" relative to the whitespace had
something to do with the program's behaviour or interpretation. That
subject matter frequently leads (in my experience) to discussion of
where the "pointer star" "ought" to be in different contexts...

So perhaps it's easier to avoid such discussion and use:

void test(void * data)

and:

int * foo, * bar;

Now in the former, you get your:

void test(void * data)
type--^^^^-^ ^^^^--parameter name

and in the latter you get your:

int * foo, * bar;
^^^-^--type

int * foo, * bar;
^^^--parameter name

int * foo, * bar;
^^^--------^--type

int * foo, * bar;
^^^--parameter name

(By the way, it's a "cast" in C, not a "typecast". )

 

[Keith Thompson]

In my reading of the exchange, it seemed that you thought that the
positioning of the "pointer star" relative to the whitespace had
something to do with the program's behaviour or interpretation. That
subject matter frequently leads (in my experience) to discussion of
where the "pointer star" "ought" to be in different contexts...

So perhaps it's easier to avoid such discussion and use:

void test(void * data)

and:

int * foo, * bar;

[...]

That might be a reasonable way to avoid debates about where the "*"
should go.

It's not a good way to deal with the problem of not knowing that the
placement doesn't matter to the compiler. The solution to that problem
is to *learn* that the placement doesn't matter to the compiler.

(This might not be a practical solution for the original poster.)

 

[Shao Miller]

I introduced references into lcc-win because they are useful.
Beyond this guy trolling here, his discussion allowed me to plug a hole
in my implementation, you could actually write

int fn(void &foo);

because lcc-win did not test explicitly for a void pointer.

Now I wonder what other problems may be lurking in my implementation there.

There are other incomplete object types such as:

typedef char foo[];
struct bar;

Since an object of the former cannot be declared, I guess you wouldn't
have a problem, there.

Since an object of the latter cannot be declared until 'struct bar' is
defined, I guess you wouldn't have a problem, there.