[fpc-pascal] Property with no default value

Michalis Kamburelis michalis at camelot.homedns.org
Mon Apr 18 08:53:43 CEST 2005


While converting some Delphi project to Lazarus I noticed that in FPC 
RTTI there is no way to mark a property as having *no* default value. 
This particular Delphi project depends on it (it relies on the fact that 
when saving some object to the stream, some of the properties will 
*always* be saved in the stream (this way it knows that "Set" methods of 
these properties will *always* be called when this object will be read 
from the stream)).

Looking at FPC typinfo unit, and implementation of TWriter class, and 
reaction on 'nodefault' directive in compiler/pdecvar.pas, there is no 
equivalent possibility in FPC. Every property has "implicit" default of 
false / 0 / [] / #0 etc. This means that I can never guarantee that when 
TWriter writes an object with e.g. some boolean property, it will 
*always* write that boolean property value, regardless of it's value 
(whether it's true or false).

The question is: did FPC decided to not implement this ? Or is it just 
not done yet ? In case it's planned to do this in FPC in a 
Delphi-compatible way, below is 1-paragraph description how it's done in 
Delphi (I don't describe here Delphi's implementation, only visible 
interface, so I guess that FPC devels may read this without any legal 
concerns :)

Delphi uses special value for TPropInfo.Default field: $80000000. It's 
used only when TPropInfo.Kind is one of tkInteger, tkChar, 
tkEnumeration, tkSet (in case of FPC this should also include tkBool). 
Then when TPropInfo.Default of this property is $80000000, the TWriter 
will always write this property value to the stream. The funny 
consequence is that an integer property with a "default $80000000" will 
always be saved to a stream, even if it doesn't have to be. So this is 
not very elegant solution from Borland (some field in TPropInfo like 
IsDefault would be better), but it's probably too late to change such 
things now, even for Borland, not to mention FPC if it tries to keep 
typinfo unit absolutely compatible.


More information about the fpc-pascal mailing list