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

[E. Robert Tisdale]

Dave Vandervies wrote:

E. Robert Tisdale 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>).

You are confusing interoperability with portability.
None of the ANSI/ISO C and C++ standards guarantee interoperability.
There in *no* guarantee that you can link in object files
created by any other C or C++ compiler
and get the code to run correctly.

Portability guarantees *only* that you can compile and link together
object files created by the same compiler.
Programmers who have only a C90 compiler should provide
or should be provided with an stdbool.h header file
like the one shown above, include it in their programs
and use the bool type and the false and true constants.

Programmers who have a C99 compiler will use the stdbool.h header file
that came with their compiler.

Programmers who have a C++ compiler
must provide an empty stdbool.h header file
and the compiler will use the built-in type bool.

[Tom Plunket]

Just to resurrect an old old thread, since this same thread came
up at work just recently and now I wish to spark more discussion.

Jonathan Mcdougall wrote:

int f();

could not be more explicit.

David B. Held wrote:

Sure it could. Add "void".

Rolf Magnus wrote:
How does adding a pseudo parameter of type void make it more expicit
that you want no parameters?

The question that came up in my mind is that this "pseudo
parameter" isn't pseudo at all. It means, quite explicitly, that
the function takes no parameters.

While I understand that empty parentheses means "takes no
parameters," doesn't this beg the question (compatibility with
the first C aside) of why a function that takes no parameters
needs to have 'void' stated as its return type? I mean, if we're
trying to get rid of useless typing, certainly a function that
returns nothing (indeed, a function that doesn't even have an
explicit return statement) shouldn't need to specify that it
returns nothing- it could just get away with not stating that it
returns something.

To pull it all together, putting void in the parameters list is
only as silly (IMO) as putting void as the return type. Alas, I
still don't use void between the parens, but now see a lack of
symmetry in the way type specifiers are used.

Does my logic fail, besides contradicting The Almighty Standard?
-tom!

[Peter Koch Larsen]

"Tom Plunket" <to***@fancy.org> skrev i en meddelelse
news:lm********************************@4ax.com...

Just to resurrect an old old thread, since this same thread came
up at work just recently and now I wish to spark more discussion.
[snip]
While I understand that empty parentheses means "takes no
parameters," doesn't this beg the question (compatibility with
the first C aside) of why a function that takes no parameters
needs to have 'void' stated as its return type? I mean, if we're
trying to get rid of useless typing, certainly a function that
returns nothing (indeed, a function that doesn't even have an
explicit return statement) shouldn't need to specify that it
returns nothing- it could just get away with not stating that it
returns something.
For historical reasons, a function that did not specify a return type was
assumed to return int. This is not the case in C++ and probably not in C
eiter.

To pull it all together, putting void in the parameters list is
only as silly (IMO) as putting void as the return type. Alas, I
still don't use void between the parens, but now see a lack of
symmetry in the way type specifiers are used.

Does my logic fail, besides contradicting The Almighty Standard?
You could easily imagine a language where no return-type was equivalent to a
void return. Forgetting your inheritance is not a good thing, however.


-tom!

Kind regards
Peter