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

[Skybuck Flying]

I do understand it now.

I still think it sucks bad.

Bye,
Skybuck.

 

[Skybuck Flying]

Hahahahaha !

So even if it were true what you were saying then that would mean

C and C++ are no longer compatible !

What a joke ! =D

Bye,
Skybuck =D

 

[Skybuck Flying]

Stop pretending dumb.

Plenty of examples in this thread, pick any one of them.

And then if it doesn't suit my post pick the previous one, and sooner or
later you will arrive where the rest has already arrived long ago.

Bye,
Skybuck.

 

[Skybuck Flying]

int void **** ding in ass;

^ It doesn't have the effect you think it does lol.

Anybody can post none working code and then go claim something stupid like
above.

In all my life of discussing I rarely give none compiling examples unless
there is a reason for it.

And in this case "void" is the reason.

Any discussion about anything else is irrelevant.

I know very damn well how an int works.

Bye,
Skybuck.

 

[Skybuck Flying]

Ofcourse I already know that.

Adding spaces can clearify meaning and in C it's definetly necessary.

void ** * **** ** * * *** **** *** ********* * ********* **** *** &;

^ Too many spaces ain't too good either LOL.

Bye,
Skybuck.

 

[Skybuck Flying]

No they are not off topic fool.

Any language idea can be discussed relating to C

Because it can always be added to the language.

I estimate your IQ to be zero.

You just a troll pretending to be dumb.

Stop it.

Anybody responding seriously to you is an even bigger fool.

Bye,
Skybuck.

 

[Shao Miller]

int void [...];

^ It doesn't have the effect you think it does lol.

I find that response rather unpleasant to read.

Anybody can post none working code and then go claim something stupid
like above.

Claim _what_? That it's possible that you misunderstood the point of
someone's post? I don't think there's anything stupid about such a claim.

In all my life of discussing I rarely give none compiling examples
unless there is a reason for it.

So wrap poster Angel's code with the obvious omission, then. Like this:

int main(void) {
int* foo, bar;
return 0;
}

now it compiles. If you're going to suggest that

void test( void* data )

be interpreted differently, in C, than:

void test( void *data )

then you might expect some feed-back from C programmers, seeing as how
the only major difference is style.

If you further add that C programmers using the latter form are "bad
programmer"s then you might expect some feed-back from C programmers who
prefer the latter form.

And in this case "void" is the reason.

You're not the first to "understand sort of... but it's a bit confusing..."

Please consider that many of Microsoft's C API documents follow a
particular style/convention, something like:

STATUS SomeApiFunc(
__in FOO Foo,
__in BAR Bar,
__in_opt PBAZ Baz,
__inout EEP *Eep,
__out PVOID *Object
);

Where the convention appears to be that the "pointer star" is reserved
for a similar use to C++'s "by-reference" '&' symbol. (I don't remember
the precise C++ terminology.)

In the example above, the 'Baz' parameter is really a 'BAZ **'. But the
function is not going to modify whatever 'PBAZ'-typed argument the
caller passes, so there's no need to pass "a reference." If anything,
the function might inspect whatever 'BAZ' the 'PBAZ' points to.

In the example above, the function will be working with an 'EEP' that
the caller passes. Since the 'EEP' itself might be modified, we see the
"pointer star" used for the purpose of passing "a reference" to become
the 'Eep' parameter.

In the example above, the 'Object' parameter is really a 'VOID **', but
the function will have a 'VOID *' ('PVOID') and it's that object itself
which will be populated by the function, so again we see the "pointer
star" used for the purpose of passing "a reference" to become the
'Object' parameter.

In this way, the convention has a type indicating an object type, even
if it is a pointer type, all in one identifier on the left. Then it's
followed by a space, then the presence of "pointer star" suggests that
the caller is passing an object "by reference." I must assume that this
convention has rationale including interoperability simplification with
C++'s "by-reference" feature, but I could be mistaken.

