As I said in my example, I don't want to pay an extra function call when
the code is in a hot spot. Even if the code isn't in a hot spot there
is a much worse case to deal with and that is death by a thousand cuts.
If a real-time game on a phone was written with all these interfaces to
make the Java gods happy then you would have a big problem trying to
fix. Then you would be calling out to the C gods for a preprocessor.
On 8/3/2010 10:01 PM, Bob Kerns wrote:
To take this a bit further: Platform can be an Enum, that implements
an IPlatform interface, and you can attach methods to BLACKBERRY and
friends to do the platform-specific stuff.
Then this becomes:
Platform.OS.doStuff();
And you don't have to touch it when you add a new platform.
On Aug 3, 6:55 pm, dm1973<david050...@gmail.com> wrote:
if (Platform.OS == BLACKBERRY){
// DO blackberry
}else{
// DO JAVA
}
class Platform{
static final int OS = BLACKBERRY;
}
The only trick part is doing the imports. Stub classes are a one way.
Interfaces (don't worry about the performance overhead. Count on the
JIT to optimize the code until it is proven to be a problem. HotSpot
is great at optimizing simple cases like this. I expect Dalvik will be
also in another year) are another way. You could also do a build
system approach (include different versions depending on what you are
doing). Even in C/C++ #define code like this is rarely the best way to
go. I always put platform specific code in platform specific files.
Some of that is personal preference but my team found it much easier
to maintain.
On Aug 3, 1:39 pm, Leigh McRae<leigh.mc...@lonedwarfgames.com> wrote:
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 McRaewww.lonedwarfgames.com
--
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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
