View Issue Details

IDProjectCategoryView StatusLast Update
0034699FPCDocumentationpublic2018-12-14 10:49
ReporterThaddy de KoningAssigned ToMichael Van Canneyt 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformallOSallOS Versionall
Product Version3.3.1Product Build 
Target Version3.3.1Fixed in Version3.3.1 
Summary0034699: Documentation for the default constructor TObject.Create is wrong.
DescriptionThe 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 ReproduceDebug a Tobject.Create...
TagsNo tags attached.
Fixed in Revision1526
FPCOldBugId
FPCTarget
Attached Files

Activities

Marco van de Voort

2018-12-13 11:34

manager   ~0112530

(afaik the memory allocation is considered separate from the constructor. If the memory allocation fails, the constructor is not run)

Michael Van Canneyt

2018-12-13 11:39

administrator   ~0112531

See the comment of Marco.

I documented the fact that NewInstance is not considered to be part of the constructor.

Thaddy de Koning

2018-12-13 17:05

reporter   ~0112537

Last edited: 2018-12-13 17:07

View 2 revisions

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.

Marco van de Voort

2018-12-13 17:47

manager   ~0112544

So. Where is are the sources for those statements?

And how do you reason away

https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/inc/objpas.inc?view=markup

around line 323?

Marco van de Voort

2018-12-13 18:02

manager   ~0112545

Last edited: 2018-12-13 18:04

View 2 revisions

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)

Marco van de Voort

2018-12-13 18:12

manager   ~0112546

If I have the following code:


type ta= class
    constructor create;
   end;

constructor ta.create;
begin
end;

var a : TA;
begin
  a:=ta.create;
end.

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.

Michael Van Canneyt

2018-12-14 10:49

administrator   ~0112561

I reworded the text in TObject.Create.

Issue History

Date Modified Username Field Change
2018-12-13 11:30 Thaddy de Koning New Issue
2018-12-13 11:30 Thaddy de Koning Status new => assigned
2018-12-13 11:30 Thaddy de Koning Assigned To => Michael Van Canneyt
2018-12-13 11:34 Marco van de Voort Note Added: 0112530
2018-12-13 11:39 Michael Van Canneyt Fixed in Revision => 1526
2018-12-13 11:39 Michael Van Canneyt Note Added: 0112531
2018-12-13 11:39 Michael Van Canneyt Status assigned => resolved
2018-12-13 11:39 Michael Van Canneyt Fixed in Version => 3.3.1
2018-12-13 11:39 Michael Van Canneyt Resolution open => fixed
2018-12-13 11:39 Michael Van Canneyt Target Version => 3.3.1
2018-12-13 17:05 Thaddy de Koning Note Added: 0112537
2018-12-13 17:05 Thaddy de Koning Status resolved => feedback
2018-12-13 17:05 Thaddy de Koning Resolution fixed => reopened
2018-12-13 17:07 Thaddy de Koning Note Edited: 0112537 View Revisions
2018-12-13 17:47 Marco van de Voort Note Added: 0112544
2018-12-13 18:02 Marco van de Voort Note Added: 0112545
2018-12-13 18:04 Marco van de Voort Note Edited: 0112545 View Revisions
2018-12-13 18:12 Marco van de Voort Note Added: 0112546
2018-12-14 10:49 Michael Van Canneyt Note Added: 0112561
2018-12-14 10:49 Michael Van Canneyt Status feedback => resolved
2018-12-14 10:49 Michael Van Canneyt Resolution reopened => fixed