TIP: Click on subject to list as thread! ANSI
echo: aust_c_here
to: david nugent
from: steven pasztor
date: 1996-04-11 00:32:02
subject: Re: Pascal - C

Welcome nugent david...


Wednesday April 10 1996 05:59, david nugent wrote to steven pasztor:


 sp>> Hello?  Anyone there?  Hello?
 dn> Nope, we've all gone home.

 Figures.


 sp>> What's the closest one can get in C++, to Borland Pascal's
 sp>> enum/sets?
 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.

 Hmmm....?  Since enum's in Pascal have to be consecutive integers, a
simple inc or dec will work just fine, as I dare say would be the case in C
if the same conditions existed...  Or is there some deeper and much more
meaningfull point you're trying to make?


 dn> Since you mention C++ specifically, and not C (yes, indeed there is a
 dn> VAST difference between the two even if C++ is an almost-superset of
 dn> C), then I'll also mention that if you define a class to emulate an
 dn> enumerated type, you can easily do the same 'hiding', and an
 dn> overloaded operator++ and operator--. Sets are trivial to implement in
 dn> C++.

 I am aware of the existance of the VAST difference, which all C (and it's
ilk) people seem like ramming into each other time and time again!

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


 sp>> And is it possible to do something like Pascal's nested
 sp>> procedures?
 dn> Not under either standard C or C++. However, some compiler
 dn> implementations such as Metaware's High-C, do have this (non-portable)
 dn> feature.
 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.

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


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

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


nevets


... Can you believe that thing is STILL moving?
--- FMail/386 1.0g
* Origin: HELP!!! (3:632/103.123)
SEEN-BY: 50/99 78/0 620/243 623/630 632/103 348 360 998 633/371 634/384 388
SEEN-BY: 634/396 635/301 502 503 544 639/252 711/401 409 410 413 430 808 809
SEEN-BY: 711/932 934 712/515 713/888 714/906 800/1 7877/2809
@PATH: 632/103 348 635/503 50/99 711/808 809 934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.