STATUS SomeFunc(PBAZ Baz) {
STATUS Status;
FOO Foo;
BAR Bar;
EEP Eep;
PVOID Object;

/* Initialize 'Foo', 'Bar', 'Eep' */
/* ... */
Status = SomeApiFunc(
Foo,
Bar,
Baz,
&Eep,
&Object
);
/* Check 'Status' */
/* ... */
/*
* If the call succeeded, 'Eep' might have
* been modified and 'Object' should have been
* populated for us.
*/
/* Do other stuff */
/* ... */
return Status;
}

But anyway, that's a particular convention that has nothing to do with
any C Standard that I know of.

Any discussion about anything else is irrelevant.

By using text including "sort of," "confusing," "proves," "bad," "should
be," etc., I'd guess you're going to get some "irrelevant" discussion in
response. Did you anticipate such responses or did you fail to
anticipate such responses, or don't you agree?

I know very damn well how an int works.

Where did you get the idea that that was in dispute?

Some additional references for the far-left markups:
[1] http://msdn.microsoft.com/en-us/library/ff550230(v=VS.85).aspx
[2] http://msdn.microsoft.com/en-us/library/ms235402.aspx

 

[Kleuskes & Moos]

Where did you get the idea that that was in dispute?

I don't think he has. I get the strong impression his only reason to
post here (or indeed anywhere else) is to annoy people.

 

[Shao Miller]

In the example above, the 'Baz' parameter is really a 'BAZ **'. But the
function is not going to modify whatever 'PBAZ'-typed argument the
caller passes, so there's no need to pass "a reference." If anything,
the function might inspect whatever 'BAZ' the 'PBAZ' points to.

Oops! No it wasn't. 'Baz' is really a 'BAZ *'. My mistake; one too
many "pointer stars."

 

[Shao Miller]

I don't think he has. I get the strong impression his only reason to
post here (or indeed anywhere else) is to annoy people.

Yesterday, Google appeared to yield:
- A "BoxifyMe" contest, in which Mr. James Dow Allen participated and
appears to have been annoyed.
- A YouTube video for a video game with tanks.
- Participation in SourceForge since 2001: With a free Pascal compiler
and an IDE.*
- Fondness of the following smiley: =D
- Self-followed-up posts in regards to a strategy to defeat video game
cheaters.

* 1/5 seemed to allow for a time investment in responding... Heh.

 

[Skybuck Flying]

