On the "by design" => read bottom part first. Might save some arguments on the middle part.
If you take my statements out of the context in which I gave them, then yes the remaining partial statement will be wrong.
Please re-read my post, and make sure to apply the entire context that I stated.
And you seem to not have read my post, because like my last 3 post are soly about that you claim that this is some limitation of inheritance in objects.
Really? Just my previous response:
- Yes old objects have polymorphism
- But its usability is limited as to where/when it can be used, if only stack memory should be used
- the stack limitation (and consequences) are an arbitrary condition.
(This last point was not previously spelled out / never mind the limit was stated as requirement)
The limit was NOT created by me, but taken from previous posts.
It clearly states it is
not "some limitation of inheritance in objects" (as you claim I said).
I said "if only stack memory should be used"It is a limitation that stems from the combination of "object" + "stack only".
And yes, I read your point that then it would apply to classes too, if they actually could be limited to stack only.
But that is not the point.
The stack only limit was brought up in some other post, because it meant that no (absolutely no) effort would have to be made to release the memory. (not even some interface, not even managed operators).
Stack memory is freed when the procedure is left.
Back to classes => The "no effort to free memory" effect can not be reached with classes (interfaces and managed operators are an effort). Hence the desired effect can not be reached with classes.
Objects can (
by choice) live on stack only.
But if that choice is made, then (
and only then) the limits I stated do apply.
Since that choice was made, it does not matter in any way what ever you can do if you use heap (be that: objects + heap or classes). Really does not matter.
All I ever said was, that if you make the "stack only" choice, then certain limits apply.
I don't say that this limitation does not exist, my complete argument revolves around that this has literally nothing to do with objects.
Classes have the exact same problem if you allocate them on the stack.
But classes do not go on the stack. At least not by design. Not in FPC.
If classes were designed to allow you to use them "stack only" then classes would have the same issue. But
classes are not designed that way.
On the other hand: Objects are designed to give you the
choice to use them on the stack.
Yes of course there design allows other usages too. It allows a choice. And for reasons given, the particular "stack only" usage was chosen.
You did now multiple times claim that this is inherently a limiation of objects. Let me go through all of your claims:
But new style classes make it possible to keep the memory available in the given case.
Old style objects do not allow for that.
This statement clearly implies that objects have a limitation that classes don't. But if you restrict classes to the stack, this is simply not true
Only if you missed that it was previously mentioned that it was about the choice to have objects on the stack.
But what im really curious at, is , what are then "object" classes like, are they not supposed to be C++ art-classes, where they can live on the stack and still have polymophism, inheritance etc... available?
There may have been more references, I did not search to exhaustion.
And just to be clear. I did not say that objects did not have polymorphism in that case. I said that in that case certain use cases would not work. (I.e. using as function result, where a child class is returned that needs extra memory). It is about the combination.
This is a complete farce. You say that objects are limited by design while classes don't impose a limit, while acknowledging that the limit is arbitrary set by you and only applied to objects. If we apply the same premise for classes, they are as limited as objects
Because by design, it cannot be applied to classes.
If it could ... well yes... but it cannot.
... skipping some repetition of the same point.
So you claimed 3 times clearly that there is some inherent limitation of the design of objects, in two of which you clearly mention classes as an alternative that do not have this limitation. The only thing I am claiming, the whole time, is that this limitation has absolutely nothing to do with the design of objects, as it is also present in classes if you compare them under the same set of limitations.
Yes and No, depending on the exact interpretation of your above statement.
- Objects - by design - give you the choice between heap and stack (and mixing those)
- Classes - by design - do not give you that choice (if they did, it where different, but they do not).
If you take that choice (e.g. for the reasons given earlier), then objects will encounter problems, when and if (and only when and if) used as described.
Classes would, if that choice was available for them. But it is not. Therefore - by that design - you can not make classes suffer from the issue.
You are comparing two different things here, objects which are placed on the stack, vs classes placed on the heap. This has nothing to do with the advantages and disadvantages of classes vs objects, but all with the advantages and disadvantages of heap vs stack.
Yes it as heap vs stack
No, I am not making that comparison => Well I did not start it. I only talked about objects, because the entire idea was to find something that worked on the stack only. Classes do not do that. So I did not even bother to bring classes in.
After you forced classes into the discussion of a "stack only" issue (a discussion where classes have no place to be), I replied that classes do not have that problem.
That reply of mine can indeed be misleading (sorry about that).
- Classes do not have the problem, because classes can not be used in that case at all.
To use "cars".
Had we been talking about problem boats may have on the open ocean (e.g. needing compensation for drift when navigating), I may have said (when prompted) that cars do not have those problems. I would have meant cars can not be used on the open ocean, therefore they also are not affected by drift occurring on the open ocean. (But sure, if you had a floating car.....)
The argument you are actually bringing forth is about the advantages and disadvantages of the different lifetime and managment of different memory allocation methods. And this is a perfectly fine argument to have, but you pretend like the design of objects has anything to do with it, while objects are literally designed to make use of both, the heap and the stack.
It is not about how polymorphism is designed in either of them.
It is about that only one of them can by design be used for "stack only".
See section above this quote.
I never was part of that discussion (that they should be on the stack), I just claimed that polymorphism can be fully used if the object lives on the stack. I did so with this example:
As you can see, polymorphism is used by calling an virtual overriden method from a base object pointer pointing to the child object located on the stack.
In the usecase of your example indeed it works.
Question here is "can be fully used", did you mean:
- Can sometimes be fully used
- Can always be fully used
?
I assumed you meant the latter. (Sorry if I misunderstood)
- If you meant the former, then the discussion is void, as the former would actually mean that "stack only" implies limitations.
- If you meant the latter, then well I asked you for an example of the usecase I provided. (And that example is still outstanding)
There is no limitations objects have when placed on the stack that is inherent to the design of objects.
Ok, going back I did use "the way objects are designed. Under the premise, that no heap is to be used."
And I may have refereed to the design of objects without explicitly stating the 2nd part, assuming it was known already.
I did so because "no heap" would most usually be done by declaring a local variable to hold the data.
In this case, under the given premise, memory allocation is not done by the user. It is part of the overall experience of using on object on the stack.
I therefore attributed the memory allocation (when not done explicitly by the user) to be part of the object design. I.e. that is to read:
By design an object can automatically take space on the stack frame, if declared as local (none pointer) variable.
By design an object allows other types of mem allocation, if the user explicitly allocates the memory.
At first, one might thing that is not something bound to objects, as it applies to all datatypes. But that is not true. Ansistring and dyn array do not offer storage on the stack.