Re: void and this
From: Attila Feher (attila.feher_at_lmf.ericsson.se)
Date: 10/10/03
- Next message: Karl Heinz Buchegger: "Re: Converting from and INT back to ASCII character"
- Previous message: Dietmar Kuehl: "Re: unget vs. putback"
- In reply to: Simon Elliott: "Re: void and this"
- Next in thread: Frank Schmitt: "Re: void and this"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 10 Oct 2003 12:22:04 +0300
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
- Next message: Karl Heinz Buchegger: "Re: Converting from and INT back to ASCII character"
- Previous message: Dietmar Kuehl: "Re: unget vs. putback"
- In reply to: Simon Elliott: "Re: void and this"
- Next in thread: Frank Schmitt: "Re: void and this"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
