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.
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 :)
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.
No, I am not. I have nothing against macros -- on the contrary, I met
my wife teaching a class on macros.
Preprocessors are not the place for them. Lots of languages have
macros without preprocessors. Macros are great! I wish Java had them.
Me too! So why not just throw in some very simple preroccessing
instructions into the mix and make it happen :)
(They do have their drawbacks, but no on the scale of a preprocessor.
And the power of any macros I'd envision is substantially more than is
offered by the C/C++ preprocessor).
MS tools destroy what Java has to offer IMHO. Only the re-factoring is
better for Java. It's all opinion either way.
Are you comparing MS C++ tools to Java tools, or C# and friends?
Anyway, it's not all opinion. Such comparisons can be done quite
objectively. Which tools you prefer to USE is opinion.
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.
Nobody has shown me a case where you need a preprocessor because of
resource issues. "Can use", yes, but "need", no.
Actually I just showed two real world examples and all answers just
skirted around the issue and ignored the performance hit.
It is HIGHLY INAPPROPRIATE to handle platform issues and hardware
issues -- it makes porting to a new platform a royal nightmare. Your
best shot there is diagnostic code -- and there are better ways,
involving post-processors rather than preprocessors.
Why force everyone to do it the so called right way?
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.
Because LONG experience shows, that approach makes for major problems
with languages, and makes them harder to use. Trust me -- that
approach has had its day in the language-design world. Even a poorly-
designed API, not part of the language, can have a major adverse
impact on the maintainability of a product.
I have a good chunk of experience also thank you and I would rather ship
than sit around looking for that golden band-aid that will make me feel
all warm an fuzzy.
And in extreme cases (but only extreme cases), even personal code-
formatting idiosyncrasies can have a negative impact.
"Let people do whatever they want" has, after decades of experience,
been found to not be a good idea. A more careful balance must be
sought.
Why does C# have conditional compile?
To accommodate the masses of C programmers that Microsoft wanted to
attract, of course!
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.
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.
Or maybe they wanted to attract all those C programmers who are used
to "solving" every problem with a #ifdef, and aren't willing to update
their approach?
Or maybe because the J2ME people actually WERE former C programmers.
Then they were never programmers to begin with.
Language purity is not the only design constraint. Soustroup makes
that point himself. Sometimes you make compromises for acceptance.
Computer languages are partly human languages, and human languages are
a cultural artifact that change slowly.
Beard.
--
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
