Testing Compiler

forum.sourcecode (2000-2005) & forum.td.sourcecode (2005-2010)
Jarmo Muukka

Testing Compiler

Post by Jarmo Muukka » 11 Jan 2007, 15:55

 Posted by:  Jarmo Muukka 


I wrote some bad code to test compiler's capabilities. Source code is in
text mode made with CTD 1.1.0.

Loat it and compile. If it gives compiler errors, progress has been done.
Please report here what bugs it detects and what is the version.

When you run the application, it tells what situations it handles or cannot
handle. If you do not see a single Message box with "A bug" title, bugs have
been fixed. Please tell here the version and what has been fixed.

I am sure you can write more functions to test compiler and runtime.


You do not have the required permissions to view the files attached to this post.

Matthias Körner

Re: Testing Compiler

Post by Matthias Körner » 11 Jan 2007, 16:11

 Posted by:  Matthias Körner 

You are New to Gupta!
All of this are very old features. As developer you can use this verry

Here are other You can pass an numeric array as windowhandle into an
function! Filehandle always works fine.

SalStrIsValidNumber(' ') --> TRUE (My Monycase works other....)
And If You work with Arrays of functional classes that also inccludes other
arrays of other functional classes.
Don´t leave the programm....! Or You got only GPF.

Matthias Körner

Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Posts: 3384
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: Testing Compiler

Post by Dave Rabelink » 11 Jan 2007, 19:18

The compiler is not very up to date and needs some revisions indeed.

For most parts, I agree the compiler should detect the issues.
But it would be wrong to change the compiler so it will create compile
errors. Instead it should offer warnings.

There is nothing wrong with casting datatypes for example, but I can
imagine developers want to be aware they return a number instead of a

But I have made this remark earlier in the TD2006 beta forums.
Seems Gupta has made the compiler in that version more strict and will
fail compiler at some cases. It should not fail, but report warnings.

The issue

Code: Select all

If NUMBER_Null  SalDateCurrent(  )
	Call SalMessageBox( 'DATETIME_Null is later than today.', 'A bug', 0 )
	Call SalMessageBox( 'DATETIME_Null is NOT later than today.', 'Works as expected.', 0 )

Jarmo Muukka

Re: Testing Compiler

Post by Jarmo Muukka » 12 Jan 2007, 12:02

 Posted by:  Jarmo Muukka 

Hi Matthias,

Yes, I am new to Gupta. I started using SQLWindows 1.0 in 1990.

As a developer I have got used to its problems, of different versions,
during my career.

I do have arrays of functional classes that has arrays of functional
classes. I have never seen a crash. Can you write a simple test case to
prove it?

I write a lot C++ code in OO way and I like the compiler's capabilities to
detect small mistakes (I use the highest warning level). I would like that
SAL compiler would be as strict as C++ compiler is. It should treat some of
the things as warnings and maybe compiler could include warning levels
(maybe two would be ok: ignore warnings and all warnings).

My motivation is in product improvement.


Jarmo Muukka

Re: Testing Compiler

Post by Jarmo Muukka » 12 Jan 2007, 12:23

 Posted by:  Jarmo Muukka 

Hi Dave,

Yes, waring is better than generating a compiler error on some cases. See my
other post.

The way Boolean datatype works now, there is no need for datatype Boolean.
It's just a Number. A true Boolean datatype could only has two different
values: FALSE or TRUE. If TRUE is 1, then setting any non-zero value to
Boolean, should set variable to 1. Comparing bFoo = TRUE should be reliable.
I never write in this way. I will write If bFoo or If NOT bFoo.

In C++ bool datatype can be only false or true.

As you pointed out there are more bugs in runtime.


Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Posts: 3384
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: Testing Compiler

Post by Dave Rabelink » 13 Jan 2007, 11:12

The TD boolean is indeed internally just a number. It is nice to have
a visually difference between boolean and numbers, but it can lead to
the bugs you have described if you are not aware of this.

Another thing is the performance. Numbers in TD have a very large
internal size, so calculations/loops using booleans actually have the
same performance impact like using math calculations on numbers.

While bContinue

While nValue

is the same !

TD is not known as a very performant environment. Having real booleans
would improve this at some points. But I believe the feature request
for new datatypes (INT, BOOL etc) is shared among many TD developers
for years now.

Jim McNamara

Re: Testing Compiler

Post by Jim McNamara » 17 Jan 2007, 22:07

 Posted by:  Jim McNamara 

Processors have gotten so good that having a real boolean would not make a
measurable difference in performance..

I like having just one number type (2 if you count boolean) to deal with in
an app. Makes life so much simpler.

INT, FLOAT, LONG INT, SMALL INT, NUMBER, DOUBLE... - who gives a rats ass,
they're all numbers. The only question is will it hold the largest
precision value that I require?

Thomas Lauzi

Re: Testing Compiler

Post by Thomas Lauzi » 18 Jan 2007, 12:25

 Posted by:  Thomas Lauzi 

Oh yes, Jim!
I played around a litte with C# and I can say that I´m really dissapointed,
that there are all these number types like in old C (which I could remeber
from the old days).
It´s horrible, always to cast numbers and to take care about this.
In this case TD is lightyears ahead compared to other languages.

Thomas L.

Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Posts: 3384
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: Testing Compiler

Post by Dave Rabelink » 18 Jan 2007, 20:17

My opinion differs here.

It is a question of choice. When TD offers more number types, you can
choose to use them or not. When you need no specific number length and
always want the largest number, use Number.
When you need performance, use INT or something like that.

You are right processors have gotten good, but it is the interpreter
which eats the performance here. The TD runtime environment has to
process all the precision a Number can hold for every number
operation, even when this is not needed. And in the end, an addition
or substraction is done by the processor and data using less bits &
bytes is more performant.

While boolean
While number

will sure be different in performance when the first only holds 1 bit.

An optimised interpreter which manages those types efficient can boost
performance quite a bit. That's why languages like C have them and C
is used to build application who actually need performance.
(and offcourse the result of a build from a C application is not

Tastes differ here, but at least Gupta could make a real boolean
instead of the boolean REAL we now have.

Christof Helm

Re: Testing Compiler

Post by Christof Helm » 19 Jan 2007, 08:00

 Posted by:  Christof Helm 

IMHO, a 4GL like TD is made for preventing us from dealing with such
annoying details.
If we love to care about casting problems we may use a different
programming language.

Return to “td.sourcecode”

Who is online

Users browsing this forum: [Ccbot] and 0 guests