void and this

[Vladimir Grul]

Hello,

I have a class member function declared as

class some_class {
....
virtual int call(void);
};

Can I use this-> inside the function body?
Thanks.

Vladimir

[Attila Feher]

Vladimir Grul wrote:

Hello,

I have a class member function declared as

class some_class {
...
virtual int call(void);
Drop the void. C++ is not C.

virtual int call(void);
and
virtual int call();
mean exactly the same
};

Can I use this-> inside the function body?

Yes.

--
Attila aka WW

[Jonathan Mcdougall]

> I have a class member function declared as

class some_class {
...
virtual int call(void);
void in an empty parameter list is considered bad style in C++.
};

Can I use this-> inside the function body?

Of course, what makes you think you can't?
Jonathan

[Vladimir Grul]

"Jonathan Mcdougall" <jo***************@DELyahoo.ca> writes:

Of course, what makes you think you can't?

I was not sure if there is an implicit this in parameter list.

Thank you and Attila.

Vladimir

[David B. Held]

"Attila Feher" <at**********@lmf.ericsson.se> wrote in message
news:bl**********@newstree.wise.edt.ericsson.se...

Vladimir Grul wrote:

Hello,

I have a class member function declared as

class some_class {
...
virtual int call(void);

Drop the void. C++ is not C.

virtual int call(void);
and
virtual int call();
mean exactly the same
[...]

So why does "(void)" mean "C"?

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 9/23/2003

[David B. Held]

"Jonathan Mcdougall" <jo***************@DELyahoo.ca> wrote in message
news:D6********************@wagner.videotron.net.. .

I have a class member function declared as

class some_class {
...
virtual int call(void);

void in an empty parameter list is considered bad style in C++.
[...]

Since when?

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 9/23/2003

[John Carson]

"David B. Held" <dh***@codelogicconsulting.com> wrote in message
news:bl**********@news.astound.net

"Attila Feher" <at**********@lmf.ericsson.se> wrote in message
news:bl**********@newstree.wise.edt.ericsson.se...

Vladimir Grul wrote:

Hello,

I have a class member function declared as

class some_class {
...
virtual int call(void);

Drop the void. C++ is not C.

virtual int call(void);
and
virtual int call();
mean exactly the same
[...]

So why does "(void)" mean "C"?

Dave

If memory serves, in the C language, foo(void) means no arguments, whereas
foo() can mean none or one or ... any number of arguments. In C++, by
contrast, both foo(void) and foo() mean no arguments. Thus the void is
redundant in C++ but meaningful in C.
--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)

[Attila Feher]

David B. Held wrote:

Drop the void. C++ is not C.

virtual int call(void);
and
virtual int call();
mean exactly the same
[...]

So why does "(void)" mean "C"?

So why do you have to pick a quarrel on everything? Have you been bitten by
some vendetta bug?

To the OP:

As I have said above: the void is redundant, and has absolutely no effect on
a conforming compiler. And as everything redundant adding no value, the
only thing it can add is error, misunderstanding, misleading, wondering
collegagues why is it there and so forth. Since a virtual member function
needs no portability between C and C++ and the void there adds no value, it
is better be left out.

--
Attila aka WW

[jeffc]

"Attila Feher" <at**********@lmf.ericsson.se> wrote in message
news:bl**********@newstree.wise.edt.ericsson.se...

So why do you have to pick a quarrel on everything?
bwahahahaahahaha
As I have said above: the void is redundant, and has absolutely no effect on a conforming compiler. And as everything redundant adding no value, the
only thing it can add is error, misunderstanding, misleading, wondering
collegagues why is it there and so forth.

Ridiculous. What POSSIBLE "misunderstanding" can come from putting the void
in there? It's no more "misleading" than the "public" here
struct A
{
public:
int i;
};

or the "private" here
class A
{
private:
int i;
};

Or the parentheses here
i = a + (b * c)

[WW]

jeffc wrote:

"Attila Feher" <at**********@lmf.ericsson.se> wrote in message
news:bl**********@newstree.wise.edt.ericsson.se...

So why do you have to pick a quarrel on everything?

bwahahahaahahaha

Stop trolling please.

--
WW aka Attila

[tom_usenet]

On Mon, 6 Oct 2003 03:51:58 -0500, "David B. Held"
<dh***@codelogicconsulting.com> wrote:

"Jonathan Mcdougall" <jo***************@DELyahoo.ca> wrote in message
news:D6********************@wagner.videotron.net. ..

> I have a class member function declared as
>
> class some_class {
> ...
> virtual int call(void);

void in an empty parameter list is considered bad style in C++.
[...]

Since when?

Dennis Ritchie and Doug Ilroy described use of void to represent an
empty parameter list in C as an "abomination". Stroustrup agrees with
them, and void f(void); was illegal syntax in the early days of C++.
However it was reincorporated into C++ when C89 decided to use that
syntax in the interests of compatibility.

Tom

[Jerry Coffin]

In article <j9********************************@4ax.com>,
to********@hotmail.com says...

[ ... ]

Dennis Ritchie and Doug Ilroy

Doug McIlroy perhaps?

--
Later,
Jerry.

The universe is a figment of its own imagination.

[tom_usenet]

On Mon, 06 Oct 2003 16:00:52 GMT, Jerry Coffin <jc*****@taeus.com>
wrote:

In article <j9********************************@4ax.com>,
to********@hotmail.com says...

[ ... ]

Dennis Ritchie and Doug Ilroy

Doug McIlroy perhaps?

Er, yes. Whoops.

Tom

[Kevin Goodsell]

John Carson wrote:

If memory serves, in the C language, foo(void) means no arguments, whereas
foo() can mean none or one or ... any number of arguments.

Actually, it means there is a fixed, but unspecified number of
arguments. You still have to pass exactly the right number and type of
arguments, but the compiler is unable to check whether you did. It's a
relic from before prototypes existed in C.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[David B. Held]

"John Carson" <do***********@datafast.net.au> wrote in message
news:3f********@news.brisbane.pipenetworks.com...

[...]
If memory serves, in the C language, foo(void) means no
arguments, whereas foo() can mean none or one or ... any
number of arguments. In C++, by contrast, both foo(void)
and foo() mean no arguments. Thus the void is redundant
in C++ but meaningful in C.

I understand the distinction and the history, but I still fail to
understand why (void) is frowned upon or viewed as "C".
I happen to like the explicit way in which it says "this function
takes no arguments".

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 9/23/2003

[Sam Holden]

On Mon, 6 Oct 2003 13:21:07 -0500,
David B. Held <dh***@codelogicconsulting.com> wrote:

"John Carson" <do***********@datafast.net.au> wrote in message
news:3f********@news.brisbane.pipenetworks.com...

[...]
If memory serves, in the C language, foo(void) means no
arguments, whereas foo() can mean none or one or ... any
number of arguments. In C++, by contrast, both foo(void)
and foo() mean no arguments. Thus the void is redundant
in C++ but meaningful in C.

I understand the distinction and the history, but I still fail to
understand why (void) is frowned upon or viewed as "C".
I happen to like the explicit way in which it says "this function
takes no arguments".

Possibly because in C++ foo() explicitely says "this function takes
no arguments".

I personally find that foo() is more obvious than foo(void) when
quickly scanning code (as my brain sometimes sees the void and
has to double check to see if it is an argument type or not).

Of course my brain is defective in many ways, so that might just
be me...

--
Sam Holden

[David B. Held]

"Sam Holden" <sh*****@flexal.cs.usyd.edu.au> wrote in message
news:slrnbo3dmh.tlp.sh*****@flexal.cs.usyd.edu.au. ..

[...]
Possibly because in C++ foo() explicitely says "this function
takes no arguments".
I would say that that is an "implicit" form of saying that, but I
guess that's splitting hairs.
I personally find that foo() is more obvious than foo(void)
when quickly scanning code (as my brain sometimes sees
the void and has to double check to see if it is an argument
type or not).
And I find just the opposite. Of course, I always include an
access specifier for every group of members in a class as
well, so maybe I just like code to be more verbose.
Of course my brain is defective in many ways, so that might
just be me...

To each his own. When I see (int) 3.14, I think "C". But that's
because there's a *better* way to do it in C++. When I see
"(void)", I *don't* think "C", because the "C++ Way" isn't
technically better. It's just different.

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 9/23/2003

[David B. Held]

"WW" <wo***@freemail.hu> wrote in message
news:bl**********@phys-news1.kolumbus.fi...

jeffc wrote:

"Attila Feher" <at**********@lmf.ericsson.se> wrote in message
news:bl**********@newstree.wise.edt.ericsson.se...

So why do you have to pick a quarrel on everything?
bwahahahaahahaha

Stop trolling please.

[Earlier, you said...] And as everything redundant adding no value, the only
thing it can add is error, misunderstanding, misleading,
wondering collegagues why is it there and so forth.

Can you spell "FUD"? Physician, heal thyself.

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 9/23/2003

[jeffc]

"WW" <wo***@freemail.hu> wrote in message
news:bl**********@phys-news1.kolumbus.fi...

jeffc wrote:

"Attila Feher" <at**********@lmf.ericsson.se> wrote in message
news:bl**********@newstree.wise.edt.ericsson.se...

So why do you have to pick a quarrel on everything?

bwahahahaahahaha

Stop trolling please.

And your constant quarreling, and hypocritical remark above, are what?

[E. Robert Tisdale]

Vladimir Grul wrote:

I have a class member function declared as

class some_class {
// ...
virtual int call(void);
};

Can I use this-> inside the function body?

Yes.

[E. Robert Tisdale]

David B. Held wrote:

I understand the distinction and the history
but I still fail to understand why
(void) is frowned upon or viewed as "C".
It us not.
I happen to like the explicit way in which it says
"this function takes no arguments".

I agree.
This is merely a style issue if you are writing C++ code.
If you are writing code that a C compiler must also be able to compile,
you should write:

int foo(void);

so that the C compiler can detect mistakes like

int k = foo("some string");

If you are in the habit of writing C++ code
that a C compiler must be able to compile,
using void to indicate an empty parameter list is a *good* habit.

[Jonathan Mcdougall]

> > If memory serves, in the C language, foo(void) means no

arguments, whereas foo() can mean none or one or ... any
number of arguments. In C++, by contrast, both foo(void)
and foo() mean no arguments. Thus the void is redundant
in C++ but meaningful in C.

I understand the distinction and the history, but I still fail to
understand why (void) is frowned upon or viewed as "C".
I happen to like the explicit way in which it says "this function
takes no arguments".

int f();

could not be more explicit. What's more, I think (void) is
not only bad style, but deprecated. But I could be wrong.
Jonathan

[Bob Bell]

tom_usenet <to********@hotmail.com> wrote in message news:<j9********************************@4ax.com>. ..

On Mon, 6 Oct 2003 03:51:58 -0500, "David B. Held"
<dh***@codelogicconsulting.com> wrote:

"Jonathan Mcdougall" <jo***************@DELyahoo.ca> wrote in message
news:D6********************@wagner.videotron.net. ..

> I have a class member function declared as
>
> class some_class {
> ...
> virtual int call(void);

void in an empty parameter list is considered bad style in C++.
[...]

Since when?

Dennis Ritchie and Doug Ilroy described use of void to represent an
empty parameter list in C as an "abomination". Stroustrup agrees with
them, and void f(void); was illegal syntax in the early days of C++.
However it was reincorporated into C++ when C89 decided to use that
syntax in the interests of compatibility.

It's a good thing it was reincorporated, then. If I remember
correctly, there are contexts where foo() can be (mis)interpreted as a
call to foo() rather than a declaration of it; that never occurs with
foo(void).

(It's a subtle issue with templates, but I'll have to post an example
when I get home, as I don't have my copy of C++ Templates: The
Complete Guide. On the other hand, I might be remembering it wrong.)

Bob

[Noah Roberts]

#define THIS_FUNCTION_NIETHER_NEED_NOR_ACCEPTS_PARAMETERS

int f(THIS_FUNCTION_NIETHER_NEED_NOR_ACCEPTS_PARAMETER S);
void g(int x);
void q(THIS_FUNCTION_NIETHER_NEED_NOR_ACCEPTS_PARAMETER S);

All code that doesn't use the above is sux.

NR

[Noah Roberts]

Vladimir Grul wrote:

Hello,

I have a class member function declared as

class some_class {
...
virtual int call(void);
};

Can I use this-> inside the function body?

You can, and in fact you may run into someone that requires it in their
coding standards. I personally have not, but some people prefer that
you explicitly cass an instance variable like this->xxx instead of just xxx.

NR

[Kevin Goodsell]

David B. Held wrote:

I understand the distinction and the history, but I still fail to
understand why (void) is frowned upon or viewed as "C".
I happen to like the explicit way in which it says "this function
takes no arguments".

Well, I don't mean to be argumentative, but it seems to me that showing
the function with no arguments is possibly a *more* explicit (or at
least logical) way of showing that it takes no arguments than showing it
with what appears to be a void argument. Granted, no C++ programmer will
actually be lead to believe that the function takes one argument of
type void, but that is what the syntax suggests. This is why I agree
that the syntax is an "abomination", as was stated elsewhere.

On the other hand, (void) is usually the right thing to use in C - if
you were concerned about forming a habit that will cause problems if
carried over to C, I can sort of understand that. I could also
appreciate wanting to avoid confusing newbies into carrying the use of
empty parens over to C.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[David B. Held]

"Jonathan Mcdougall" <jo***************@DELyahoo.ca> wrote in message
news:%E********************@weber.videotron.net...

[...]
int f();

could not be more explicit.
Sure it could. Add "void". Then you aren't wondering if you
are looking at a C++ function that takes no arguments, or a
C function that takes an unknown number of arguments.
Because we all know that if you don't do that, Russia will
invade, we will be attacked by aliens, and global warming
will cause the earth to burn up. That's what will happen if you
don't use "void".
What's more, I think (void) is not only bad style, but
deprecated.
LOL!!! As if (void) is so evil that we must get rid of it at all
costs!
But I could be wrong.

I certainly hope so. There's much worse things to worry about
than (void).

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 9/23/2003

[David B. Held]

"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:H7***************@newsread4.news.pas.earthlin k.net...

David B. Held wrote:

I understand the distinction and the history, but I still fail to
understand why (void) is frowned upon or viewed as "C".
I happen to like the explicit way in which it says "this function
takes no arguments".
Well, I don't mean to be argumentative,

Don't apologize for disagreeing!
but it seems to me that showing the function with no
arguments is possibly a *more* explicit (or at least logical)
way of showing that it takes no arguments than showing it
with what appears to be a void argument. Granted, no C++
programmer will actually be lead to believe that the function
takes one argument of type void, but that is what the syntax
suggests. This is why I agree that the syntax is an
"abomination", as was stated elsewhere.
[...]

Well, void doesn't quite work with metaprogramming, but it
should. I mean, how handy would it be if we could substitute
any number of void arguments in a template function? We
wouldn't need to write a hundred overloads! Like this:

int foo(void, void); // takes no arguments

Why would you want to do that? Why, so you could do this,
of course:

template <typename T1 = void, typename T2 = void, ...>
int foo(T1 t1, T2 t2, ...);

And voila! You just wrote N overloads that currently require
tedious cut-n-paste or preprocessor magic.

Anyway, I think of "void" as a "metanull". It's a metavalue
which indicates nothingness, like NULL, kinda. Would you
say that this is more "explicit"?

int* p = ;

Believe it or not, I see "int foo()" in a similar way, which
rubs me the wrong way just as the statement above
undoubtedly rubs most people.

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 9/23/2003

[Attila Feher]

jeffc wrote:

"WW" <wo***@freemail.hu> wrote in message
news:bl**********@phys-news1.kolumbus.fi...

jeffc wrote:

"Attila Feher" <at**********@lmf.ericsson.se> wrote in message
news:bl**********@newstree.wise.edt.ericsson.se...
So why do you have to pick a quarrel on everything?

bwahahahaahahaha

Stop trolling please.

And your constant quarreling, and hypocritical remark above, are what?

Stop trolling please.

--
Attila aka WW

[Attila Feher]

David B. Held wrote:

"WW" <wo***@freemail.hu> wrote in message
news:bl**********@phys-news1.kolumbus.fi...

jeffc wrote:

"Attila Feher" <at**********@lmf.ericsson.se> wrote in message
news:bl**********@newstree.wise.edt.ericsson.se...
So why do you have to pick a quarrel on everything?

bwahahahaahahaha

Stop trolling please.

[Earlier, you said...]

And as everything redundant adding no value, the only
thing it can add is error, misunderstanding, misleading,
wondering collegagues why is it there and so forth.

Can you spell "FUD"? Physician, heal thyself.

Stop trolling please.

--
Attila aka WW

[Noah Roberts]

Attila Feher wrote:

David B. Held wrote:

"WW" <wo***@freemail.hu> wrote in message
news:bl**********@phys-news1.kolumbus.fi...

jeffc wrote:

"Attila Feher" <at**********@lmf.ericsson.se> wrote in message
news:bl**********@newstree.wise.edt.ericsson.s e...

>So why do you have to pick a quarrel on everything?

bwahahahaahahaha

Stop trolling please.
[Earlier, you said...]

And as everything redundant adding no value, the only
thing it can add is error, misunderstanding, misleading,
wondering collegagues why is it there and so forth.

Can you spell "FUD"? Physician, heal thyself.

Stop trolling please.

He's like a broken record :P
--
Attila aka WW

[Attila Feher]

Noah Roberts wrote:

>> So why do you have to pick a quarrel on everything?
>
> bwahahahaahahaha

Stop trolling please.

[Earlier, you said...]

And as everything redundant adding no value, the only
thing it can add is error, misunderstanding, misleading,
wondering collegagues why is it there and so forth.

Can you spell "FUD"? Physician, heal thyself.

Stop trolling please.

He's like a broken record :P

Yes, he is. I wish he would stop trolling.

--
Attila aka WW

[Rolf Magnus]

David B. Held wrote:

"Jonathan Mcdougall" <jo***************@DELyahoo.ca> wrote in message
news:%E********************@weber.videotron.net...

[...]
int f();

could not be more explicit.
Sure it could. Add "void".

How does adding a pseudo parameter of type void make it more expicit
that you want no parameters?
Then you aren't wondering if you
are looking at a C++ function that takes no arguments, or a
C function that takes an unknown number of arguments.
I never was wondering about that. I typically know if I'm programming in
C or in C++. Don't you too?
Because we all know that if you don't do that, Russia will
invade, we will be attacked by aliens, and global warming
will cause the earth to burn up. That's what will happen if you
don't use "void".

.... in C. Well, actually only in the obsolete C89.

[Rolf Magnus]

David B. Held wrote:

Well, void doesn't quite work with metaprogramming, but it
should. I mean, how handy would it be if we could substitute
any number of void arguments in a template function? We
wouldn't need to write a hundred overloads! Like this:

int foo(void, void); // takes no arguments

Why would you want to do that? Why, so you could do this,
of course:

template <typename T1 = void, typename T2 = void, ...>
int foo(T1 t1, T2 t2, ...);

And voila! You just wrote N overloads that currently require
tedious cut-n-paste or preprocessor magic.
The question is where could you practically use it? I mean, you can't
use the parameters within your function, because they might not exist.
So what are they useful for then?
Anyway, I think of "void" as a "metanull". It's a metavalue
which indicates nothingness, like NULL, kinda. Would you
say that this is more "explicit"?

int* p = ;

Well, you also don't write:

void x;

to state that x is not a variable.

[Attila Feher]

Rolf Magnus wrote:

David B. Held wrote:

Well, void doesn't quite work with metaprogramming, but it
should. I mean, how handy would it be if we could substitute
any number of void arguments in a template function? We
wouldn't need to write a hundred overloads! Like this:

int foo(void, void); // takes no arguments

Why would you want to do that? Why, so you could do this,
of course:

template <typename T1 = void, typename T2 = void, ...>
int foo(T1 t1, T2 t2, ...);

And voila! You just wrote N overloads that currently require
tedious cut-n-paste or preprocessor magic.

The question is where could you practically use it? I mean, you can't
use the parameters within your function, because they might not exist.
So what are they useful for then?

Anyway, I think of "void" as a "metanull". It's a metavalue
which indicates nothingness, like NULL, kinda. Would you
say that this is more "explicit"?

int* p = ;

Well, you also don't write:

void x;

to state that x is not a variable.

We can take any number of void arguments, but we will not be convinced by
them. ;-)

--
Attila aka WW

[Jonathan Mcdougall]

> > int f();

could not be more explicit.
Sure it could. Add "void".

At that point, I think it must only be a matter of taste.
Then you aren't wondering if you
are looking at a C++ function that takes no arguments, or a
C function that takes an unknown number of arguments.

I don't program in C, so there is no wondering about that.

What's more, I think (void) is not only bad style, but
deprecated.

LOL!!! As if (void) is so evil that we must get rid of it at all
costs!

No, only that it is useless. Not many things are useless in C++.
Take for example 'typename' which is only allowed in certain
circumstances since it would be useless (but not syntactically).

But I could be wrong.

I certainly hope so. There's much worse things to worry about
than (void).

That I certainly agree with.
Jonathan

[WW]

David B. Held wrote:

To each his own. When I see (int) 3.14, I think "C". But that's
because there's a *better* way to do it in C++. When I see
"(void)", I *don't* think "C", because the "C++ Way" isn't
technically better. It's just different.

If we say "you are right" will you stop ranting?

--
WW aka Attila

[David B. Held]

"WW" <wo***@freemail.hu> wrote in message
news:bl**********@phys-news1.kolumbus.fi...

David B. Held wrote:

To each his own. When I see (int) 3.14, I think "C". But that's
because there's a *better* way to do it in C++. When I see
"(void)", I *don't* think "C", because the "C++ Way" isn't
technically better. It's just different.

If we say "you are right" will you stop ranting?

No, because A) you asked a loaded question, and B) I don't
think the issue has an unarguably correct position.

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 9/23/2003

[David B. Held]

"Rolf Magnus" <ra******@t-online.de> wrote in message
news:bl*************@news.t-online.com...

[...]
The question is where could you practically use it? I mean,
you can't use the parameters within your function, because
they might not exist. So what are they useful for then?
You use type traits to see if an argument is void or not.
That's what is_void<> is for. To be truly useful, these functions
would have to be considered equivalent for overload purposes:

int foo(int);
int foo(int, void);

Then, you could do c'tor forwarding very nicely:

template <typename T, typename A1, typename A2 = void, ...>
auto_ptr<T> make_auto_ptr(A1 a1, A2 a2, ...)
{
return new T(a1, a2, ...);
}

The call to new T() would only call c'tors that matched the right
number of non-void arguments. Of course, 'void' in the middle
of a non-void list would be ill-formed. Compare that to the
current way we have to do this with N overloads.

There are all kinds of places where forwarding occurs, or
doesn't occur, because it's too tedious to write the overloads.
[...]
void x;

to state that x is not a variable.

But you do here:

int foo(void);

You just aren't allowed to name the "not-present variable".
And you can certainly cast to void:

(void) x;

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 9/23/2003

[David B. Held]

"Attila Feher" <at**********@lmf.ericsson.se> wrote in message
news:bl**********@newstree.wise.edt.ericsson.se...

[...]
> And as everything redundant adding no value, the only
> thing it can add is error, misunderstanding, misleading,
> wondering collegagues why is it there and so forth.

[...]
Yes, he is. I wish he would stop trolling.

So you're saying your statement above about (void) has a
factual basis? Would you like to prove your statement then,
with replicated studies? Or are you just going to admit
that you made a provokative unfounded claim?

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 9/23/2003

[WW]

David B. Held wrote:

"WW" <wo***@freemail.hu> wrote in message
news:bl**********@phys-news1.kolumbus.fi...

David B. Held wrote:

To each his own. When I see (int) 3.14, I think "C". But that's
because there's a *better* way to do it in C++. When I see
"(void)", I *don't* think "C", because the "C++ Way" isn't
technically better. It's just different.

If we say "you are right" will you stop ranting?

No, because A) you asked a loaded question, and B) I don't
think the issue has an unarguably correct position.