I shall round up/put a closure on this topic with one last final nice
posting (perhaps for noobies having to choose a language or experts trying
to understand the differences between the languages):
(Unless more reactions/replies come into it but I would prefer if there
weren't any because I like to close this topic now.)

The difference is actually:

1. Pascal has call by value and call by reference.
2. C only has call by value.

Because of limitation 2, C programmers use the pointer trick to pass the
address of a variable so it can be changed inside the routine, example:

1. C call by value (default):

void test( int a )
{
a = 5; // after routine exists, value is lost.
}

test( b );

2. C call by value (reference trick):

void test( int *a ) <- pointer to variable of integer trick.
{
*a = 5;
}

test( &b ); // <- address of variable trick.

For noobies/novice programmers this makes C a bad language since
noobies/novice programmers are still learning to design software codes and
will often need to change call by value to call by reference or vice versa
and then it becomes a hurdle to change all these call sites, not mention
confusion.

For experienced programmers it's also a reall burden to use * everywhere and
& everywhere, everywhere reference comes into play.

Passing real pointers and working with them becomes even more tricky and
requires even more stars/asterixes.

A very bad problem which was easily solved in pascal:

procedure test( var a : integer );
begin
a := 5;
end;

test( a );

^ No stupid symbols needed ! Much user friendly and pretty much does the
same thing.

Why make things more difficult then absolutely necessary huh ?! =D

Only thing I can imagine is very very very maybe it's easier to write a
"call by value compiler" than a "call by reference compiler" ?!? But does
sound a bit like bullshit to me ?!

Bye,
Skybuck =D

 

[Stephen Sprunk]

No they are not off topic fool.

Any language idea can be discussed relating to C

Wrong. This newsgroup is about C; there are other newsgroups for other
languages.

Because it can always be added to the language.

If you want to discuss adding references to C, the appropriate place is
comp.std.c.

I estimate your IQ to be zero.

Then you would be wrong.

You just a troll pretending to be dumb.

Pot, meet kettle.

S

 

[Stephen Sprunk]

Hahahahaha !

So even if it were true what you were saying then that would mean

Even if what were true? Since you didn't quote any context, I don't
know what you're referring to.

C and C++ are no longer compatible !

That is correct. There is a subset of both languages that is valid in
both, and a smaller subset that even means the same thing. However,
some C code is not valid C++ code, and a lot of C++ code is not valid C
code. That's why they're different languages--and why C++ is not merely
an "extension" of C as you claim.

S

 

[Stephen Sprunk]

I shall round up/put a closure on this topic with one last final nice
posting (perhaps for noobies having to choose a language or experts
trying to understand the differences between the languages):
(Unless more reactions/replies come into it but I would prefer if
there weren't any because I like to close this topic now.)

The difference is actually:

1. Pascal has call by value and call by reference.
2. C only has call by value.

Because of limitation 2, C programmers use the pointer trick to pass the
address of a variable so it can be changed inside the routine, ...

That is roughly correct.

For noobies/novice programmers this makes C a bad language since
noobies/novice programmers are still learning to design software codes and
will often need to change call by value to call by reference or vice versa
and then it becomes a hurdle to change all these call sites, not mention
confusion.

"Bad" is in the eye of the beholder. It's how C works. Indeed, truly
understanding pointers is often the hardest thing about learning C.
However, they're a core feature of the language, and the sooner you
start learning, the sooner you'll "get" how C works.

For experienced programmers it's also a reall burden to use * everywhere
and & everywhere, everywhere reference comes into play.

An experienced programmer should rarely have problems with them, since
part of gaining said experience is learning to use pointers. That's
where the real power of C comes from.

Why make things more difficult then absolutely necessary huh ?! =D

The basic philosophy of C is to expose the low-level operation of the
machine as much as possible and let the programmer, if desired, build
higher-level operations. If you only want to deal with higher-level
operations, then another language is probably more appropriate.

Only thing I can imagine is very very very maybe it's easier to write a
"call by value compiler" than a "call by reference compiler" ?!? But does
sound a bit like bullshit to me ?!

One might consider what would be required to add "references" to a C
compiler. To borrow the syntax from C++, one would have this:

void test(int &a) {
a = 5;
}
....
int b = 0;
test(b); // b==5 after call returns

However, to implement this, the reality is that the compiler would end
up producing identical output to what it would produce if it were given
this:

void test(int *a) {
*a = 5;
}
....
int b = 0;
test(&b); // b==5 after call returns

So, the only advantage of allowing the former is that it is arguably
easier for novices to understand, but it doesn't actually add anything
to the language--and it breaks the decades-old rule that functions
cannot change their parameters, which means programmers must closely
examine the declaration of every function they call to determine whether
or not it uses references.

C++ had a good reason to add this syntactical sugar: to avoid
(potentially expensive) calls to copy constructors for pass-by-value
arguments. That reason does not apply to C; all that would be left is
pure syntactical sugar, and that goes against the philosophy above.

Also, if deceiving the caller as above is desired for some reason, you
_could_ accomplish that with a (rather evil) macro:

#define test(x) (test)(&x)
void (test)(int *a) {
*a = 5;
}
....
int b = 0;
test(b); // b==5 after call returns

However, that should never survive any decent code review, and I would
seriously question hiring someone who thought it was a good idea.

S

 

[Paul N]

No they are not off topic fool.

Any language idea can be discussed relating to C

Because it can always be added to the language.

I used to think that comp.std.c was for questions like "What does the
standard say about ... ?" and comp.lang.c was more suited for qustions
like "Wouldn't it be nice if C had feature ... ?". It was something of
a surprise to discover they are almost exactly the opposite way round.

I estimate your IQ to be zero.

You just a troll pretending to be dumb.

Some contradiction surely?

 

[Skybuck Flying]

Please stop the nonsense.

Call by reference in pascal has huge adventages compared to C.

You accidently delete one little asterix somewhere and you have a crisis


Bye,
Skybuck =D

 

[Skybuck Flying]

No this just means C/C++ is broken.

Find another language before it breaks your code even more !

Bye,
Skybuck =D

 

[Stephen Sprunk]

Call by reference in pascal has huge adventages compared to C.

Only for those, such as you, who don't really understand C.

You accidently delete one little asterix somewhere and you have a crisis

No, if you accidentally delete one little asterisk someone, the compiler
warns you of a type mismatch, and you fix that and move on.

S

 

[Mark Storkamp]

Please stop the nonsense.

Call by reference in pascal has huge adventages compared to C.

You accidently delete one little asterix somewhere and you have a crisis

I want one of those languages where if you accidently delete something
the compiler guesses what you meant and fixes it for you.

Some people just are not able to grasp (grok?) C well enough to
effectively program with it. Others are not meant to program at all.

 

[Arivald]

W dniu 2011-06-20 20:51, Stephen Sprunk pisze:
No, there is no references in pascal. There are constructs which works
like C++ reference, but under many different names.

For example, parameters passed using "var" (always) and "const"
(possibly, if it is faster than non-reference pasing) are passed by
reference. Specifically only pointer to variable is passed.
Sometimes this passing methods are called "passing by reference",
although it is not exactly correct.

Objects (TObject descandants), string, Variant and other automated types
are references itself. They are passed by value (if without "var" or
"const"), but because they are references, it effectively works like
passing by reference.

Yes and no.
Passed pointer is value, but it is also reference to other value.

It is no limitation. it is no trick! It is fundamental way how computer
programs works! In assembler You also can pass copy of value, or pointer
to same value.

"Bad" is in the eye of the beholder. It's how C works. Indeed, truly
understanding pointers is often the hardest thing about learning C.
However, they're a core feature of the language, and the sooner you
start learning, the sooner you'll "get" how C works.

Learning pointers in Delphi is same problem.

An experienced programmer should rarely have problems with them, since
part of gaining said experience is learning to use pointers. That's
where the real power of C comes from.

Exactly. What idiot design Delphi objects. You can't pass this objects
by value (making copy). You can't return then by value. There is no
standard way to make copy of object (what a real pain!). There is no way
to have object on stack (automatic destruction on stack rewinding). And
lot more...

The basic philosophy of C is to expose the low-level operation of the
machine as much as possible and let the programmer, if desired, build
higher-level operations. If you only want to deal with higher-level
operations, then another language is probably more appropriate.

Like C++. Fast and safe (if You know what You doing), close to hardware.

One might consider what would be required to add "references" to a C
compiler. To borrow the syntax from C++, one would have this:

void test(int&a) {
a = 5;
}
...
int b = 0;
test(b); // b==5 after call returns

However, to implement this, the reality is that the compiler would end
up producing identical output to what it would produce if it were given
this:

void test(int *a) {
*a = 5;
}
...
int b = 0;
test(&b); // b==5 after call returns

So, the only advantage of allowing the former is that it is arguably
easier for novices to understand, but it doesn't actually add anything
to the language--and it breaks the decades-old rule that functions
cannot change their parameters, which means programmers must closely
examine the declaration of every function they call to determine whether
or not it uses references.

C++ had a good reason to add this syntactical sugar: to avoid
(potentially expensive) calls to copy constructors for pass-by-value
arguments.

Speed is no main issue for copy constructor. Issue is: You need to make
copy to pass it to copy constructor... And to make copy compiler need to
call copy constructor first ;-) So You need to make copy to be able to
make copy ;-)

Of course they may make copy ctor get pointer, but using reference is
much safer.

Reference parameter have one huge advantage over pointer: it can't be
NULL. It means no NULL checking, with most advantages of using pointer.
It is why they design references for C++. Without references most of STL
will be not possible.

That reason does not apply to C; all that would be left is
pure syntactical sugar, and that goes against the philosophy above.

C may also benefit from non-NULL property of references.