dn>> C enumerators are basically the same thing. But you can't declare an
 dn>> enumerated variable in increment/decrement it over the list. You have
 dn>> to do that manually, which is pretty much what Turbo Puke does anyway,
 dn>> only it is 'hidden' in your code.

 sp>  Hmmm....?  Since enum's in Pascal have to be
 sp> consecutive integers, a simple inc or dec will work
 sp> just fine, as I dare say would be the case in C if the
 sp> same conditions existed...

No - at least in respect of enumerated types - they cannot be incremented
or decremented in C++. You may indeed assign them to integers which can be
incremented or decremented, but at that point you've removed the context of
the enumeration.

And, as I think you are aware, C's enumators are not necessarily
consecutive values, nor even unique.

 sp>  Hmmm.....  Maybe it's just the late hour (as usual
 sp> these days, I'm writting this in the morning... :-( ),
 sp> but I fail to see how it could be handled generically,
 sp> and to my way of thinking, one of the criteria of
 sp> something being trivial is that it only need be done
 sp> once to work for all similar opperations (ie. Being
 sp> generic)...

I was referring to sets there (which C/C++ provides no direct or even
indirect equivalent), and yes, they can be handled "generically"
without too much fuss. Set behaviour is fairly easily done by creating a
generic abstract base class and/or class template. I have several
variations of this type of beasty which I use from time to time. They're
useful when you have to do a lot of "for all elements in this set
(which are not necessarily consecutive), do this".


 dn>> The problem with introducing this into the general C/C++ climate is
 dn>> that the benefits of a inherited/shared stack is not available or is
 dn>> difficult to implement on many systems, or of little practical use
 dn>> when all is said and done. In general, it is eaiser and simpler to use
 dn>> pointer-to-structs anyway, and there's little, if any, loss of
 dn>> efficiency and an arguable gain in code readability and
 dn>> maintainability.

 sp>  I don't know...  Pascal knows that the variables it's
 sp> accessing will be at a place specified by
 sp> SS:[BP+something].  C on the otherhand would have to
 sp> waste a segment register into which it can stick the
 sp> segment of the variables... That would surely account
 sp> for something!

Sorry? What's this "segement register" thing?

OH, you mean those silly segment registers they use on Intel's in 16-bit
environments? Don't think I've actually programmed on one of those in a few
years now. :)

Perhaps this will help you see my point. "Segment registers" is
an intel concept. C is implemented on many MANY more platforms than intel.

And no, in reality it does not accont for much.


 dn>> BTW, you left the word "Borland" out before the word
"Pascal". Nested
 dn>> procedures is not a feature of ISO Pascal.

 sp> Picky.

No, not at all. Borland Pascal is the name of the language that the Borland
Pascal compiler implements. It has no standard, and confirms to whatever
the Borland implementors wanted it to.


 sp>  I assumed that the "Borland" on the first
 sp> Pascal would be taken as a context specifier for the
 sp> entire message...  I did the same with C++...  I
 sp> suppose we could also insist that "Borland C++" be
 sp> written rather than just "C++"!  Gets rather tiresom
 sp> after a while.

No, your preception is incorrect. Borland implement the "C" or
"C++" language (depending on the compiler's mode at the time) and
there is nothing at all "Borland" about it. That's the
distinction I was attempting to make (and which you obviously failed to
understand). If "Pascal" was the language, then you'd have to
look at which specific "Pascal" a compiler conforms to; and there
is an ISO Pascal that is not a lot like Borland Pascal.

Certainly Borland do provide some proprietary functions in their C/C++
libraries; nevertheless, their compilers do implement "The C++
language" since there is no such thing as a "Borland C++
language".

It is a pity you missed the thrust of what I was saying previously since it
did answer your question in depth quite directly. Borland Pascal is an
intel specific environment that works under two operating systems (that is,
if you count MS Windows as an operating system, which is debatable). C, on
the other hand, has nothing "intel" specific about it, nor is it
owned nor directed by any specific vendor, nor geared towards any
particular hardware, operating system or environment. Yet it does this
without any significant loss of efficiency on any of those platforms. Using
C/C++, you can implement a program that compiles on multiple platforms. You
simply cannot do that with Pascal.

I'm not trying to advocate C/C++ over Pascal here - just pointing to a
fundamental difference in the design philosophies between the languages.
When you have to take into account that the stack may grow up instead of
down, require specific alignment, not grow larger than X bytes before
overflow, or that the stack is not even CPU assisted or may require
specific types of assistance, then limitations can and do apply. C solves
the 'efficiency' problem of nested procedures in other ways.

--- MaltEd/2 1.0.b6