Good. Then please, by all means, continue ranting. I will, in no way,
stand in the way of anyones happiness.

--
WW aka Attila

[jeffc]

"David B. Held" <dh***@codelogicconsulting.com> wrote in message
news:bl**********@news.astound.net...

"Attila Feher" <at**********@lmf.ericsson.se> wrote in message
news:bl**********@newstree.wise.edt.ericsson.se...

>> [...]
>>> And as everything redundant adding no value, the only
>>> thing it can add is error, misunderstanding, misleading,
>>> wondering collegagues why is it there and so forth.

[...]
Yes, he is. I wish he would stop trolling.

So you're saying your statement above about (void) has a
factual basis? Would you like to prove your statement then,
with replicated studies? Or are you just going to admit
that you made a provokative unfounded claim?

He is never going to admit *anything*, *ever*. After 1 or 2 more ludicrous
posts of his, he's going into the killfile.

[Bob Bell]

be****@pacbell.net (Bob Bell) wrote in message news:<c8**************************@posting.google. com>...

tom_usenet <to********@hotmail.com> wrote in message news:<j9********************************@4ax.com>. ..

Dennis Ritchie and Doug Ilroy described use of void to represent an
empty parameter list in C as an "abomination". Stroustrup agrees with
them, and void f(void); was illegal syntax in the early days of C++.
However it was reincorporated into C++ when C89 decided to use that
syntax in the interests of compatibility.

