Recent

Author Topic: SAFE mode for FPC  (Read 10734 times)

Handoko

  • Hero Member
  • *****
  • Posts: 5131
  • My goal: build my own game engine using Lazarus
Re: SAFE mode for FPC
« Reply #15 on: January 16, 2017, 12:21:28 pm »
Quote
initializing a variable does not cost too much performance.

Yes, I know. I don't against it, but in this code below (which I wrote many years ago) all the variables even the "Result" aren't initialized at the beginning. They will be assigned with proper values when they're going to be used.

Code: Pascal  [Select][+][-]
  1. function GetATmpFileName(const Name: string): string;
  2. var
  3.   FileNameOnly: string;
  4.   FileExt: string;
  5.   S: string;
  6.   i: SmallInt;
  7. begin
  8.  
  9.   // Using name's path
  10.   if FileExists(Name) then begin
  11.     S := ChangeFileExt(Name, '.bak');
  12.     if not(FileExists(S)) then begin
  13.       Result := S;
  14.       Exit;
  15.       end;
  16.     S := ChangeFileExt(Name, '.tmp');
  17.     if not(FileExists(S)) then begin
  18.       Result := S;
  19.       Exit;
  20.       end;
  21.     FileExt := ExtractFileExt(Name);
  22.     FileNameOnly := StrRemoveRight(Name, Length(FileExt));
  23.     for i := 1 to 999 do begin
  24.       S := StrWithNumber(FileNameOnly, i, 3) + FileExt;
  25.       if not(FileExists(S)) then begin
  26.         Result := S;
  27.         Exit;
  28.         end;
  29.       end;
  30.     end;
  31.  
  32.   // Using system's temporary path
  33.   S := ExtractFileNameOnly(Name);
  34.   Result := SysUtils.GetTempFileName('', ExtractFileNameOnly(S));
  35.  
  36. end;

Quote
I ALWAYS have rangechecks on during debugging. I ALWAYS resolve all related warnings and hints.

Yes, it is a good practice, although I often skip the range check. I fell shame  :-[
But it's okay, I know what I'm doing.

Quote
Quote
stack overflow check
Do we still need it? Maybe. But I remember I used it when programming on 8-bit machine for DOS using Turbo Pascal 5.5. Now we're using 32 even 64 bit, do we now still have stack overflow issue?
Yes, we still need it, because cocky programmers like recursion ;) And multi-threading :)

Oh yes, I almost forget recursion. Thanks for reminding me. If I need recursion I will find the different way to write the code. I simply don't like recursion.

serbod, can you (or other) please make this thread a survey so we can vote for "Do you want safe (or a better debug) mode?"

I see this topic is interesting. I believe a good safe or better debug mode can be a very useful feature. But of course we have to think properly what things needed to put in the list.

Thaddy

  • Hero Member
  • *****
  • Posts: 14213
  • Probably until I exterminate Putin.
Re: SAFE mode for FPC
« Reply #16 on: January 16, 2017, 12:24:10 pm »
Some errors can't be autodetected from sources - array bounds, invalid pointers, access to destroyed objects, wrong typecast, wrong record alignment.. It's shame, that for 15-20 years of language developmant and usage, it still don't have any protection from routines, that can cause random critical runtime errors. Smart pointers for objects by default can solve most casual troubles. In 90'th with limited computing resources, extra runtime checks was burdening, but now it's not a problem even for pocket devices. Difference in performance between debug and release builds is unnoticable.
Well, how about:
- Using Low() and High() and Length() for arrays. If you don't, you are the cause of your problems
- Testing Assigned(), Assert() and nil for pointers will help
- Hard - wrong - type casts can never be made safe. That is a programmer instruction by definition.
- Smart pointers should not be on by default, they are possible though, in trunk.
- Record alignment is a programmers task. If writing to/from a storage medium is required a record should be packed and the programmer should take care of the optimum layout, otherwise it should be CPU/FPU/OS  alignment dependent. Simple.
If you have indeed 15-20 years of experience.... well, use the language features that are already there..

Some runtime checks are possible, but for e.g. a hard cast that is not possible.
« Last Edit: January 16, 2017, 12:28:03 pm by Thaddy »
Specialize a type, not a var.

Handoko

  • Hero Member
  • *****
  • Posts: 5131
  • My goal: build my own game engine using Lazarus
Re: SAFE mode for FPC
« Reply #17 on: January 16, 2017, 12:30:55 pm »
+1 Thaddy

Good suggestions.

serbod

  • Full Member
  • ***
  • Posts: 142
Re: SAFE mode for FPC
« Reply #18 on: January 16, 2017, 01:49:36 pm »
Well, how about:
- Using Low() and High() and Length() for arrays. If you don't, you are the cause of your problems
- Testing Assigned(), Assert() and nil for pointers will help
- Hard - wrong - type casts can never be made safe. That is a programmer instruction by definition.
- Smart pointers should not be on by default, they are possible though, in trunk.
- Record alignment is a programmers task. If writing to/from a storage medium is required a record should be packed and the programmer
It's very bad practice, put all troubles on programmer's shoulders, when it's not necessary.

For example, strings (LongString, AnsiString) have runtime size/position checking, refcounting, type conversion, and some other features out-of-box, and it make Pascal outstanding over many other languages, without performance penalties. Who now use PChar as string in Pascal? Standad library have many functions for PChar, almost all shared libraries and API's use PChar for strings. Why not make PChar as default string type? =)

Smart pointers and refcounting is already implemented for Interface, but not implemented for Object. I don't uderstand, why. Every TObject have refcounted strings and iterfaces table, but can't have refcounting itself. So, Assigned() is just comparsion with nil, not checking, that object was destroyed. FreeAndNil() also can't help, if there another pointers to object.

 

TinyPortal © 2005-2018