Board index » delphi » Delphi not "standard pascal"

Delphi not "standard pascal"

Recently I have had to get involved with pascal again (I've
been a long time c/c++, java, javascript, perl programmer).
I've noticed that several of the features supported in Delphi
(we're using version 2.0 in house) are not standard pascal.
So writing a Delphi specific app cannot be ported to another
pascal compiler (i know i know, what other pascal compilers
are there?).

For instance, since when has a programmer ever been able to
assign the return values for a function to some system
provided variable called "Result"? I've only ever known
programmers being able to assign the return value for a
function to the function's name.

Also, when dealing with classes (I thought classes were
objects? back in Borland Turbo "standard" Pascal days)
it is necessary to assign the value of a constructor
call to the variable being constructed? (e.g.
MyInstance := MyClass.Create;).

While it is easy to adhere to the "standards" adopted
by Borland in the Delphi VCL when building applications,
these things do not appear to be standard (in the way that
I know pascal anyhow).

Can someone clarify these points? Maybe I've not programmed
in pascal for so long that new standards have developed.

 

Re:Delphi not "standard pascal"


Quote
In article <348DE0FF.2...@rt66.com>, Mike Powell wrote:
> For instance, since when has a programmer ever been able to
> assign the return values for a function to some system
> provided variable called "Result"? I've only ever known
> programmers being able to assign the return value for a
> function to the function's name.

This one got suggested on the Borland CompuServe forum several years
back and they obviously liked it. The logic is that as the routine has
to make space on the stack to pass back the result you might as well
use it. More often than not you would have to create a variable to hold
what was going to be the result whilst you worked on it, and then
assign this to the function on the last line; no real problem with a
numeric but if it's a 256 char string it saves a lot of pushing,
popping and copying. I like it.

Tony Bryer

Re:Delphi not "standard pascal"


Mike Powell <mi...@rt66.com> wrote in article <348DE0FF.2...@rt66.com>...

Quote
> Recently I have had to get involved with pascal again (I've
> been a long time c/c++, java, javascript, perl programmer).
> I've noticed that several of the features supported in Delphi
> (we're using version 2.0 in house) are not standard pascal.
> So writing a Delphi specific app cannot be ported to another
> pascal compiler (i know i know, what other pascal compilers
> are there?).

> For instance, since when has a programmer ever been able to
> assign the return values for a function to some system
> provided variable called "Result"? I've only ever known
> programmers being able to assign the return value for a
> function to the function's name.

The use of Result is a an option--one can still use the standard way of
assigning a return value using the function's name.

Quote
> Also, when dealing with classes (I thought classes were
> objects? back in Borland Turbo "standard" Pascal days)
> it is necessary to assign the value of a constructor
> call to the variable being constructed? (e.g.
> MyInstance := MyClass.Create;).

Delphi introduces a new object library using the keyword CLASS--the older
version of Turbo Pascal uses OWL as its underlying object library for
Windows, using the keyword OBJECT.  My understanding is that code with the
old OBJECT keyword will compile with Delphi, but this has always been
proprietary to Borland's version of Object Pascal.  I'm not aware of any
standard for Object Pascal such as that for C++, however, if someone else
is aware of such a standard, please let us know.

Quote
> While it is easy to adhere to the "standards" adopted
> by Borland in the Delphi VCL when building applications,
> these things do not appear to be standard (in the way that
> I know pascal anyhow).

Most of the components in the Delphi VCL is specific to Windows; in Delphi
2 & 3, specific to Windows 95 and Windows NT.  Borland does not offer
Delphi (or any other version of Object Pascal) for any other operating
system.  I personally would like to see Delphi on Linux.

Quote

> Can someone clarify these points? Maybe I've not programmed
> in pascal for so long that new standards have developed.

The extensions to the Pascal language appear proprietary to Borland--the
extensions support Microsoft's Windows environment.  Despite their
proprietary nature, one big advantage is that the VCL component library is
written completely in Delphi, and the source code for the complete VCL
library comes with the developer's or higher version of Delphi.

Gene

Re:Delphi not "standard pascal"


You answered your own question when you said "What other
pascal compilers are there?"  Delphi 1, 2, and 3 are in effect
Turbo Pascal version 8, 9, and 10, as reflected in the conditionals

{$IFDEF VER100}
  ShowMessage('This is Delphi 3');
{$ENDIF}

Turbo Pascal has been the "standard" for a very long time.  For some
of us, it has been the standard since 1983.  If you
want to get up to speed on the language definitions, then look at the
Delphi help / contents / Object Pascal Guide.

Delphi has been able to accomplish what it can partially because
Borland has had the flexibility to define the standard and incorporate
new keywords as necessary.  Clearly they have done an admirable job
of being trustworthy with such a responsibility, as is evidenced by the
power of Delphi.

If portability is the question, then you will give up something that has
native closeness with the system.  But that is certainly possible with
C++, Java, or several Database systems.  It's an engineering tradeoff
where Delphi developers or their bosses have made some decisions
based on productivity, speed, or other Delphi benefits.

Delphi is not in the portability business in the strict sense.

If portability is a requirement, then you will be best suited to have a
PAS
file as a unit which contains a library of plain vanilla functions which
have a high portability with other systems.  Then you would need to write
the user interface and other pieces to glue the app together.

Phil

Mike Powell <mi...@rt66.com> wrote in article <348DE0FF.2...@rt66.com>...

Quote
> Recently I have had to get involved with pascal again (I've
> been a long time c/c++, java, javascript, perl programmer).
> I've noticed that several of the features supported in Delphi
> (we're using version 2.0 in house) are not standard pascal.
> So writing a Delphi specific app cannot be ported to another
> pascal compiler (i know i know, what other pascal compilers
> are there?).

> For instance, since when has a programmer ever been able to
> assign the return values for a function to some system
> provided variable called "Result"? I've only ever known
> programmers being able to assign the return value for a
> function to the function's name.

> Also, when dealing with classes (I thought classes were
> objects? back in Borland Turbo "standard" Pascal days)
> it is necessary to assign the value of a constructor
> call to the variable being constructed? (e.g.
> MyInstance := MyClass.Create;).

> While it is easy to adhere to the "standards" adopted
> by Borland in the Delphi VCL when building applications,
> these things do not appear to be standard (in the way that
> I know pascal anyhow).

> Can someone clarify these points? Maybe I've not programmed
> in pascal for so long that new standards have developed.

Re:Delphi not "standard pascal"


Delphi is not meant to be standard pascal, although it will compile
standard pascal. It is a windows development environment only.

Mike Powell <mi...@rt66.com> wrote in article <348DE0FF.2...@rt66.com>...

Quote
> Recently I have had to get involved with pascal again (I've
> been a long time c/c++, java, javascript, perl programmer).
> I've noticed that several of the features supported in Delphi
> (we're using version 2.0 in house) are not standard pascal.
> So writing a Delphi specific app cannot be ported to another
> pascal compiler (i know i know, what other pascal compilers
> are there?).

> For instance, since when has a programmer ever been able to
> assign the return values for a function to some system
> provided variable called "Result"? I've only ever known
> programmers being able to assign the return value for a
> function to the function's name.

> Also, when dealing with classes (I thought classes were
> objects? back in Borland Turbo "standard" Pascal days)
> it is necessary to assign the value of a constructor
> call to the variable being constructed? (e.g.
> MyInstance := MyClass.Create;).

> While it is easy to adhere to the "standards" adopted
> by Borland in the Delphi VCL when building applications,
> these things do not appear to be standard (in the way that
> I know pascal anyhow).

> Can someone clarify these points? Maybe I've not programmed
> in pascal for so long that new standards have developed.

Re:Delphi not "standard pascal"


Someone correct me if I'm wrong, but afaik Object Pascal is an
extension of Pascal designed for the Mac and the MacApp class library
(I read about it in some old Byte magazine). Borland adopted many of
the ideas of the original Object Pascal and enhanced it a bit, to be
able to use it in Win32.

So Object Pascal is really not standard, although it can do almost
anything the ISO standard can.

Rudy Velthuis (rvelth...@cww.de)

Re:Delphi not "standard pascal"


On 10 Dec 97 10:05:44 GMT, "Craig van Nieuwkerk"

Quote
<crai...@melbpc.org.au> wrote:
>Delphi is not meant to be standard pascal, although it will compile
>standard pascal. It is a windows development environment only.

No, Delphi will not compile all standard Pascal.  There are a number
of unsupported aspects.  As far as I know, there's nothing newly
dropped since Turbo Pascal.  The things that were missing there were
mainly to do with I/O:  standard Pascal has a very strange I/O model,
and TP implemented one that was a closer match to the standard one.

Duncan Murdoch

Re:Delphi not "standard pascal"


Quote
Tony Bryer wrote:

> In article <348DE0FF.2...@rt66.com>, Mike Powell wrote:
> > For instance, since when has a programmer ever been able to
> > assign the return values for a function to some system
> > provided variable called "Result"? I've only ever known
> > programmers being able to assign the return value for a
> > function to the function's name.

> This one got suggested on the Borland CompuServe forum several years
> back and they obviously liked it. The logic is that as the routine has
> to make space on the stack to pass back the result you might as well
> use it. More often than not you would have to create a variable to hold
> what was going to be the result whilst you worked on it, and then
> assign this to the function on the last line; no real problem with a
> numeric but if it's a 256 char string it saves a lot of pushing,
> popping and copying. I like it.

Plus the added (admittedly minor) benefit of not having to change the
left side of the assignment whenever you change a function name...

Re:Delphi not "standard pascal"


Quote
Keith G. Murphy wrote:

> Tony Bryer wrote:

> > In article <348DE0FF.2...@rt66.com>, Mike Powell wrote:
> > > For instance, since when has a programmer ever been able to
> > > assign the return values for a function to some system
> > > provided variable called "Result"? I've only ever known
> > > programmers being able to assign the return value for a
> > > function to the function's name.

> > This one got suggested on the Borland CompuServe forum several years
> > back and they obviously liked it. The logic is that as the routine has
> > to make space on the stack to pass back the result you might as well
> > use it. More often than not you would have to create a variable to hold
> > what was going to be the result whilst you worked on it, and then
> > assign this to the function on the last line; no real problem with a
> > numeric but if it's a 256 char string it saves a lot of pushing,
> > popping and copying. I like it.

> Plus the added (admittedly minor) benefit of not having to change the
> left side of the assignment whenever you change a function name...

Also, without Result, you can run into problems of circularly
referencing the function name as a function pointer. In certain
situations the compiler can get confused. I think this simply *has* to
exist for functions to be able to return function pointers.

Dave

Re:Delphi not "standard pascal"


In article <348EC56E.C9678...@mindspring.com>
           keith...@mindspring.com "Keith G. Murphy" writes:

Quote
> Tony Bryer wrote:

> > In article <348DE0FF.2...@rt66.com>, Mike Powell wrote:
> > > For instance, since when has a programmer ever been able to
> > > assign the return values for a function to some system
> > > provided variable called "Result"? I've only ever known
> > > programmers being able to assign the return value for a
> > > function to the function's name.

> > This one got suggested on the Borland CompuServe forum several years
> > back and they obviously liked it. The logic is that as the routine has
> > to make space on the stack to pass back the result you might as well
> > use it. More often than not you would have to create a variable to hold
> > what was going to be the result whilst you worked on it, and then
> > assign this to the function on the last line; no real problem with a
> > numeric but if it's a 256 char string it saves a lot of pushing,
> > popping and copying. I like it.

> Plus the added (admittedly minor) benefit of not having to change the
> left side of the assignment whenever you change a function name...

Plus the added benefit of being able to use it on the right hand side
of an equation without causing recursion.

Regards,

Mike Watson

--
Mayes uk

Re:Delphi not "standard pascal"


On Tue, 09 Dec 1997 17:23:27 -0700, Mike Powell <mi...@rt66.com>
wrote:

Quote
>Recently I have had to get involved with pascal again (I've
>been a long time c/c++, java, javascript, perl programmer).
>I've noticed that several of the features supported in Delphi
>(we're using version 2.0 in house) are not standard pascal.
>So writing a Delphi specific app cannot be ported to another
>pascal compiler (i know i know, what other pascal compilers
>are there?).

>For instance, since when has a programmer ever been able to
>assign the return values for a function to some system
>provided variable called "Result"? I've only ever known
>programmers being able to assign the return value for a
>function to the function's name.

>Also, when dealing with classes (I thought classes were
>objects? back in Borland Turbo "standard" Pascal days)
>it is necessary to assign the value of a constructor
>call to the variable being constructed? (e.g.
>MyInstance := MyClass.Create;).

>While it is easy to adhere to the "standards" adopted
>by Borland in the Delphi VCL when building applications,
>these things do not appear to be standard (in the way that
>I know pascal anyhow).

>Can someone clarify these points? Maybe I've not programmed
>in pascal for so long that new standards have developed.

Sorry,

but what is Standard Pascal -) ? The only standard I know is Turbo
Pascal -) !!!

To be serious, even Borland/Turbo Pascal has never been Standard
Pascal-compatible, not even in its pre-OO-era.

With all the stuff from OWL (ancent Windows-TP-Library) or VCL you
shouldn't even think of porting this code to a
Standard-Pascal-compiler.

However there are compiler for OS/2 (hear, hear) which are
Delphi-compatible (Virtual Pascal, Sibyl, derived from Speed-Pascal
/2).

The guys who have made the Sybil-compiler want to port it to Windows
and other platforms like Unix. I'll be very curious to see such a
version.

Ciao,

Rudi

Re:Delphi not "standard pascal"


Quote
Dave Shapiro <da...@hermes.csd.net> wrote:
>Keith G. Murphy wrote:

>> Tony Bryer wrote:

>> > In article <348DE0FF.2...@rt66.com>, Mike Powell wrote:
>> > > For instance, since when has a programmer ever been able to
>> > > assign the return values for a function to some system
>> > > provided variable called "Result"? I've only ever known
>> > > programmers being able to assign the return value for a
>> > > function to the function's name.

>> > This one got suggested on the Borland CompuServe forum several years
>> > back and they obviously liked it. The logic is that as the routine has
>> > to make space on the stack to pass back the result you might as well
>> > use it. More often than not you would have to create a variable to hold
>> > what was going to be the result whilst you worked on it, and then
>> > assign this to the function on the last line; no real problem with a
>> > numeric but if it's a 256 char string it saves a lot of pushing,
>> > popping and copying. I like it.

>> Plus the added (admittedly minor) benefit of not having to change the
>> left side of the assignment whenever you change a function name...

>Also, without Result, you can run into problems of circularly
>referencing the function name as a function pointer. In certain
>situations the compiler can get confused. I think this simply *has* to
>exist for functions to be able to return function pointers.

>Dave

I can see your logic here... but Modula-2 adopted a slightly different
approach which also gets round all these problems.

In this, functions have no magic variables, and one has to use an
explicit RETURN statement: eg

{note the sligtly different syntax from pascal}

procedure myfunc:integer;

begin
{ bah
 foo
 bar }
RETURN MyResult;
end;

The typing problem is got round as follows:

var
   a:integer;
   b:pointer;

begin
a:=myfunc(); {a now = result of call}
b:=myfunc; {b = pointer to code of function}
end;

Martin Harvey.
***********************************************
Martin Harvey
Pembroke College, Cambridge University.
Uni email: mc...@hermes.cam.ac.uk
Home email: mc...@harvey27.demon.co.uk
Uni web pages: http://www-stu.pem.cam.ac.uk/~mch24/
***********************************************

Re:Delphi not "standard pascal"


Quote
Martin Harvey wrote:
> I can see your logic here... but Modula-2 adopted a slightly different
> approach which also gets round all these problems.

> In this, functions have no magic variables, and one has to use an
> explicit RETURN statement: eg

[snip]

Interesting comparison. If I'm not mistaken, Modula-2 was created by the
same guy that created Pascal. I'm surprised that he opted for such
C-like syntax in his newer language.

I'm not a fan of the return statement because it invites programmers to
break early from the function. It's not a hard-and-fast rule, but I
prefer to see code go to the very end of the function. I think it's
easier to follow. Many times, use of the Result parameter sways me to
stay in the function, a la

function MyFunc: Boolean;
begin
  Result := SomeCondition;
  if Result then DoSomeStuff;
end;

With the return directive, I would be tempted to write

(* Excuse brief lapse to C. I don't know Modula-2. *)

char my_func() {
  if (some_condition)
    return FALSE;
  else {
    do_some_stuff;
    return TRUE;
  }

Quote
}

(*
  By the way, doesn't Pascal look about a zillion times better than C?
*)

Now you have the function breaking early, which can get tricky to
maintain, I think.

Quote
> The typing problem is got round as follows:

> var
>    a:integer;
>    b:pointer;

> begin
> a:=myfunc(); {a now = result of call}
> b:=myfunc; {b = pointer to code of function}
> end;

Again, I'm surprised at the C-like syntax. Using parentheses to
distinguish between function pointers and function invocations always
seemed too easy to{*word*222}up (granted the compiler will check this
situation and bomb before even linking, but it's just not aesthetically
pleasing).

But that's a nice comparison. And this thread is so refreshing ... I was
getting sick of the "How do I make Widget X transparent?" questions.

Cheers,

Dave

Re:Delphi not "standard pascal"


Quote
Dave Shapiro <da...@hermes.csd.net> wrote:
> Martin Harvey wrote:

> > I can see your logic here... but Modula-2 adopted a slightly
> > different approach which also gets round all these problems.

> > In this, functions have no magic variables, and one has to use an
> > explicit RETURN statement: eg

> [snip]

> Interesting comparison. If I'm not mistaken, Modula-2 was created by
> the same guy that created Pascal. I'm surprised that he opted for
> such C-like syntax in his newer language.

Yes. Herr Wirth wrote both of them.

There are several things he got right in M2 that he got wrong in
pascal, and vice versa

eg:

there's much less use of blocks in M2.

in pascal you can have:

if <cond> then <statement>

or

if <cond> then begin <statements> end;

in M2, all you have is if <cond> then <statements> end;

this makes it *so* much easier to sort out nested loops and such
like, and it means you don't have to worry about forgetting begins
and ends.

the thing that I think M2 is awful with is that it's case sensitive!
Not only that, but all the BEGIN's and END's and PROCEDURE's ae all
in capitals... it's such a pain, and you spend half your time eith
holding down shift, or hitting caps lock!

Quote
> I'm not a fan of the return statement because it invites programmers
> to break early from the function. It's not a hard-and-fast rule, but
> I prefer to see code go to the very end of the function. I think
> it's easier to follow. Many times, use of the Result parameter sways
> me to stay in the function, a la

> function MyFunc: Boolean;
> begin
>   Result := SomeCondition;
>   if Result then DoSomeStuff;
> end;

hmm... I see what you mean.

Quote
> With the return directive, I would be tempted to write

> (* Excuse brief lapse to C. I don't know Modula-2. *)

> char my_func() {
>   if (some_condition)
>     return FALSE;
>   else {
>     do_some_stuff;
>     return TRUE;
>   }
> }

possibly. Having said that.. I have had bugs in pascal occur due to
the fact that you tend to stay in the function. Quite often, I prefer
to bomb out real quick for reasons of efficiency.... it's a bit of a
two edged sword.

Quote
> (*
>   By the way, doesn't Pascal look about a zillion times better than
>   C?
> *)

Yeah... it's so much easier to read. What the designers of C forgot
is that most people spend more time reading novels or text than they
do reading equations, and non-alphabetic characters take longer to be
interpreted. You can read a=(b mod c)div d , quicker than a=(b%c)/d,
simply because most people's brains are more accustomed to reading
letters rather than percent signs.

Quote
> Now you have the function breaking early, which can get tricky to
> maintain, I think.

It can be tricky... but it's all a question of responsibility. Most M2
programmers I know are real sticklers for good code style, and they
tend to make it abundantly clear what they're doing.

Quote
> > The typing problem is got round as follows:

> > var
> >    a:integer;
> >    b:pointer;

> > begin
> > a:=myfunc(); {a now = result of call}
> > b:=myfunc; {b = pointer to code of function}
> > end;
> Again, I'm surprised at the C-like syntax. Using parentheses to
> distinguish between function pointers and function invocations
> always seemed too easy to{*word*222}up (granted the compiler will check
> this situation and bomb before even linking, but it's just not
> aesthetically pleasing).

well... hmm... yeah. Okay. When I started programming in Delphi,
having used modula-2, this bothered me... what if I did this in
Delphi?

var
    a:integer;
    b:pointer;

begin
a:=myfunc;
b:=myfunc;
end;

I was worried that the compiler would "get smart" on me, and
interpret those two statements like the ones above in M2, without
telling me.

When I learned about event types, and the fact that it's normally best

to keep callbacks to procedures in objects, my fears were allayed,
and the event concept in delphi is very neat & smart.

Related spiel on events:

I'm currently writing a whole load of async comms stuff in Delphi.

Traditional C programmers seem to do this by forking & blocking
zillions of threads, and giving each thread it's own local data.

In Delphi, you can keep everything single threaded, have state in
objects, and respond to the winsock msgs via either msg procedures,
or thru a shareware / freeware / whatever winsock component (I use
DWinsock). and it's *so* neat & easy with all these events...

I'm implementing all of the protocol stack above TCP, and it's
great.... each layer has some procedures to call the layer below, and
some events to signal to the layer above.... none of this hacky C
stuff.

Having said that, TCP stacks have to be multithreaded, since they deal

with lots of apps, and you don't want one app to block your TCP
stack for everyone else,
but if you're doing comms stuff for an application, where the
app probably has only one thread, then
Delphi is the neatest language for it I know of.

Quote
> But that's a nice comparison. And this thread is so refreshing ... I
> was getting sick of the "How do I make Widget X transparent?"
> questions.

Tell me about it... These are so many really poor programmers out
there who just can't be bothered to:

 1. RTFM
 2. Study Standard texts. (eg. Uni Textbooks explaining principles).
 3. Read RFC's
 4. Write TestApps
 5. Design requirements specs, test plans, implementation plans &
approaches, etc etc....
 6. Prototype
 7. Code carefully, using plenty of comments.
 8. Test thoroughly according to a testing plan.

Amusing Digression:

I was on IRC (light relaxation) today... and some F***er dumped a
whole load of C code on me and asked me to debug it. This C code was
the s***tiest stuff I have ever seen: take a look at this for
APALLING style:

<{*word*99}PY PIECE OF CODE>

void Get_Texture_X(short sx1, short sx2)
{
  long BaseX=Vx1;
  long BaseY=Vz1;
  long Vx=Vx2;
  long Vy=Vz2;

  long Sx=Vx-BaseX;
  long Sy=Vy-BaseY;

  long LL=WallInfoArray[CurentWall.Num].WallSize;

  long R=((BaseY*-Sy)-(BaseX*Sx));
  long S=((BaseY* Sx)-(BaseX*Sy));  

  long BtoBP=((long)R*(long)LL)>>16;
  long Pdist=((long)S*(long)LL)>>16;

  short A=SegmentAngle;

  short x;
  for(x=sx1;x-sx2;x++){
    if(x<1 || x>320)
      continue;

    short RayA=XtoAng[x];

    short TanIndex=A-RayA-ANGLE_90;

    long TanA=tangent(TanIndex);

    long T=(TanA*Pdist)>>16;

    long Tdist=T+BtoBP;

    TexX[x]=Tdist&63;
  }

</{*word*99}PY PIECE OF CODE>

It amazes me that he has a loop where the calculation is done by
means of repeated initialised variable declarations! Have you ever
seen anyone do anything as neanderthal as that???

In addition, there's not one comment to be seen for miles around...
so I hadn't a clue WTF it did.... needless to say, I couldn't really
help.

Martin H.

***********************************************
Martin Harvey
Pembroke College, Cambridge University.
Uni email: mc...@hermes.cam.ac.uk
Home email: mc...@harvey27.demon.co.uk
Uni web pages: http://www-stu.pem.cam.ac.uk/~mch24/
***********************************************

Re:Delphi not "standard pascal"


In article <881776451...@d-m-g.demon.co.uk>, Ma...@d-m-g.demon.co.uk (Mayes uk)
writes:

Quote

Plus the added benefit of being able to use it on the right hand side
of an

Quote
>equation without causing recursion.

And it doesn't preclude using the Pascal standard; simply extends it.

Timothy Dixon
dixon...@aol.com
...insert appropriate apologies for using AOL...

Go to page: [1] [2]

Other Threads