On 8/2/2010 10:49 PM, Bob Kerns wrote:
First of all -- if you want to list the faults of the C language, the
preprocessor is very near the top.
Just your opinion.
That's why C++ went to great lengths to mostly remove the need for
using it, with inline functions, constants, and the like.
Now your just talking specifically about macros which still can be
useful and there are somethings that can only be done using a macro.
It's too bad they didn't remove it. It causes all kinds of difficulty
for tools. The tools for Java are generally far better than for C++ --
and the lack of a preprocessor to screw up and ambiguate the
interpretation of any piece of syntax you look at, is a huge part of
the reason.
MS tools destroy what Java has to offer IMHO. Only the re-factoring is
better for Java. It's all opinion either way.
I think you have to realize that preprocesing is just a tool and isn't
to be used to solve all problems. Just because I want a hammer doesn't
mean I regard every issue as being a nail. It's very appropriate to
handle cross platform issues, hardware issue, diagnostic code etc. All
of these issues are very relevant to Android. Sure these issues might
be handled differently for a desktop solution where resources aren't as
big of an issue.
Why force everyone to do it the so called right way? Why does C# have
conditional compile? Just because SUN chose not to support
preprocessing in javac doesn't mean they aren't behind it. Maybe they
chose to support it through tools so that j2me code would still work
with j2se? That would make a lot of sense to me. For something they
aren't behind they sure put a lot of effort into it.
It's also a major compilation performance hit. With a significant
amount of pain, you can get Visual Studio to avoid a lot of the
reparsing it requires, but the language basically says that to compile
any particular program file, you have to parse all the #includes,
recursively, processing the same file over and over and over again --
possibly differently each and every time, because INTEGER may mean int
in one case, unsigned int in another, and unsigned long long in yet
another.
And that's a problem for programmers, too. No, I don't mean a problem
for me, that a good C++ programmer knows how to avoid the problems. I
mean its a problem I've had to help MANY experienced C++ programmers
resolve time and time again -- often in vendor-supplied code, rather
than their own. Or when two different vendor's include files conflict
-- or one vendor's include files conflict with their own.
My long experience is that every time someone tells me they need a
preprocessor -- there turns out to be a better way. Sometimes you
replace that with code generation -- but most of the time, code
generation isn't the ultimate solution, either. Often, proper use of
introspection and metadata (the annotation facility, for example)
provide a superior (more robust, more compact, and more maintainable)
solution.
Solve this one for me. BlackBerry has a version of atan2 that is
fixed-point and is much faster that the Math.atan2. How can I take
advantage of this without an interface or an extra function call?
public static final float VecToHeading( float x, float y )
{
//#if PLATFORM_BLACKBERRY
float fAngle = ((float)Fixed32.atand2( (int)(x * 65536.0f), (int)(y
* 65536.0f) )) / 65536.0f;
//#else
//@ float fAngle = ((float)Math.atan2( x, y )) *
57.295779513082320876798154814105f;
//#endif
if ( fAngle< 0.0f )
return fAngle + 360.0f;
return fAngle;
}
Here is another one. The math function is in two different packages.
//#if PLATFORM_BLACKBERRY
omega = (float)net.rim.device.api.util.MathUtilities.acos( cosom );
//#else
//@ omega = (float)java.lang.Math.acos( cosom );
//#endif
And that includes the use here -- of selecting what code to run. For
that, often the solution lies in correct modularity of the program.
Trust me -- littering your code with conditionals does not improve it.
Actually laying down some surgical preprocess strikes within my code has
allowed me to finish the project without having to create more code that
I would have to manage and pay for at run-time.
--
Leigh McRae
www.lonedwarfgames.com
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
