<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 >