It's a good thing it was reincorporated, then. If I remember
correctly, there are contexts where foo() can be (mis)interpreted as a
call to foo() rather than a declaration of it; that never occurs with
foo(void).

(It's a subtle issue with templates, but I'll have to post an example
when I get home, as I don't have my copy of C++ Templates: The
Complete Guide. On the other hand, I might be remembering it wrong.)

D'oh! Looks like I'm remembering it wrong. I had this confused with a
different subtle issue with templates.

Bob

[Simon Elliott]

David B. Held <dh***@codelogicconsulting.com> writes

To each his own. When I see (int) 3.14, I think "C". But that's
because there's a *better* way to do it in C++. When I see
"(void)", I *don't* think "C", because the "C++ Way" isn't
technically better. It's just different.

Much as I hate to jump in to a controversial thread like this, some of
this stuff is interesting, and some is actually quite relevant to code I
have to maintain and develop.

I'm involved in several projects where there's a core lump of C code.
Sometimes this is legacy stuff which is so tried and tested that it
would be foolish to replace it. More often it's cross platform and must
work on a a variety of embedded systems with low power 8 bit processors.
Often these don't have C++ compilers, and even if they did, the
developers probably wouldn't want to use C++.

If this core C code is to be callable from larger, more complex programs
written with C++, there has to be some kind of interface between the C
and the C++. Sometimes it's necessary for C code to call C++ functions
or vice versa, and sometimes it's necessary to #include data structures
which were originally written for the core C code. So I end up having a
certain amount of this kind of thing:

