|
From: <fl...@ma...> - 2003-08-03 22:40:46
|
Well the point with using defines instead of const int for that, do not have
a big impact on code writability, however, from the perspective of
readability check this two codes...
-----------------------------------------
const Real pi = 3.1416
Real f ( Real argument )
{
return (2 * pi * argument );
};
-----------------------------------------
#define _PI 3.1416
Real f (Real argument )
{
return (2 * _PI * argument);
};
-----------------------------------------
Now from the point of view of static code analysis, using our conventions
you can see that in the second case 2 * _PI is a constant that will be
precalculated by the compiler. In the first one, you can be misleaded to
think that pi is a variable (even though pi is not, you can find real life
names that will) or worst a global variable. So if you can diferenciate them
in code via names, you are making a more readable code... Now you can argue
that we can use a naming convention similar for that kind of constants,
then: What is the difference between a const Real in a function and a
conventional constant const Real?
From the compiled code point of view, when you use the define the 2 * _PI
instruction is optimized by the compiler as 6,2832 and then the compiled
code looks like this:
(I will take some poetic license here creating a special symbolic assemblet,
but it works to show the point)
S - Stack Frame Pointer (where the function begins)
MOV register0, S[argumentOffset];
MULT register0, register0, 6,2832;
MOV S[returnOffset], register0;
in the second place you need an optimizing compiler to get that, however,
because C++ have to support separate compilation if the constant you are
using is defined and initialized in another file (module) then the compiler
cannot know the real value (even though it wont be changed). So because of
that limitations the best code you will get will look like this.
MOV register0, S[argumentOffset];
MOV register1, [piAddress];
MULT register0, register0, 2;
MULT register0, register0, register1;
MOV S[returnOffset], register0;
So If there is not a need to use complex structures, like in the case of
vectors or matrices, where all identity ones are already defined as the
latest kind of constants (because of a performance issue that I will explain
below) you should use defines... The case with that objects for instance is
the next:
We have some MiscRGBAColor objects already created. So we have
miscColorBlack, miscColorRed and so on... now you have created n objects
codifing colors. You can use defines too, suppose you want to define the red
color..
#define _REDRGBACOLOR MiscRGBAColor (1,0,0,0);
So for every place you have _REDRGBACOLOR in your code you are creating a
new object instance. But there is something more sinister in this. The scope
of MiscRGBAColor is validated by the inclusion of an include statement, and
the #define is not, because that is a precompiler macro... so that can
create some difficult to diagnose compilation problems. So appart from the
performance issues, there is some other problems that have to be
addressed...
Now, when to use defines and when to use const values? Easy, you have to use
defines when the type of the expression you used can be known by the
compiler on compilation like characters, strings, integers, real numbers,
etc.... You cant use them with user defined objects, so for that you have
const values...
Greetings
Red Knight
----- Original Message -----
From: "mamutas" <ma...@pr...>
To: <xen...@li...>
Sent: Saturday, August 02, 2003 11:44 PM
Subject: FW: [Xenocide-programming] Fritz here, Font/Text renderer header
files.
> Also, why do we use defines for style flags? Why not to use static const
int
> instead? See sample of code below.
>
> // RED KNIGHT: Modify this names to be consistent with new code
convention,
> that was old code so dont use it that way. If we are going to break the
> code, then break it completly and we will make things look better.
>
> // OLD CONVENTION: _STYLE<something>
> // NEW CONVENTION: _FS<something> (FS stand for FONTSTYLE)
>
> #define _STYLENONE 0
> #define _STYLEITALIC 1
> #define _STYLEUNDERLINE 2
> #define _STYLESTRIKEOUT 4
>
> Regards,
> mamutas
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>
>
|