Writable consts...?

[cdbc]

Hi
I'm wondering, does the array in this record constitute a 'writable const'?:

Code: Pascal  [Select][+][-]

1.   PLogDirsCreated = ^TLogDirsCreated;
2.   TLogDirsCreated = record
3.    const ldcDirs: TStringArray = ('common','models','presenters','views');
4.    var
5.     ldcAbreviation: string;
6.     ldcLogText: string;
7.     ldcProjectname: string;
8.     ldcResult: boolean;
9.     ldcRoot: string;
10.   end;

I mean, in the case of 'ldcDirs', would I later be able to e.g.: extend or truncate the array?!?
Regards Benny

[Zvoni]

I think it is.
OTOH, try and error? :-P

[Thaddy]

{$J+/-}

[cdbc]

Hi
Thaddy is that just in the implementing unit or also in the units using it?!?
Regards Benny

[cdbc]

OTOH, try and error? :-P

Hehehe Zvoni, that's my next move, but it never hurts to ask 
Regards Benny

[Thaddy]

Hi
Thaddy is that just in the implementing unit or also in the units using it?!?
Regards Benny

No, it is the way compiler handles it: in {$J-} state it ends up in a read-only section.
That means it should be global. You can't turn that around without hacks.

[440bx]

... is that just in the implementing unit or also in the units using it?!?
Regards Benny

you didn't ask me but, the writeability of the const is determined by the setting of the J directive where the const is declared. 

Since the J directive can change multiple times and at any time in a unit or program it is therefore not a unit "thing".  Its state can be "on" at some point, "off", twenty lines later and back "on" ten lines after that.  Turn it on and off to your liking and/or needs.

HTH.

[Thaddy]

No, once it is declared it keeps the state.  Always.
Simply compile with -s and examine...

[cdbc]

Hi
Ok, so if I define it like this:

Code: Pascal  [Select][+][-]

1. unit model.base;
2. {$mode ObjFPC}{$H+}{$J+} /// <--- here?!?
3. {$ModeSwitch advancedrecords}
4. interface
5. uses classes,sysutils,obs_prosu;
6. const
7.   { (p)rovider (r)easons for observer action/reaction }
8.   prStatus = prUser + 1; { carries an optional object in aNotifyClass and usually a pchar in UserData }
9.   prDataStrNeeded = prUser + 2; { carries an 'ItrxSectionFetch' obj in UserData }
10.   prSectionFetched = prUser + 3;     { carries an 'IStrings' object in UserData }
11.   prStaticTextsFetched = prUser + 4; { carries an 'IStrings' object in UserData }
12.   prUnitFetched = prUser + 5;        { carries an 'IStrings' object in UserData }
13. type
14. {$interfaces corba}
15.   { this is the ancester }
16.   IbcCorba = interface['{3563A63E-8C1A-40E1-9574-3E4171BB3ACF}']
17.     function Obj: TObject;
18.   end;
19.   TcsuTransaction = class; // forward
20.   { ImemTransaction is our container vessel for changes }
21.   IcsuTransaction = interface['{AFE2A986-7D3C-46AB-A4BF-2A0BDA1DECDF}']
22.     function get_DataPtr: pointer;
23.     function get_Id: ptrint;
24.     function get_ModReason: word;
25.     function get_Sender: TObject;
26.     function get_StrProp(anIndex: integer): shortstring;
27.     function Obj: TcsuTransaction;
28.     procedure set_DataPtr(aValue: pointer);
29.     procedure set_Id(aValue: ptrint);
30.     procedure set_ModReason(aValue: word);  
31.     procedure set_Sender(aValue: TObject);
32.     procedure set_StrProp(anIndex: integer;aValue: shortstring);
33. //    function AssignFrom(anItem: ImemItem): boolean;
34.     property DataPtr: pointer read get_DataPtr write set_DataPtr;
35.     property ID: ptrint read get_Id write set_Id;
36.     Property ModReason: word read get_ModReason write set_ModReason;
37.     Property Sender: TObject read get_Sender write set_Sender;
38.     property Title: shortstring index 0 read get_StrProp write set_StrProp;
39.   end;
40. {$interfaces com}
41.   { TcsuTransaction is our container vessel for changes }
42.   TcsuTransaction = class(TObject,IcsuTransaction)
43.   protected
44.     fDataPtr: pointer;
45.     fID: ptrint;
46.     fModReason: word;
47.     fSender: TObject;
48.     fTitle: shortstring;
49.     function get_DataPtr: pointer; virtual;
50.     function get_Id: ptrint; virtual;
51.     function get_ModReason: word; virtual;
52.     function get_Sender: TObject; virtual;
53.     function get_StrProp(anIndex: integer): shortstring; virtual;
54.     function Obj: TcsuTransaction; virtual;
55.     procedure set_DataPtr(aValue: pointer); virtual;
56.     procedure set_Id(aValue: ptrint); virtual;
57.     procedure set_ModReason(aValue: word); virtual;
58.     procedure set_Sender(aValue: TObject); virtual;
59.     procedure set_StrProp(anIndex: integer;aValue: shortstring); virtual;
60.   public
61.     constructor Create(aModReason: word); virtual;
62.     destructor Destroy; override;
63. //    function AssignFrom(anItem: ImemItem): boolean;
64.     property DataPtr: pointer read get_DataPtr write set_DataPtr;
65.     property ID: ptrint read get_Id write set_Id;
66.     Property ModReason: word read get_ModReason write set_ModReason;
67.     Property Sender: TObject read get_Sender write set_Sender;
68.     property Title: shortstring index 0 read get_StrProp write set_StrProp;
69.   end; { TcsuTransaction }
70.  
71.   { P/TLogDirsCreated }
72.   PLogDirsCreated = ^TLogDirsCreated;
73.   TLogDirsCreated = record
74.    const ldcDirs: TStringArray = ('common','models','presenters','views');
75.    var
76.     ldcAbreviation: string;
77.     ldcLogText: string;
78.     ldcProjectname: string;
79.     ldcResult: boolean;
80.     ldcRoot: string;
81.   end;
82.  
83. implementation

