The plus plus

[Les]

<rant>
But the capability already existed in the way you define your initial
structure.  It just wasn't taught well, nor utilized well, and many
programmers started out on that blasphemy of programming languages
BASIC.
Moreover many people didn't bother to learn that pointers and integers
are not the same entity, and that functions and subroutines should be
defined clearly before being called, all of which is negated by the
design of C++, which remains "Ojbect Oriented" meaning that the tracking
of relationships and object definitions are only actually implemented at
compile time.  This is a severe limitation on the power of Object coding
and Object capabilities, and moreover can lead to errors in
implementation depending on the compiler heirarchy.  Worse many of the
instructors don't even understand how this can be or what the effects
are of an undisclosed object not being consistently defined between
files or over the scope of a project (yes, Dorothy, it can happen).

   I think OOP and GUI development packages are great, but the users of
these packages should be aware of their limitations, their obfuscation
of class races and object constraints, as well as how badly constructed
class modules can really mess up everyone's day that is associated with
the project.  IMO, this is what is really killing Microsoft, not that
their ideas are bad, nor that the problems are insurmountable, but that
the culture of OOP has obfuscated the target of concise capable code
(the three C's every programmer should strive for).

</rant>
Regards,
Les H
On Fri, 2006-11-10 at 19:48 +0000, Andy Green wrote:
> Les Mikesell wrote:
> 
> > I always thought your basic data type in C should be "array of struct" 
> > regardless of the actual elements you plan to use. Otherwise the
> > semantics don't make sense when you start storing things in allocated
> > or shared memory.  You don't need C++ for that - it has been there
> > from the beginning.
> 
> Yes but once you arrive at that concept, after a short while at least 
> two other ideas arrive:
> 
>   - how do I manage init of these structs, allocation of malloc()-ed 
> elements and free()-ing them to avoid leakage?
> 
>   - how do I build on this struct and functions dealing with it, made at 
> such care are cost, where I have needs that in turn build on the 
> valuable capabilities I made?
> 
> these are inherent, inescapable needs that follow from the creating of a 
> valuable data-structure-and-associated-code.  That's why they bothered 
> to make a C++ grown out of C.  They have been there and done it years 
> ago, Les!
> 
> -Andy
>