#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */

extern BLOGGS* BLOGGSnew(void);
extern void BLOGGSdelete(BLOGGS* pBloggs);
extern void BLOGGSsetFoo(BLOGGS* pBloggs, int iFoo);

#ifdef __cplusplus
}
#endif /* __cplusplus */

You can see where I'd be a bit worried about disappearance from the
standard of the use of 'void' to indicate a null argument list. So here
are a few more comments and questions around the topic of C versus C++.

1/ Do those who don't like the use of 'void' to indicate a null argument
list also think that 'void' should be dropped as a return type to
indicate a function which doesn't return a value? It seems a bit strange
that a function with no specified return type should default to int
rather than void.

2/ I find the change in the names of the standard headers from "stdio.h"
to "cstdio" are also quite disturbing. Is the long term objective of the
C++ standard still to encompass being "a better C"?

3/ One of the biggest problems I have when I need to #include headers
written for C is that the C developer will often have written:
typedef int bool;
Which not surprisingly C++ compilers don't like. Guarding the
declaration with #ifdef __cplusplus doesn't help if the developer has
then used his bool type in argument lists or structures, as sizeof(int)
in the C compiler isn't likely to be the same as sizeof(bool) in the C++
compiler. How would people get round this?

4/ Interesting point by David re C casts. When I code in C++ I use the
new C++ casts for objects, but if I'm just converting one built in type
to another, I'll use a C cast: int i; i=(int)3.14;
Is there any downside to this use of C casts in C++ code?
--
Simon Elliott
http://www.ctsn.co.uk/

