Dave Smith <[EMAIL PROTECTED]> writes:
> Levi Pearson wrote:
>> C++ is hugely complex and has a myriad of ways to do things, so it's really
>> a tool that requires deep knowledge of the language, available libraries,
>> and best practices to use well.
>>
>
> I disagree with 2 of your 3 statements and only partially agree with
> the other. Let me respectfully address them below, in the interest of
> an edifying discussion. Please set me straight where I err.
I think we agree more than you seem to think we do.
> First, you contend that you must have a deep knowledge of the C++
> language to use it well. Let me address that point last, because I
> partially agree with you on that one.
I was probably not very clear with my intent here. Instead of 'use
well' I should have said something like 'get advantages over a safer
language like Java'. And there are definitely advantages to be gotten
from using C++, but they require deep and broad knowledge and come at
the cost of some safety.
> Second, you contend that you need deep knowledge of available
> libraries to use C++ well. Is that not also true of all languages?
> Those who are ignorant of the useful libraries in their language of
> choice are doomed to reimplement them. This surely applies to all
> languages. Are you perhaps inferring that C++'s standard library is so
> lacking that you have to go to outside sources to make it usable? If
> so, I agree, but Google can help. However, I still contend that in
> order to make good use of any language, you have got to be familiar
> with the available libraries. This is especially true of Java, which
> alone isn't much of a tool, but when coupled with the myriad of
> outside libraries, it's pretty capable.
C++ has lots of libraries available and they're not all of the same
quality or even implementation style. There's crazy template-heavy
stuff in Boost, there's object-oriented stuff in some places, etc.
Qt, which you mention later, kind of does its own thing.
Java, on the other hand, is less flexible in style and therefore
everything follows the same general object-oriented style. Java also
comes with a lot more functionality built-in and standard. This has
advantages and disadvantages, but I think in general it's got a
learning curve that's not nearly so steep.
> Third, you contend that you must know C++ best practices to use it
> well. Are you saying that there are languages that *don't* require
> developers to employ best practices to use the them well? I think this
> is common to all languages. Perhaps you are inferring that because
> there are so many ways to do an individual task that it is too hard to
> guess the best one without a deeper knowledge?
I'm saying that if you don't know when to use auto pointers, RAII,
RTTI, all the rules about how to handle virtual functions, etc. you're
going to be at a serious disadvantage. I'm not an expert at either
C++ or Java, but Java seems to have a lot fewer of these subtleties to
learn before you can write decent code. For another comparison, look at
Stroustrup's book on C++ vs. the K&R C book. Also the C FAQ vs. the C++
FAQ, which is a rather fat book and not even available for free online
last time I checked.
So, yes, you ought to learn best practices for any language you use.
In some languages, however, they're more about codifying common sense
than mapping out a path through a minefield. :)
> Now back to your first argument, that you must have a deep knowledge
> of the language to use it well. I don't think this is entirely
> true. You certainly have to know some things, on which topic I have
> two pieces of advice:
<advice elided>
That's great, but that will probably get you to the point where you
can write code that's on par with what the average Java Joe writes.
This is not to say that Java is bad, just that it's got a different
set of tradeoffs that necessarily limits the control you have over
your system's performance.
Basically, I compare C++ to the contractor-grade tool and Java to the
pro-sumer grade tool. Both do roughly the same thing, but the
contractor-grade tool has got the safety shields removed and has a
tendency to kick back at you if you have poor form. You can get
similar results with either as long as you've got moderate
proficiency, but the contractor-grade tool lets you take things to
another level if you've got the chops to handle it, plus you can swap
out parts when necessary. The pro-sumer grade is a one-size-fits-all
that's pretty adjustable, but only within the parameters set by the
factory.
Of course, if you give the novice the contractor tool, he's likely to
take a finger off, or worse. :)
> You certainly don't have to understand some of the language's cobweb
> filled corners like virtual inheritance and the unfavorable diamond or
> recursive template meta-programming to be a good C++ developer.
Well, maybe you don't have to, but you definitely need to have someone
who does handy to review your code then. Or at least know what areas
of the language to avoid.
> Here are a couple other examples of why C++ is a great programming language.
>
> 1. Qt's foreach macro. The language designers did not write a sane
> foreach. In fact, the one that ships with the standard library is a
> steaming pile of unusable poo (unlike most poo which is not steaming
> and at least somewhat usable), but Qt managed to use cool language
> features to make a nifty, useful, and type-safe foreach macro that
> *feels* like part of the language despite being added many years after
> the most recent language revision.
Language extension is one of the cool features of C++, but it's also a
potential source of pitfalls for novices. The Qt macro you speak of is
probably done reasonably well, but textual substitution macros are an evil
thing and, if written or used improperly, are liable to cause enormous amounts
of pain and suffering. Also, overloading operators can hide expensive or
unorthodox operations from people who aren't expecting them. Again, a
trade-off.
> 2. Macro-based debugging. Using the macro system, you can remove and
> insert entire chunks of code just by flipping a flag in your
> makefile. In other languages (like Java and Python), you'd have to do
> some serious magic to actually *remove* debug code from your software
> at release time, rather than just wrap them in false conditionals, to
> get the same kind of performance as C++.
Any compiler worth its bits ought to be able to eliminate unreachable code, so
I don't think this is necessarily as big a win as you say, though macros are
nice. If only there was a sane macro system available that operated on the
parse tree rather than the text...
> 3. A linker! Why don't other languages have linkers these days? It's
> such a pain to kludge together jar files that you hope have all the
> classes you need to ship in one bundle. I know the Mono team is
> working feverishly to finally write a linker after how many years?
> Using a C++ linker, I can create a single binary that will run on just
> about every Linux distro (even spanning kernel versions).
Yeah, this is nice, but not a big deal. You can link Java code with
gcj, if you want.
> 4. Templates. Templates are cool when used properly, and type safe. Of
> course, templates can be abused, so use with caution. This is one of
> those areas that requires a little bit of "deep knowledge." :)
I love the idea of generic programming. The implementation of it in
C++ is lacking, though. See an ML derivative for sanity here. C++ is
the way it is for efficiency reasons, though. Efficiency reasons and
compatibility with C are why its abstractions are all full of holes,
it has fewer safety guarantees than other modern languages, and
especially why it continues to have so many adherents. :) I'm glad
that a language like C++ exists, but I will continue to believe that
it's a tool best reserved for those who really need the extra control
it gives you over a language like Java.
> 5. Speed. For most user-interactive desktop applications, you still
> can't JIT fast enough to match C++'s raw speed.
Most user-interactive desktop applications aren't really dealing with
'raw speed', whatever that means. I'm not really sure where the
slowness of modern desktop applications comes from, but I'd point the
finger at the mountains of code beneath the surface before I pointed
at the language implementations at the foundation. When it comes to
raw calculating speed, Java and C# are actually pretty fast these
days. It's when you need to do custom memory handling for good
performance that C++ wins.
> Anyway, I'll get off the C++ pedestal. Sometimes I feel like I'm still
> rooting for the losing team, but for certain applications C++ is just
> great, even if your last name isn't Stroustrup.
I agree, C++ is a great tool for some applications. I haven't needed
to write any of those, though, so I stick with C, which is at least
fairly simple and ubiquitous, and sane languages. ;)
--Levi
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
