| Re: [AD] msvc7 vs new_api_branch |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: [AD] msvc7 vs new_api_branch
- From: Chris <chris.kcat@xxxxxxxxxx>
- Date: Sat, 20 Aug 2005 23:33:29 -0700
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=sftcPGYnYPmy7frajvfDZmimBMKuxJJ54gvBXLr01TIt/gAMqj+ePCERuxmaVLy7jbkX/kBvsxSauNJfuz7ZJ4w2YzNyNXrkpCoVo+1kPxuklMDHBahZJJZTP5/TCtOJ8dIcjDU0uWaShtyk6xbxtHBCH8HRs1Friv7ePl1UkLU=
On Saturday 20 August 2005 09:46 pm, Peter Wang wrote:
> > MSVC7 has a __FUNCTION__ macro, so somewhere we could
> > #define __func__ __FUNCTION__
> > but where?
>
> gcc accepts __FUNCTION__ as well, so we'll go with that.
> __func__ is C99.
I'd say we should use __func__ where possible. It's standard, after all (C99,
which new_api_branch/4.3+ is going to use/uses already). IMO, best not to use
extensions/custom constructs when there's standard equivilants. For MSVC,
yeah.. defining __func__ to __FUNCTION__ would be the solution here, but I
think we should make use of __func__ directly where possible to encourage its
use.
Also, on IRC, we also ran over the problem of bool, and how there's a note
that it's redefined to be the same size as C++ bool in case the header's
broken (is C++ bool gauranteed to be 1 byte?). Normally the size of bool
should be irrelevant, except in the situation where the extern "C"'d API uses
a bool in a C++ program.. both C's and C++'s implementations need to be the
same size.
Unless C99 explicitly specifies otherwise, I think it'd be safe to assume that
a C/C++ compiler set will make them the same size for this very reason. And
if not, then we just don't use bools in the exposed parts of the API (public
or not). Either way, we shouldn't have to worry about the size of bool.
Redefining bool to a char may be a bad idea regardless. Even though C99
specifies that bool must be a macro (so I hear), GCC defines bool to a
built-in compiler type _Bool, which apparently can only accept true and
false. It could lead to problems like this.
Accepted:
#include <stdbool.h>
#include <allegro/allegro.h>
...
bool var = 0xFF;
Problem:
#include <stdbool.h>
...
bool var = 0xFF;
Even if the latter is accepted, it'd be logical to assume it would change the
0xFF to true, meaning the two may be stored differently and cause problems
(like, if it's returned or passed to a function in a file that doesn't have
Allegro included, and is checked against true explicitly). And also, size
problems again, if one file uses Allegro it'll have bool at 1 byte, but
another file doesn't use Allegro, could have bool at something else.. if that
bool is passed to/from a function...