[Attila Feher]

Simon Elliott wrote:
[SNIP]

#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */

extern BLOGGS* BLOGGSnew(void);
extern void BLOGGSdelete(BLOGGS* pBloggs);
extern void BLOGGSsetFoo(BLOGGS* pBloggs, int iFoo);

#ifdef __cplusplus
}
#endif /* __cplusplus */

You can see where I'd be a bit worried about disappearance from the
standard of the use of 'void' to indicate a null argument list. So
here are a few more comments and questions around the topic of C
versus C++.
It will not disappear. The question was about its use in "pure C++" code.
1/ Do those who don't like the use of 'void' to indicate a null
argument list also think that 'void' should be dropped as a return
type to indicate a function which doesn't return a value?
This has nothing to do with the topic, and no one suggested void to be
dropped.
It seems a
bit strange that a function with no specified return type should
default to int rather than void.
That might be the reason no one has suggested anything silly like that. Not
even for indication of an empty argument list.
2/ I find the change in the names of the standard headers from
"stdio.h" to "cstdio" are also quite disturbing. Is the long term
objective of the C++ standard still to encompass being "a better C"?
It has never been. C++ is a stand alone language, with high (but not full)
compatibility with C. There was a long list of articles/statement/threads
(in comp.lang.c++.moderated) about C and C++ compatibility, and the need to
increase it. There is a legit need and there seems to be a serious
intention (at least from some, including Bjarne Stroustrup) to make that
happen. How, when - if ever - is still a question.
3/ One of the biggest problems I have when I need to #include headers
written for C is that the C developer will often have written:
typedef int bool;
Which not surprisingly C++ compilers don't like. Guarding the
declaration with #ifdef __cplusplus doesn't help if the developer has
then used his bool type in argument lists or structures, as
sizeof(int) in the C compiler isn't likely to be the same as
sizeof(bool) in the C++ compiler. How would people get round this?
Interesting. I think it is not really possible without changing the C code,
like calling that typedef cbool or something.
4/ Interesting point by David re C casts. When I code in C++ I use the
new C++ casts for objects, but if I'm just converting one built in
type to another, I'll use a C cast: int i; i=(int)3.14;
Is there any downside to this use of C casts in C++ code?

