On Aug 4, 6:56 am, Leigh McRae <leigh.mc...@lonedwarfgames.com> wrote:
> On 8/3/2010 11:23 PM, Bob Kerns wrote:> You have a very limited view of the
> techniques available.
>
> For Java that could be true but my C/C++ fu is just fine thank you.
I can't see that I said anything about your C/C++ fu. Seems we were
discussing Java. You might possibly generalize that to "languages in
general", but not back-narrow it to C/C++.
> > On Aug 3, 10:39 am, 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.
>
> > False:
> > "Preprocessor usage should be eliminated."
> > -Bjarne Stroustrup, "An Overview of the C++ Programming Language",
> > page 3, under table "Language-technical rules:"
>
> > This concept carried over into the C++ standard committee. Hardly
> > "just my opinion". It's not removed, because C compatibility is a
> > higher-priority concern.
>
> Not false, just your and Stroustrup's opinions. To be fair there are
> likely a ton of others that agree just as there are a ton that are happy
> to have them WHEN they need them. Just because Stroustrup is the father
> of C++ doesn't mean he is law. Lots of people are still pissed about
> multi-inheritance but just like the preprocessor it's a tool and people
> should get over it and either use or don't use it. Also Dennis Ritchie
> has a longer beard than Stroustrup so that trumpts it :)
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++).
> 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 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).
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.
--
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
