On 8/4/2010 1:02 PM, Bob Kerns wrote:
Mine's pretty long, too. But you missed the point. I wasn't just
citing an opinion. I was citing the rationale for why C++ strove to
minimize dependence on the pre-processor, from a list of faults of the
C language they wanted to address.
Me too! So why not just throw in some very simple preroccessing
instructions into the mix and make it happen :)
Because C/C++ preprocessing messes everything up, including (or
especially) macros.
Let me make that a bit more clear. It's not the fact of a pre-
processing step being involved that is the problem.
It is more specifically that C/C++ preprocessing is completely
decoupled from the language syntax. It's that you have to preprocess
to even know whether you have valid syntax or not. It is #ifdef and
the lousy C++ macros that are the problem.
Otherwise, you could just regard macros are part of the language
syntax (as in most any other language macros), and regard the
"preprocess" step as merely being the first compilation phase.
If you people would stop arguing for specifically C/C++ preprocessor,
and argue for a restrained-and-sane macro facility instead, I think
you'd get a lot further.
For example, you could ask for something like:
if (__compile_time(OS == OS_BLACKBERRY)) {
result = funny_atan2(b, a);
} else {
result = Math.atan2(a, b);
}
which has none of the problems we are discussing.
Nor does:
if (OS == OS_BLACKBERRY) {
@CompileTime
result = funny_atan2(b, a);
} else {
result = Math.atan2(a, b);
}
The compiler can be required to ignore the failing conditional in
either case, and you have exactly the same result as the C/C++
preprocessor, without the headaches.
But for some reason, you people never ask for that. And I've never
thought to point that out before. Strange -- on both sides.
(I hope it's clear that "you people" is self-defining here as C/C++
people who expect Java to have a preprocessor -- just like C/C++).
I am only talking about Java/j2me and how it's to be used in an
embedded system like a phone. With that said it's far more reasonable
to ask for a simple tool that can be integrated without having to change
anyone's code than to try and change a language. I don't even care care
to debate j2se/ee as I am only using Java because that's what BlackBerry
and Android use.
Oddly enough I was just looking around the android-os code trying to
figure out some opengl stuff and it's riddled with conditional
compiles. Silly rabbits, preprocessing is for kids. Can't they figure
out some golden abstract generic templated foo to fix that?
Actually I just showed two real world examples and all answers just
skirted around the issue and ignored the performance hit.
Apparently you did not understand my responses. My solutions had ZERO,
yes ZERO performance hit -- resulting in exactly the same sequence of
instructions as your preprocessor would produce. Same result,
different approach. No need to preprocess in Java when there are other
techniques available.
I am all for a solution. As far as I can see your enum isn't really and
different than an object with a method call. Plus you still haven't
solved the import issue. On top of that there is more code to
maintain. Sure you can use code generation, which preprocessing is, but
it makes working with the code much harder in eclipse. The preprocessed
solution is 100% guaranteed to cost nothing extra and solves the import
in one shot.
I am not arguing that Java could not be improved. I was offering
solutions with the Java we have today, and tools that exist today
(sometimes in awkward form, that might require some programming on
your part, and extra effort to integrate into the IDE and/or build).
Because of the cost to everyone else of the feature you are demanding.
Why not put in every hair-brained feature anyone thinks they'd like to
use?
It's not hair brained. Just more opinion.
Please read more carefully. I did not call your feature hair-brained.
(It's hair-brained. OK, now I did).
Nice.
I offered an reductio ad adsurdum argument against the strategy of
putting in everything people ask for just because they want them.
I would have thought C# was to compete with Java and fix main of the
things that Java got wrong. Don't get me wrong, I am surprised
actually how little I hate Java.
Yes, quite right. And one of the things they viewed as "wrong" was
that C/C++ programmers didn't like it for various comfort reasons, so
they made it more C/C++-like. And then to keep the Java folks happy,
they made a Java-like version, too.
I don't hate C#, though I am not sure the world needed another
language or two. The main drawback is that it's proprietary, coupled
to a proprietary API. I haven't targeted that API much since it came
out, but I'm very happy they came up with an alternative to C++ for
targeting that API.
And there is nothing wrong with my C++ fu, though recently I find it
harder to call it up.
Or maybe because the J2ME people actually WERE former C programmers.
Then they were never programmers to begin with.
Huh?
Beard.
Mine is long and grey. Oddly, my ponytail is not. And I'm taller; that
gives me more authority.
Nice. You make very valid points and I can see you clearly know your
stuff but I think at this point we should just agree to disagree.
Nothing is going to get changed anyway.
--
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