Some. For example it is much harder to find them (like text search). But I
think in the above code you need no cast... do you? Unless you supress a
warning...

I do not think that such a cast (as above) is dangerous. C++ programmers
will need to learn the C style casts, they are not deprecated and they will
be around for quite a while. (Not deprecated IMO means that they will be
around for at least 20 years.)

Casts which really do something IMO better be written as C++ style casts.
But as I understand this is exactly what you do. :-)

--
Attila aka WW

[Frank Schmitt]

Simon Elliott <si***@nospam.demon.co.uk> writes:

1/ Do those who don't like the use of 'void' to indicate a null argument
list also think that 'void' should be dropped as a return type to
indicate a function which doesn't return a value?
I don't like the usage of void to indicate a null argument list, but I
insist on having void as return type for functions not returning
anything - otherwise parsing C++ (for a human, at least) would become
more difficult.
It seems a bit strange
that a function with no specified return type should default to int
rather than void.
Functions without a specified return type are no longer allowed in C++.
4/ Interesting point by David re C casts. When I code in C++ I use the
new C++ casts for objects, but if I'm just converting one built in type
to another, I'll use a C cast: int i; i=(int)3.14;
Is there any downside to this use of C casts in C++ code?

They are much harder to spot - for the new style casts, a simple grep
suffices. That said, for trivial cases like yours, I tend to use C-style
casts as well - less typing :-)

