Carter Smith said:
....and that's proof that you don't know the meaning the word "Syntax".
Syntax is the set of rules that govern what form legal statements in a
language.
Returning a null pointer clearly has nothing to do with syntax.
Syntactic issues should not be trivialized in any case: to do any
programming, one has to learn the syntax of the language to be used.
I always check to see if a pointer is not zero before using
it and default it to 0. Not so surprisingly I've never had a problem with
it. That statement also assumes that you should use "new."
No, it does not. It's a FACT that new is part of C++. Anybody who is
ignorant of new is clearly ignorant of quite a substantial portion of
C++. Anybody who is ignorant of dynamic allocation in generaly is
ignorant of a substantial portion of programming.
If you're doing
real time programming you simply can't use new and delete because they're
horribly slow.
Quite the contrary -- there are dynamic allocators that are perfectly
capable of providing real-time response.
In any case, "slow" and "real-time" aren't necessarily mutually
exclusive. In a real-time system, speed must be predictable and
dependable. In many cases, you forego the highest average speed in
favor of something that has more predictable speed.
Just for example, consider two dictionaries, one based on a balanced
tree and another based on hashing. In a typical situation the
hashing-based system will be substantially faster -- but also
substantially less suited to real-time use.
The reason is simple: hashing has an expected complexity of O(k), but
a worst case complexity of O(N). A balanced tree has an expected
complexity of O(lg2 N) and a worst case something like O(2 lg2 N).
Getting back to dynamic allocation we have a similar situation. Just
for one example, one typical optimization of the buddy-system
allocator is lazy merging of freed blocks. This improves speed on
average, but hurts predictability. An "unoptimized" buddy-system
allocator has fairly predictable response -- it does a maximum of
Lg2(N) block splits during an allocation, and a merges a maximum of
three blocks when freeing memory. As such, validating a buddy-system
allocator for real-time use is entirely within the realms of
possibility.
A* relies heavily on allocating and deleting memory and with
new and delete you'll never get it fast enough unless you're only covering
short distances. This is what most tutorials for A* do which is why the
authors don't bother to point out that their implementation is horribly
inefficient. It looks fast to them. It's still necessary to know about
malloc and free so that you can make an informed decision about which to
use. You can't just rely on brute force Ghz all the time.
You seem to lack not only knowledge, but common sense as well.
Knowledge of how new works certainly does NOT imply relying on "brute
force GHz all the time" or anything like it.
Wrong again.
You don't get exception handling in many languages.
We were talking about C++. If you want to discuss some other language,
you're clearly in the wrong newsgroup. Even if other languages were
topical, you can't claim to learn programming in general by ignoring
things because they're not present in all languages -- after all, the
original BASIC lacked such things as real functions, while some
functional languages lack assignment. If you refuse to learn anything
that isn't present in both, you're left knowing nothing.
It's better to
write code that crashes when it's broken so you can eliminate the bad code
or bad cases that cause exception errors rather than relying on additional
code to serve as a crutch for other code. That's what debug is for.
Clearly you lack any clue of what exception handling is for.
That's a syntatical debate. Many languages don't have templates.
The difference between templates and inheritance goes far beyond
syntax. Again, if you're interested in a language that lacks
templates, you're clearly in the wrong newsgroup. Again, learning more
than one language is no excuse here either: Ada and Java (for a couple
of examples) provide facilities similar to C++ templates.
That's an educational debate. Do you want to know how something works or
just use a magic black box? It's often the case that it's a bad idea to use
an existing library because libraries are not consistant across languages.
"Across languages" is meaningless in a newsgroup devoted exclusively
to C++. In any case, I haven't said anything about people not learning
what would be necessary to write a string class, a matrix class, etc.
Most such things, however, involve a great deal of drudgery from which
there is little real learning. Worse, the books I'm thinking of don't
even use them for real study in themselves -- they simply included
them once upon a time when C++ lacked them, and now the continue to
use them, even though they're clearly obsolete.
Long ago I refused to use C because it relied on libraries. I could do
better graphics with more colors but everything was hidden so it was
pointless. I wanted to know how things worked. I learned a lot more by
doing things the hard way. I've done a few dozen tutorials on software
rendering already and I'm far from done. Sure, I could do a bunch of
lessons in OpenGL or DirectX but that's boring and not too educational. The
math used for software renderering rears it's ugly head outside the realm of
graphics as well. So you can't hide behind OpenGL and DirectX forever.
Apparently the C++ standard library can be added to the list of areas
of which you're grossly ignorant -- neither DirectX nor OpenGL is
included in the standard library.
In any case, I haven't suggested enforcing ignorance of any subject.
If somebody wants to study what's in the library in tremendous detail,
more power to them. If, however, they insist on a book that pushes a
string class (or whatever) that's now obsolete, and (worse) was a
piece of crap even when it was new, that's a whole different story.
And yet we still use books filled with algorithms that were first written
decades ago. Some before there were even computers.
I'm starting to think this must be a troll: you don't really expect us
to belive that you're such a complete idiot that you don't recognize
the difference between an algorithm and a language do you?
A lot of people value syntax above all when it comes to languages. And this
is why we have students who learn Java who are then completely lost when
they're presented with C/C++. Or the other way around. It's a very rare
programmer who only uses one language their entire career. They're also not
particularly valuable to an employer.
It's generally better to know "syntax" (or nearly any other word)
means before throwing it around so much. In any case, learning C++
well is hardly a bar to learning another language -- quite the
opposite; every feature of any one language is almost certain to have
a counterpart in some other language. As such, the better you learn
one language the more prepared you are to learn other languages AND to
start to make the connections that lead to an overall understanding.
Limiting the student's view of each language tends to enforce the
notion that each is unique unto itself.
The concepts taught in older books are just as revelavent now as they were
when they were first written.
You can repeat that as often as you want, but it's just NOT TRUE. Just
for example, I have one old book that goes into exhaustive (and
exhausting) detail about how to design constructors without exception
handling. Offhand, I can't think of ANY current language to which such
a discussion would apply. It was only ever meaningful by accident.
Not every language has templates and the STL
so at some point you need to know how things work on a lower level.
Which doesn't mean you need to remain ignorant of how they work at a
higher level. Learning templates (for example) does not suddenly
remove all knowledge of how to program without templates. Certainly
nobody can learn C++ using ONLY templates, without any other code. As
such, your argument is vacuous at best, and shows that you're either
ignorant of the subject matter or being deliberately decietful.
If you
intend to get into console programming you'll probably need assembly as well
since not every game system runs at 3Ghz. Which is why my lessons on
software rendering will eventually go to assembly.
You're welcome to write tutorials in any language you choose -- though
given the ignorance you've displayed so far, I can hardly imagine your
writing an assembly language tutorial that was worth much. I would
note, however, that regardless of how good or bad it is, a tutorial on
assembly language won't be topical here.
Mark Twain said that people who could spell words more than one way were
more intelligent that people who could only spell them one way. It's the
same thing with programming. You still need to know how to do things The
Old Way(tm) so you can make informed decisions about which is The Better
Way(tm) to do something. You can't just assume that the New Way is The
Better Way.
I, at least, have not advocated any such thing. If somebody is going
to learn C++, they need to learn the language as it exists today, not
as it existed 15 years ago. That does not denigrate the value of the
parts of the language that existed 15 years ago, nor the parts that
were "inherited" from C that existed 30 years ago.
Nonetheless, somebody who learns only about C as it existed 30 years
ago does NOT know C as it exists today, and somebody who knows C++ as
it existed 15 years ago does not know C++ as it exists today.
I'd also note that none of the concepts I mentioned is unique to C++,
or anything close to it. For example, some languages have exception
handling and others don't -- but exception handling has been around
quite a while now (at least as far back PL/I in the mid-1960's). A
pretty fair number of modern languages have exception handling --
enough that anybody who wants to know much about programming in
general needs to understand it.
The same is true to some degree or other with templates as well: while
there are certainly specific techniques that apply to C++ templates
but not (for example) to Ada generics, many ideas are common to both.
In the end, all of your arguments are self defeating: learning more of
one language does NOT prevent somebody from learning other languages
-- quite the contrary, it generally helps. The restricted subset you
seem to advocate will HURT a student's ability to learn other
languages and (especially) to learn programming as a whole rather than
viewing each language as its own little island. C++ is particularly
strong in this regard because it espouses enough paradigms and
provides enough features that a student who learns it well will be
provided with links to nearly any other language you can name -- but
restricting the view will reduce those connections.
