New Compiler Option

BackupUser · Post by **BackupUser** » Fri Dec 27, 2002 2:50 pm

Restored from previous forum. Originally posted by tranquil.

"Force DefType" Enable/ Disable

Which forces the user to declare EVERY(!!) Variable at the beginning of the code and which obtain the automatically allocation of variables if you wrote eg.: hWdn instead if hWnd

Hope you know what I mean. Now the Compiler should bring an errormessage during compilation "Variable hWdn not defined"

Would be very usefull for great sources and for stable coding.

Mike

Tranquilizer/ Secretly!
http://www.secretly.de
Registred PureBasic User
System: Windows 2000 Server, 512 MB Ram, GeForce4200 TI 128 MB DDR, Hercules Theater 6.1 DTS Sound
System 2: Mobile Pentium 4 2.4GHz 512 MB DDR GeForce4 420-32, Windows XP Home

BackupUser · Post by **BackupUser** » Fri Dec 27, 2002 11:40 pm

Restored from previous forum. Originally posted by pbdep.

Originally posted by tranquil

"Force DefType" Enable/ Disable

Which forces the user to declare EVERY(!!) Variable at the beginning of the code and which obtain the automatically allocation of variables if you wrote eg.: hWdn instead if hWnd

Hope you know what I mean. Now the Compiler should bring an errormessage during compilation "Variable hWdn not defined"

Would be very usefull for great sources and for stable coding.

Mike

Tranquilizer/ Secretly!
http://www.secretly.de
Registred PureBasic User
System: Windows 2000 Server, 512 MB Ram, GeForce4200 TI 128 MB DDR, Hercules Theater 6.1 DTS Sound
System 2: Mobile Pentium 4 2.4GHz 512 MB DDR GeForce4 420-32, Windows XP Home

Hi Tranquil,

I agree, the pbcompiler could be more strict.
Indeed flavors like: Strict/Mild and forced will do wonders on the
code.

Also im missing warnings from the compiler.
Wrong delcaired memory blocks or peeksizes
could bound out of range, but the functions catch them savely.
Still a warning is wishfull.

Regards,
Norman.

BackupUser · Post by **BackupUser** » Sat Dec 28, 2002 1:12 am

Restored from previous forum. Originally posted by MrVainSCL.

I agree with Mike and Norman!

PIII450, 256MB Ram, 80GB HD + 6,4 GB, RivaTNT, DirectX8.1, SB AWE64, Win2000 + all Updates...

greetz
MrVainSCL! aka Thorsten

BackupUser · Post by **BackupUser** » Sat Dec 28, 2002 11:38 am

Restored from previous forum. Originally posted by fred.

On my TODO list.

Fred - AlphaSND

BackupUser · Post by **BackupUser** » Sat Dec 28, 2002 3:03 pm

Restored from previous forum. Originally posted by tinman.

Originally posted by pbdep
Also im missing warnings from the compiler.
Wrong delcaired memory blocks or peeksizes
could bound out of range, but the functions catch them savely.
Still a warning is wishfull.

How can the compiler know when you specify an address or array index which is out of bounds? The only time you could do this at compile time is if you access a constant offset from the array or memory base, which wouldn't always be very useful

--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + SP1, PB3.40)

BackupUser · Post by **BackupUser** » Sat Dec 28, 2002 3:19 pm

Restored from previous forum. Originally posted by pbdep.

Originally posted by tinman

Originally posted by pbdep
Also im missing warnings from the compiler.
Wrong delcaired memory blocks or peeksizes
could bound out of range, but the functions catch them savely.
Still a warning is wishfull.
How can the compiler know when you specify an address or array index which is out of bounds? The only time you could do this at compile time is if you access a constant offset from the array or memory base, which wouldn't always be very useful

Hi Tinman,

It could check ie ->
*buffer=allocatememory(0,8192,0)
pokes(*buffer,"Emagine this string is long")
PeekS(*buffer,40963)

The Length in PeekS is longer than the allocated Memory.
Okay PeekS is protected by the \0 byte, but when there is
No \0 byte it coninues until it finds one.

The above will perfectly work without problems but the pbcompiler
could give a "Warning - Peek longer than Buffer".

Or perhpas a WriteByte(b) behind the allocated memorybuffer or loc()?

I know that PB protects those from within the function sometimes
but it usefull for bypassing mistakes during programming.

Its not an error the above just for notification, okay then
the question will rise, is it usefull?

Regards,
Norman.

BackupUser · Post by **BackupUser** » Sat Dec 28, 2002 11:06 pm

Restored from previous forum. Originally posted by fred.

Hum, this is almost not possible to do such test, as the *buffer value can be changed etc... before the PokeS() call. I agree than PokeS() is a dangerous function, you have to use it carefully !

Fred - AlphaSND

BackupUser · Post by **BackupUser** » Sun Dec 29, 2002 4:04 pm

Restored from previous forum. Originally posted by tinman.

Originally posted by pbdep
I know that PB protects those from within the function sometimes
but it usefull for bypassing mistakes during programming.

Its not an error the above just for notification, okay then
the question will rise, is it usefull?

Yes, it would be useful, but it would only work under certain circumstances (and would have only limited usefulness). Imagine this code:

*buffer=allocatememory(0,myvar,0)
pokes(*buffer,"Emagine this string is long")
PeekS(*buffer,string_length)

The compiler cannot give a warning here as there is no way for it to know what values myvar and string_length will have (which of course could change during the program).

--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + SP1, PB3.40)