It will then keep its state?
P.s.: sorry 440bx 
Regards Benny

[Thaddy]

yes, because the compiler keeps the state for you.
If the constant is declared in {$J-} state...

[440bx]

It will then keep its state?
P.s.: sorry 440bx 
Regards Benny

No problem.

As far as keeping its state, there is nothing in what you showed that may or may not keep its state. 

ldcDirs is a _definition_ therefore it has no state to lose or keep, just like TLogDirsCreated is a _definition_ it cannot lose or keep its state.

Once you've declared a variable of type TStringArray and initialized it using ldcDirs then the setting of the J directive at that time will determine if the _variable_ (which is a much different thing than a data type) will or will not have a persistent state.

As you currently have it, ldcDirs is just an array definition the compiler will _copy_ into a variable of type TStringArray when one is declared.  If no variables of type TStringArray that use ldcDirs are defined then the entire definition will be discarded by the compiler (same thing applies to the definition of TLogDirsCreated.)

HTH.

ETA:

Actually, ldcDirs is a declaration not just a definition therefore the setting of the J directive at the time does affect it. 

[Zoran]

It is good practise to declare it within push-pop; it's then isolated, independent of surrounding directives and will not have any side effects on other code:

Code: Pascal  [Select][+][-]

1. {$push}
2. {$J+}
3. const
4.   ldcDirs: TStringArray = ('common','models','presenters','views');
5. {$pop}
6.  

[Thaddy]

Yes, that is good practice, it is also a good thing to exanine the generated assembler code. Then you do not have to ask.

[ASerge]

Code: Pascal  [Select][+][-]

1. unit model.base;
2. {$mode ObjFPC}{$H+}{$J+} /// <--- here?!?
3. ...
4. implementation

It will then keep its state?

No. In order NOT to change, you need {$J-} or {$WRITEABLECONST OFF}

[Thaddy]

ASerge, I already wrote that.
Benny, check the assembler that is generated and you will immediately see the difference.