Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!uw-beaver!milton!sumax!polari!rwing!seaeast!burklabs!ronb
From: ronb@burklabs (Ron Burk       )
Newsgroups: comp.windows.ms.programmer
Subject: Re: What does Yield do?
Message-ID: <cVm022w163w@burklabs>
Date: 20 May 91 21:57:59 GMT
References: <1991May17.002102.14533@mnemosyne.cs.du.edu>
Organization: Burk Labs, Redmond WA
Lines: 70

ebergman@isis.cs.du.edu (Eric Bergman-Terrell) writes:

> General question:  How is programming Windows in T. Pascal?  What's easier
> than using C?  What's more difficult?  How do you get statically bound
> variables?

Having just written the same program in TPW, C++, and C, I can give
my preliminary opinion.  I prefer the TPW development environment to
any of my C/C++ compilers because it is a fast and it is a real Windows
app (no shelling to DOS).  The debugger is still character-mode, however.
TPW gives me more compile-time checking than C, but (surprisingly) less
than C++.  There are several object-oriented-related things that C++
detects at compile time, whereas TPW detects it only at runtime.  For
example, you make a TPW class "abstract" (in the C++ sense) by defining
a virtual func that calls the proc "Abstract".  Unfortunately, that
just causes a runtime error if the user fails to replace the virtual func.
In C++, of course, the compiler detects attempts to instantiate a
virtual class.

Other than the standard complaints when switching to Pascal from C (no
break/return statements, etc.), the main hassle for my 1000-line program
was null-terminated strings.  TPW adds some functions for switching
between C-style strings and Pascal-style strings, but converting back
and forth is a pain.  Windows, of course, wants null- terminated
strings.  I guess another hassle was the way constructors and
destructors work in TPW.  You have to call the dang things explicitly!
First you declare (or allocate) a variable, then call it's constructor.
If you forget to call the constructor, well, you must've had
some good reason to not want it initialized.  A more inconvenient
example occurs with inheritance.  Suppose I want to inherit
from a TPW class called TWindow and override it's constructor
(assume TWindow has a constructor that you pass a string containing
the window title):

type
    MyWindow = object(TWindow)
        constructor Init(Title:AString);
        {...}
        end;

Well, if you want the TWindow constructor to still get called,
you have to remember to do it yourself, like this:

constructor MyWindow.Init(Title:AString);
begin
    TWindow.Init( AString );
    { my added initialization }
end;

It is also possible to end up with a constructor that assigns
the parent's virtual function table to the object by mistake.
This took me several hours to track down.  Of course, once
you learn where the major pitfalls are in a language, you avoid
them without thinking.  C++ has it's problems, too, but it does
catch more problems at compile-time than TPW does, in my opinion.

I'm not sure what you mean by "statically bound variables".  The TPW
combination of units and objects gives you the most-used facilities of
C++ classes.  For example, the static data members of my C++ class
became global variables in the implementation of the unit containing the
corresponding TPW object.  Pretty much the same effect (only functions
in the unit's implementation can access them).  C++ still has
finer-grain facilities than any OO language I know of.  In TPW you
get private or public object members, no protected.  Inheritance
is public, no other options.

I was pleasantly surprised by TPW.

> 
> Terrell