[OT] [sdiy] IN your mind, what is ....

[Shokwave]

----- Original Message ----- 
From: "Magnus Danielson" <cfmd at bredband.net>
(and Rainer, intermixed)

> > > "C structs that can contain functions".
> >
> > Uhm... C structs can contain functions, even without ++. How about
> > something like this:
<snip>
> > People just dislike pointers nowadays :)
>
> Yeap. Also, how the hell do you think things work under the hood anyway?

Hehehe. Calm down, fellas...I'm a 39 year old inveterate C programmer, and
used to rolling my own linked lists for everything, and yes, I used tables
of function pointers to program large GUI's on the Amiga in the late
eighties and liked it.

Mind you, given that a huge percentage of the nastiest bugs to track down in
any C program are generally related to a wandering pointer, there is good
reason to be wary of pointers flying everywhere in your coding style. I did
it for years, but I'm trying to cut back ;)

Take away my direct memory access, and I bitch. Take away my swiss army
knife, I bitch.
Don't get me started on garbage collection, feh.

> I don't need that level of C++ education, I am way beyond that state since
> early 90thies. Inheritance, overloading etc. etc. There is a "STYLE" of
C++
> which people talk about, but it doesn't make sense in all the googoo
people
> talk... and that sense is what I want to hear. Look at the Objective C
manual
> and there you see things very clearly motivated and you also get good
"under
> the hood" motivations for doing things this or that way. I don't need the
> fluffy pictures and vauge connections, I want to know what the hell is a
good
> way of writing C++ stuff and WHY! When do what. A really good C++
programmer
> will understand my frustration, but I haven't had time to bother any of
the
> once I know. I want to have it written down so I can read about it in my
own
> good time.

Well, now that we know what you really need...we probably can't give it to
you. You still missed my overly-subtle point (or maybe you don't believe in
it). My fault.

You start with your data. Always. Everyone knows that, everyone pays lip
service to it...and too many C++ jockeys let all the cool things they can do
with the language come between them (and especially the *other* programmers
on the team) and the data and data-structures. Unfortunately perhaps, with
C++ there isn't any one true way. Every project is unique, and so is every
team. I work with RT stuff (video games) that is very complex and yet
requires a level of performance that can be impossible to attain if you need
to go through 13 layers of indirection to get at the data that is driving
the current frame's calculations. The first major game that I ever heard of
to attempt using C++   will remain unnamed, but; they "designed" the game
along what they thought were proper C++ principles, with the initial result
that the main ship had so many layers of inheritance and abstraction going
on that it took longer to "find" the data for the polys that needed to be
drawn than to actually DRAW them! Extreme example, but all this
data-hiding-access-everything-through-accessors-and-all-objects-are-instance
s-of-the-one-true-bolt programming style makes life hard on the poor
programmers and, often, the poor cpu.

Nowadays, every major development house would have programmers commiting
suicide if the larger projects weren't generally done in C++; we've learned
how much is enough, and how much is too much, and don't you dare take away
our nice tool thank you!

Although I can roll my own pointers as well as anyone I know, I feel sorry
for folks that haven't figured out how to write a generic linked-list
template with a simple iterator; 90% of my linked list coding is done before
I start a project now. I did it once, ironed out all the bugs, and know that
for standard lists it's all bug-free and ready to go. STL advocates know
what I'm talking about, albeit someone else wrote their templates for them.
Nothing wrong with that, AS LONG AS THEY UNDERSTAND WHAT THOSE TEMPLATES ARE
ACTUALLY DOING.

Maybe you'll find that magic book; the closest thing I found is sorta
elementary, but I thought the author had a decent angle on the language: "On
to C++", by that AI star (and mad Lisp/Scheme guru) Patrick Henry
Winston...his best book by far, although merely a very thin
introductory-style textbook.

I think most folks who hate C++ are Windows programmers (lotsa garbage
there, especially in MFC...and DirectX is starting to get a little mad now,
too), or they've been around too many programmers who used every feature of
the language at every opportunity. That's why, when I teach C++, I teach C
first, then tell the budding programmers that "C++ classes are structs with
functions". I find that this approach seems to stimulate useful growth as a
games programmer. I guess such simple, pithy sayings aren't going to
translate out of the classroom and into an email. The Zen of C++ really is.
I'm sure that Deedle & Deedle's take on it won't help you :)

Apropos of nothing: has anyone noticed that the Deedle & Deedle books (no, I
don't use them, other instructors do) are incredibly heavy and dense? I mean
that literally; a textbook that actually has a slightly larger volume will
invariably weigh about half what the Deedle book does!

I marked this OT, as it's going to drive non-programmers (and lotsa
programmers) nuts. I chimed in, because I see the frustration of "how SHOULD
I use C++?" on a daily basis, and I've been there; oh, how I've been there
(self taught C and C++ guy). I'm still there...but I've got something that
works, and I can seem to help my students find something that works, and
it's in a non-trivial environment. In the end, though, everyone has to find
their own approach; I've seen guys that LOVED MFC. Go figure.

-Darren "ommmmmmmWhen you can snatch the pointer from my handommmmmmmHey,
where's that pointer go?" Reid