Some errors in MIT's intro C++ course

[Pavel]

On 09/18/10 03:49 PM, Daniel wrote:
[...]
Don't forget the biggest convenience of all: programmer availability!

When one of my favourite tool sets degraded to Java (and I do mean
degraded, it's memory footprint grew from about 50 to over 700MB!) I
asked the developers why and they told me they simply couldn't get
enough skilled C++/Motif programmers where Java programmers where two a
penny.

That's an interesting point, to which I'm not sure I agree,
although I can see where a manager might think so. C++ is
clearly a more complicated language than Java.

Is that so clear in practice? I don't use Java myself, but I'm on the
company Java mailing list. There seems to be a huge set of APIs,
frameworks and abbreviations you have to know, and there seems to be
plenty of fashions you have to follow (e.g. FOO-driven development,
where FOO changes quarterly).

It has been quite clear to me. Java Standard API is huge but it does not
add to the complexity for a programmer.

Java syntax is simple (or so it was before an idiotic addition of
worse-than-useless Java generics).

Java API you do not care to use directly does not add to the complexity
even if you use it indirectly (via API you do care do use). You do not
make a mistake in interpreting Java code your are looking at if you are
not aware of the contents of non-directly-imported classes. If you see
an unfamiliar name you know that you don't know what it is and have an
idea on where to look for what it is (in classes/packages directly
imported into your source file or in your source file's package).

In C++, a convoluted syntax (e.g. visually indistinguishable
passing-by-value vs passing-by-reference) and semantics that you do not
care to use but the headers you include use (operator overloading,
user-defined conversions, macros etc) hit you hard. If you see
something like << in the code it often may or may not be one of the
functions you are familiar with and you won't have a clue until you look
up for operator<< declarations in all headers included directly *or
indirectly* (compare to Java) to your source file (that is, to stay on
the safe side, you will have to search through the headers often (or, if
you are lucky to have a very good C++ code browser, to hop through 1000
definitions of operator<< trying to understand which one, if any, will
be resolved for that particular right-side argument and ooh left-side
argument was also not what you thought it was..)).

-Pavel

 

[Juha Nieminen]

Juha Nieminen ha scritto:


You don't have to upgrade your compiler if you don't want to. Removal of
security features certainly sounds like a good reason for keeping an old
version.

Then we get the problem of people using extremely old compilers, like
what you see constantly in this very newsgroup (with people saying that
they are using eg. VC6, and others telling them to upgrade to something
more modern).

Besides, who tells you that the ISO standard will leave bounds checking
optional "for eternity"? Perhaps it will be required by C++2x, or
perhaps at() will be removed.

One of the main principles of the design of the C++ language has been
that you don't have to pay for what you don't use. In this case, if you
don't need bounds checking (because you know your code is correct), then
you don't have to pay for the overhead.

 

[James Kanze]

James Kanze ha scritto:

[...]

Hold on, I was still talking about students in their first
programming course! If you tell them this early about
profiling and different ways of toggling bounds checking, then
they will run away screaming and give up CS...

I totally agree. But when one talks about "preferred form", one
does have to consider more global scope. IMHO, regardless of
the context, compiling without bounds checking before you have a
proven execution time problem is just stupid. (And of course,
studends in their first programming course won't have execution
time probems. At least not ones that can be solved by turning
off bounds checking.)

(Of course, as a teacher you should be able to explain those
things on demand even in a beginner's class, even if you don't
require students to be familiar with any details.)

I tend to agree, but I'm not 100% sure. Knuth certainly argued
for "white lies" at the beginning, until the student is ready
for more complexity, and I can easily consider that in some
cases, just telling the student that he's not ready for that
sort of thing might be appropriate.

int main()
{
std::vector<int> v;
v.reserve(100);
v[0] = 1;
}
If you compile this just with "cl test.cpp", then you probably
won't get a crash.

But if you use the IDE, with the default settings, you probably
will. (I don't have any compilers installed on my machne here,
so I can't check.)

OK, so the question is what to consider the default settings.
Those in the compiler itself or those the IDE invokes it with
if you don't change any options.

In which case, the default settings are different between the
IDE and the command line invocation. For VC++, I'm willing to
bet that most students are using the IDE.

But to get back to your "students in their first course": the
professor should provide the environment, with whatever settings
he deems appropriate. Even in a command line environment under
Linux, an alias or a shell script will provide whatever options
are needed for [] to trigger a core dump.

 

[James Kanze]

On 09/18/10 03:49 PM, Daniel wrote:

[...]

Don't forget the biggest convenience of all: programmer availability!
When one of my favourite tool sets degraded to Java (and I
do mean degraded, it's memory footprint grew from about 50
to over 700MB!) I asked the developers why and they told me
they simply couldn't get enough skilled C++/Motif
programmers where Java programmers where two a penny.

That's an interesting point, to which I'm not sure I agree,
although I can see where a manager might think so. C++ is
clearly a more complicated language than Java. But some of that
complexity is there to allow it to solve more complex problems.
A programmer capable of solving such problems is capable of
learning C++ well. Less competent programmers have real
problems with C++. (I'm not talking of some of the critics in
this thread. They obviously are capable C++ programmers as
well, even if for some reason, they prefer Java.) Since
learning C++ well requires real skill, there are less C++
programmers, but the Java programmers who aren't capable of
learning C++ probably aren't capable of writing good code in
Java either (although they may know Java the language well).

Reading between the lines I think the true picture was more like "we can
get several cheap java programmers for every expensive C++/Motif one"...
I think Motif was more of an issue than C++.

But who uses Motif nowadays? A GUI interface is either Windows
only (and you can get a lot of cheap Windows programmers---who
often aren't any better than the Java ones), or you use some
sort of portable interface (WxWidgets, QT, etc.). (My own
choice would be to do the GUI in Java/Swing, and use CORBA for
the C++ interface. But I gradually get the feeling that I'm in
a minority of one there.)

(Obviously, if you're implementing WxWidgets or QT, you do
program to the Motif interface. But that only concerns a very
small minority.)

 

[James Kanze]

[...]

In my case, I was simply referring to all projects (at work or as a
hobby) I have seen. I don't see any GLIBCXX_DEBUGs in the Makefiles.

The first one I look at has it. But then, that's mine. I
don't have access to any others at the moment.

It should go without saying that I haven't done any major
surveys or seen all C++ code ever produced.

Me neither. But I still would find it "sloppy" not to use the
debugging versions of the library if they were available, and
you could afford it.

 

[James Kanze]

James Kanze wrote:

[...]

Library writers usually can't afford it.

Make that third party library writers.

They rarely have certainty that the performance of a
particular API will never be critical for any client code.

Agreed. And the problem is that you can only turn it on or off
globally, for the entire program (since it affects the size of
std::vector). Which means that if the library has it turned on,
the library can't be used by code which has a time critical use
of std::vector elsewhere.

The obvious solution is to deliver two versions of the library.
Or to deliver source code, and let the client compile it with
the options he feels appropriate. (Long term, I think we're
going to have to go with the latter. It seems like there are
more and more options which affect binary compatibility, and
there's a limit to how many versions you can deliver.)

Thus, in library code you usually use the fastest (that is,
unsafe) API, check correctness explicitly (e.g. with asserts
or more often with library- or company- specific analogue)
wherever necessary and deliver both a debug version with the
checks preprocessed-in and a production version with the
checks preprocessed-out. If you plan to only support VC you
could take advantage of its bound-checking [] for the debug
version but in these days of no MS monopoly it's probably
wiser to invest little more keystrokes and type the checks in
explicitly.

If you support VC, and you are delivering precompiled libraries,
you almost have to provide the two versions. And the "debug"
version will have all of the checks turned on.

 

[James Kanze]

Juha Nieminen ha scritto:

You don't have to upgrade your compiler if you don't want to.
Removal of security features certainly sounds like a good
reason for keeping an old version.

Besides, who tells you that the ISO standard will leave bounds
checking optional "for eternity"? Perhaps it will be required
by C++2x, or perhaps at() will be removed.

Or perhaps std::vector will be removed entirely.

Seriously: at() will not be removed. And the standard will
never require checking, because it does have such serious
performance implications (not bounds checking per se, but all of
the iterator verifications), and they won't want to render a
compiler non-compliant when it is turned off.

Just as seriously, however: checking implementations are here to
stay, and no new implementation will be done without (optional)
checking. You don't go to the effort of implementing something
new just to make it inferior to the existing products.
(Practically speaking, I suspect that Dinkumware will end up
with a monopoly of the commercial implementations, simply
because the other commercial implementations are so far behind
it. And the two major non-commercial implementations: the one
with g++ and STLPort, both support debugging.)

 

[James Kanze]

On Sep 11, 9:05 pm, James Kanze <[email protected]> wrote:

[...]

my compiler it seems just uses unchecked offset from
dynamically allocated pointer... Its a freebie though from Gnu
org or so... hmm.. maybe its just a load of rubbish.. Maybe I
should have bought the VC++6 instead?

Or just update it. G++ added checking in version 3.0.0, IIRC.
Or if you prefer VC++, download their free implementation
(currently version 2010)---they've had checking since version 7
(i.e. since there was a C++ standard to be compliant to).

Obviously, if you insist on using out of date tools, you won't
be able to use the latest features. (I'd avoid templates
entirely with VC++6. They definitely weren't its strong point.
And the library delivered with it was far from standard, because
of this.)

 

[Pascal J. Bourguignon]

One of the main principles of the design of the C++ language has been
that you don't have to pay for what you don't use. In this case, if you
don't need bounds checking (because you know your code is correct), then
you don't have to pay for the overhead.

Even if you know your code is correct, you may be wrong.

Even if you know your code is correct and you're not wrong, alien code
could be wrong and provide you out of bound values.

 

[Juha Nieminen]

Even if you know your code is correct, you may be wrong.

Even if you know your code is correct and you're not wrong, alien code
could be wrong and provide you out of bound values.

That's what compiling in debug mode is for.