Followup
| Message |
 |
- Date: 2012-12-07 05:54
- Sender: Morten Mikkelsen
- As the comment in the header file clearly states it is specifically supposed to be a standalone and external set of files.
It's all explained in the header and if you search for blender tangent space in google.
| - Date: 2012-12-17 08:37
- Sender: Campbell Barton
- hi, Id like to move to C99 eventually, but changed like this will cause many conflicts in branches and make many small changes in blender.
Since there are quite a few actively maintained branches that are preparing for merge, I think now isnt such a good time to make this change.
as you say in your say - this can be done gradually, but even in this case - we should agree on the bf-committers mailing list first.
| - Date: 2012-12-17 16:52
- Sender: Brecht Van Lommel
- I think bool in C/C++ is commonly defined as int rather than char? It's slightly faster on 32 bit CPU's, though not sure if that's still true on 64 bit.
| - Date: 2012-12-20 00:49
- Sender: Lawrence D'Oliveiro
- Thanks for not rejecting this patch submission out of hand. :)
Certainly I don’t want to disrupt things—at least not right away. This patch is intended to be able to be merged without having to change anything else. Then, once it’s in, we can at any time try doing builds with BOOL_COMPAT set to OFF, react with dismay at all the compile-time errors it triggers, and start patching them up at our leisure. This can take as long as you like, because BOOL_COMPAT is there to keep the backward compatibility. Once, and only once, all these errors have gone away, we can declare “mission accomplished” and get rid of the BOOL_COMPAT mechanism (and the obsolete TRUE and FALSE constants) altogether.
| - Date: 2012-12-28 13:05
- Sender: Campbell Barton
- Notes...
on GCC 4.7x, 64bit linux sizeof(bool) == sizeof(char)
It would be nice if - for example, functions that return bool would give some compiler warning if returning/assigning values besides 0/1, (found a bug today that would have been avoided if this was so).
I checked and GCC doesn't do this (which is a shame IMHO), but not a reason to reject this patch. perhaps cppcheck or some other tool can be made to do it.
| - Date: 2013-01-01 13:35
- Sender: Campbell Barton
- Quick Q, whats '__bool_true_false_are_defined' added for?
| - Date: 2013-01-01 13:48
- Sender: Campbell Barton
- applied, r53480.
changed the cmake part to use check_c_source_runs(), so the source is inline.
| - Date: 2013-01-01 22:39
- Sender: Lawrence D'Oliveiro
- Cool! Thanks for including it. :)
Not sure what “__bool_true_false_are_defined” is for, but it’s defined in stdbool.h, and checked for in the original autoconf test, so it seems to be important.
Agreed about the lack of a diagnostic for out-of-range values. But they’re likely only important when the value is being used e.g. for array indexing, or direct comparisons with true and false (normally bad practice anyway), or in a switch statement. Presumably this is not already happening, otherwise the bugs would already be present. Changing to the standard “bool” type shouldn’t make any difference to this.
| |
|