kind regards
frank

--
Frank Schmitt
4SC AG phone: [phone]
e-mail: frankNO DOT SPAMschmitt AT 4sc DOT com

[Gavin Deane]

Simon Elliott <si***@nospam.demon.co.uk> wrote in message news:<fT**************@courtlands.demon.co.uk>...

<snip description of working with C and C++ code close together>

#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */

extern BLOGGS* BLOGGSnew(void);
extern void BLOGGSdelete(BLOGGS* pBloggs);
extern void BLOGGSsetFoo(BLOGGS* pBloggs, int iFoo);

#ifdef __cplusplus
}
#endif /* __cplusplus */

You can see where I'd be a bit worried about disappearance from the
standard of the use of 'void' to indicate a null argument list. So here
are a few more comments and questions around the topic of C versus C++.
I don't think it's likely to disappear is it?
1/ Do those who don't like the use of 'void' to indicate a null argument
list also think that 'void' should be dropped as a return type to
indicate a function which doesn't return a value? It seems a bit strange
that a function with no specified return type should default to int
rather than void.
Those who don't like the use of 'void' to indicate an empty parameter
list are arguing from a purely C++ point of view. A function with no
specified return type is not allowed in C++ - there is no implicit
int. Allowing functions that don't return anything to be defined
without any return type at all (no void, no anything) would be a
fundamental change and I'm sure nobody is suggesting that.
2/ I find the change in the names of the standard headers from "stdio.h"
to "cstdio" are also quite disturbing. Is the long term objective of the
C++ standard still to encompass being "a better C"?
stdio.h hasn't been replaced by cstdio. The old headers are still
available. The new headers put the library in namespace std which is
good for pure C++, but not when your code needs to be compiled as both
C and C++. I don't think the stdio.h style headers are any more likely
to disappear than allowing void to indicate an empty parameter list
is.
3/ One of the biggest problems I have when I need to #include headers
written for C is that the C developer will often have written:
typedef int bool;
Which not surprisingly C++ compilers don't like. Guarding the
declaration with #ifdef __cplusplus doesn't help if the developer has
then used his bool type in argument lists or structures, as sizeof(int)
in the C compiler isn't likely to be the same as sizeof(bool) in the C++
compiler. How would people get round this?
Not sure there is an easy way around that. If you're writing code that
you expect to be compiled as C and as C++, I suppose you just have to
not do that. Doesn't C99 have a built in boolean type now?
4/ Interesting point by David re C casts. When I code in C++ I use the
new C++ casts for objects, but if I'm just converting one built in type
to another, I'll use a C cast: int i; i=(int)3.14;
Is there any downside to this use of C casts in C++ code?

The new C++ casts are preferred for two reasons. They are easier to
spot, both by humans and by search tools. And, probably more
importantly, all apart from reinterpret_cast are less powerful than
C-style casts, allowing the compiler to still do a certain amount of
type checking.

I have the impression that well written C code is likely to contain
more casts (particularly pointer casts) than well written C++ code.
But I am not a C programmer so I may have got that idea simply from
seeing code from people who aren't as good as they think they are.

GJD

[Dave Vandervies]

In article <6d**************************@posting.google.com >,
Gavin Deane <de*********@hotmail.com> wrote:

Simon Elliott <si***@nospam.demon.co.uk> wrote in message
news:<fT**************@courtlands.demon.co.uk>. ..

<snip description of working with C and C++ code close together>

3/ One of the biggest problems I have when I need to #include headers
written for C is that the C developer will often have written:
typedef int bool;
Which not surprisingly C++ compilers don't like. Guarding the
declaration with #ifdef __cplusplus doesn't help if the developer has
then used his bool type in argument lists or structures, as sizeof(int)
in the C compiler isn't likely to be the same as sizeof(bool) in the C++
compiler. How would people get round this?

Not sure there is an easy way around that. If you're writing code that
you expect to be compiled as C and as C++, I suppose you just have to
not do that. Doesn't C99 have a built in boolean type now?

C99 has a built in boolean type (_Bool), as well as a standard header
(<stdbool.h>) that defines macros for bool, true, and false.

Since in practice you're unlikely to be able to avoid having to coexist
with C90 for quite some time, this doesn't make it any easier to use
bool in headers that have to be both C- and C++-clean. It's probably
still best to use int and document that the value represents a boolean
value for that.

4/ Interesting point by David re C casts. When I code in C++ I use the
new C++ casts for objects, but if I'm just converting one built in type
to another, I'll use a C cast: int i; i=(int)3.14;
Is there any downside to this use of C casts in C++ code?

The new C++ casts are preferred for two reasons. They are easier to
spot, both by humans and by search tools. And, probably more
importantly, all apart from reinterpret_cast are less powerful than
C-style casts, allowing the compiler to still do a certain amount of
type checking.

Also useful is that they do better with indicating why a cast is used.
F'rexample:

