View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0034699||FPC||Documentation||public||2018-12-13 10:30||2018-12-14 09:49|
|Reporter||Thaddy de Koning||Assigned To||Michael Van Canneyt|
|Target Version||3.3.1||Fixed in Version||3.3.1|
|Summary||0034699: Documentation for the default constructor TObject.Create is wrong.|
|Description||The documentation states that the default constructor TObject.Create does nothing: https://www.freepascal.org/docs-html/rtl/system/tobject.create.html|
But it does call NewInstance, which is virtual, which in turn calls initinstance which in turn returns the instance through the default constructor to assign it to an instance variable.
You can easily see that in the debugger.
Since NewInstance is virtual the documentation is misleading.
Although NewInstance can be called directly, the default constructor is the preferred way to set up the instance. And so does a little more than nothing....
|Steps To Reproduce||Debug a Tobject.Create...|
|Tags||No tags attached.|
|Fixed in Revision||1526|
||(afaik the memory allocation is considered separate from the constructor. If the memory allocation fails, the constructor is not run)|
See the comment of Marco.
I documented the fact that NewInstance is not considered to be part of the constructor.
Marco's assumption is wrong: the latter part is not correct:
1. the constructor itself is the call that does newinstance -- > initInstance
2. If one of those two fails, the constructor fails *as if* it is not executed.
3. TObject.AfterContruction is another one I noticed if an object is directly created through newinstance.
Ergo: They are not separate in any way. It is the constructor that initiates the other calls and if.. only if.. one of those nested calls to newinstance, subsq initinstance fails the constructor *seems* to do nothing.
4. The constructor does nothing for *user* code, but it sets a whole lot of other necessary initialization. On fail it just does not run any further.
So. Where is are the sources for those statements?
And how do you reason away
around line 323?
Hmm, the debugger does enter that, and as next step enters initinstance. I assume Thaddy means that. The assembler code does indeed call a tobject symbol at objpas.inc:323.
Yet the call is not explicit in the source.
I guess the code is generated (trunk linenrs) psub:443
I searched a bit more and Delphi docs say that "constructor calls newinstance", that seems to agree with this. (Delphi also seems to http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.TObject.NewInstance)
If I have the following code:
type ta= class
var a : TA;
then I get exactly the same behaviour in the empty ta.create constructor. IOW it is not tobject.create that does it unique, but every constuctor that is called with (on x86_64) rsi=1
If ta.create is changed to call inherited, the initinstance is called at the entry of ta.create, and not when it descends into tobject.create.
Conclusion all constructors have this behaviour that is triggered by a parameter. Delphi's documentation is closer to the truth, anyway Thaddy's assertion that is solely tobject.create that does it is wrong.
||I reworded the text in TObject.Create.|
|2018-12-13 10:30||Thaddy de Koning||New Issue|
|2018-12-13 10:30||Thaddy de Koning||Status||new => assigned|
|2018-12-13 10:30||Thaddy de Koning||Assigned To||=> Michael Van Canneyt|
|2018-12-13 10:34||Marco van de Voort||Note Added: 0112530|
|2018-12-13 10:39||Michael Van Canneyt||Fixed in Revision||=> 1526|
|2018-12-13 10:39||Michael Van Canneyt||Note Added: 0112531|
|2018-12-13 10:39||Michael Van Canneyt||Status||assigned => resolved|
|2018-12-13 10:39||Michael Van Canneyt||Fixed in Version||=> 3.3.1|
|2018-12-13 10:39||Michael Van Canneyt||Resolution||open => fixed|
|2018-12-13 10:39||Michael Van Canneyt||Target Version||=> 3.3.1|
|2018-12-13 16:05||Thaddy de Koning||Note Added: 0112537|
|2018-12-13 16:05||Thaddy de Koning||Status||resolved => feedback|
|2018-12-13 16:05||Thaddy de Koning||Resolution||fixed => reopened|
|2018-12-13 16:07||Thaddy de Koning||Note Edited: 0112537||View Revisions|
|2018-12-13 16:47||Marco van de Voort||Note Added: 0112544|
|2018-12-13 17:02||Marco van de Voort||Note Added: 0112545|
|2018-12-13 17:04||Marco van de Voort||Note Edited: 0112545||View Revisions|
|2018-12-13 17:12||Marco van de Voort||Note Added: 0112546|
|2018-12-14 09:49||Michael Van Canneyt||Note Added: 0112561|
|2018-12-14 09:49||Michael Van Canneyt||Status||feedback => resolved|
|2018-12-14 09:49||Michael Van Canneyt||Resolution||reopened => fixed|