free((void *)temp);

Is the programmer not aware that conversions to void * don't need
a cast? Is temp const- or volatile-qualified for some reason? Is temp
a non-pointer type that has had a pointer stuffed in it?

Now answer the same question for:

free(const_cast<void *>(temp));

(I've encountered this in testing code that used a volatile-qualified
pointer obtained from malloc to avoid having some timing tests optimized
out. Perhaps not the best example, since the total amount of code for
such things tends to be small enough that it's easy to find supporting
evidence for "casting away qualifiers", but still enough to demonstrate
the point.)

I have the impression that well written C code is likely to contain
more casts (particularly pointer casts) than well written C++ code.
But I am not a C programmer so I may have got that idea simply from
seeing code from people who aren't as good as they think they are.

Most likely the latter.

There are a very small number of cases where a cast is required, but they
tend not to be the places most programmers use them. (In my experience,
the most important use of casts is to shut up compiler warnings for
conversions that can lose information, like double->float.) Pointer
casts especially are almost always a sign that the code needs a closer
look and probably some debugging.
C tends to use fewer pointer conversions than C++ in the first place,
and the most common one (void * returned from malloc -> pointer used
to point to stuff -> void * passed to free) is done without a cast.
(Note that void * has a somewhat different purpose in C than in C++,
and corresponding differences in rules for its use.)

(For the curious, the places where pointer casts are actually valid and
useful in C (that I know of) are:
-Passing pointers as variadic arguments where the type of the pointer
isn't the expected type. The canonical example of this is printf's
"%p", which expects a void *, and there isn't enough type information
to allow an automatic conversion.
(Not as relevant in C++, since there's usually a better way to do
things than using variadic functions)
-Casting away const for functions that return a pointer to the same
thing as a pointer they're passed, without modifying what's pointed
at (several <string.h> functions do this or the moral equivalent).
(Not useful in C++, because of stronger const rules and overloading:
C's "char *return_pointer_into_string(const char *)" would have two
versions in C++, one taking and returning char * and one taking and
returning const char *)
-Taking advantage of the rule that a pointer to a struct, suitably
converted, can be used as a pointer to its first member. This usually
means the programmer is doing something odd anyways.
(Valid (as far as I know) and potentially useful in C++, but most
often used to allow a limited form of polymorphism that in C++ is
better done using other language features)
-Converting a pointer to char * to examine the representation of an object
(Just as valid, and just as useful (that is, "not portably"), in C++
as in C)
If you really want to know all the details, ask in comp.lang.c .)
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
So "Patterns" are really just another name for "Object-oriented programming",
which is really just another name for "Structured programming", which is really
just big words for "good hacking". --Richard Bos in comp.lang.c

[E. Robert Tisdale]

Dave Vandervies wrote:

Gavin Deane wrote:

not do that. Doesn't C99 have a built in boolean type now?

C99 has a built in boolean type (_Bool), as well as a standard header
(<stdbool.h>) that defines macros for bool, true, and false.

Since in practice you're unlikely to be able to avoid having to coexist
with C90 for quite some time, this doesn't make it any easier to use
bool in headers that have to be both C- and C++-clean.
It's probably still best to use int and document that
the value represents a boolean value for that.

This is *bad* advice.

C90 programmers should provide their own stdbool.h header file:

#ifndef guard_stdbool_h
#define guard_stdbool_h 1
typedef int bool;
const int false = 0;
const int true = !false;
#endif/*guard_stdbool_h */

[Dave Vandervies]

In article <3F**************@jpl.nasa.gov>,
E. Robert Tisdale <E.**************@jpl.nasa.gov> wrote:

Dave Vandervies wrote:

Gavin Deane wrote:

not do that. Doesn't C99 have a built in boolean type now?

C99 has a built in boolean type (_Bool), as well as a standard header
(<stdbool.h>) that defines macros for bool, true, and false.

Since in practice you're unlikely to be able to avoid having to coexist
with C90 for quite some time, this doesn't make it any easier to use
bool in headers that have to be both C- and C++-clean.
It's probably still best to use int and document that
the value represents a boolean value for that.

This is *bad* advice.

C90 programmers should provide their own stdbool.h header file:

#ifndef guard_stdbool_h
#define guard_stdbool_h 1
typedef int bool;
const int false = 0;
const int true = !false;
#endif/*guard_stdbool_h */

And how does this make it easier to have headers that can be used with
C90, C99, *and* C++?
Unless there are constraints on C++'s bool that I'm not aware of, it
would be reasonable to expect C++'s bool and C99's _Bool to be the same
type for a compiler that supports both languages. Expecting this to
be the same as int is less reasonable, and without all three being the
same it becomes pointless to use "bool" in headers that are intended to
be used between the languages.

Do you have an alternate suggestion for being able to put this in a
header file:
--------
void do_something_with_boolean_value(bool);
--------
and being able to correctly call do_something_with_boolean_value from
any of the three languages?
Aside from interoperability issues that can be confined to header files,
C90 programmers should write in C90, which doesn't include a boolean type
(though it does allow one to be created if it's desired, and with care
the semantics of such a type (if not the representation) can be made
compatible with those of the bool from C99's <stdbool.h>).
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
So "Patterns" are really just another name for "Object-oriented programming",
which is really just another name for "Structured programming", which is really
just big words for "good hacking". --Richard Bos in comp.lang.c