Re: abstract sub programs overriding

["Robert I. Eachus" <rieachus@comcast.net>]

Randy Brukardt wrote:

>>I was thinking of cases where Initialize is called implicitly, and the
>>compiler can determine that Object is never referenced before it is
>>overwriten. In that case, of course, the compiler can eliminate an
>>implicit Finalize.  This shouldn't break your code.
>  
> OK, but that only works when the (user-defined) Initialize is in-lined. (I
> doubt compilers are both recognizing user-defined Initialize as special, and
> generating two bodies for it!)

I agree here.  My point was that it may be legal, but it is unlikely 
that any compiler does it.

>>Notice that, in this particular case, the value not finalized would also
>>not have any default components initialized.
> 
> I suppose that's possible, but only if user-defined Initialize is in-lined.
> I don't know if any compilers actually do that.

Again, agree, especially on the last line.

>>I was suggesting to Hyman
>>that he might want to try to find a case where compilers DO finalize a
>>value that does not have default component values assigned. 
> 
> I don't think that can happen. Which is why Ada controlled objects usually
> contain a "Valid" flag or the like.

The Valid flag (or checking if an access value is non-null which is what 
I sometimes do) is not relevant here.  My original point was that 
although the language rules seem to imply that there is a loophole, any 
compiler is going to have to do a lot of work--to be able to do more 
work proving that there are no external effects of the optimizations.

>>As I understand AI-147, it allows some calls to user defined Finalize
>>operations to be eliminated, but not Intialize and Finalize pairs where
>>the Initialize is user defined.  Eliminating a Finalize call on an
>>object that has not been initialized seems legal to me.
> 
> Yes, but there is no such object in a user-defined Initialize call. It is
> default-initialized before it is passed in. If the compiler actually
> in-lined the call, it could eliminate the default-initialization and the
> Finalize call -- except that there is no permission in the standard (as
> amended by AI-147) to do either, and either operation could have detectable
> side-effects. So I wonder if such an optimization is even allowed.

As I was writing this originally, I thought about the curse in Ruddigore 
and "Yesterday upon the stair I met a man who wasn't there. He wasn't 
there again today. I wish that man would go away." -- Hughes Mearns 
(1875-1965)

I don't wonder if the optimization is allowed, I wonder if there are 
inifinitely many uninitialized objects that are also not finalized, or 
if the number is somehow finite.  In any case it seems clear to me that 
an object that doesn't get far enough along the track toward existing as 
to begin default initialization does not need to be finalized.  The 
interesting questions concern partially and fully initialized objects.

>>This can only happen AFAIK, in these cases where the object has an
>>explicit  initial value, and the Finalize call occurs before the
>>assignment of the initial value. 
> 
> If the object has an explicit initial value, Initialize is never called. And
> if that initial value is an aggregate, it has to be built directly in the
> object (and none of Finalize, Adjust, or Initialize are called). That's not
> the case we're talking about.

Whoops, that one sent me back to the reference manual.  First, an 
aggregate of a controlled type always results in a call to some 
Initialize, except perhaps inside of Ada.Finalization where you can use 
a regular aggregate instead of an extension aggregate.  An interesting 
bounding case that has come up in this discussion, but AFAIK is not of 
interest here.  In the second sentence, I think you are thinking of RM 
7.6(17.1) which was added in the 2000 revision.  But that requirement 
does not apply to aggregates in assignment statements, and you are right 
that is not the case we are talking about here.

This is the case where an exception occurs during the evaluation of the 
aggregate, in particular in the call to Initialize there.  And this is 
where we get into whether partially intialized objects are finalized. 
As I read the rules and understand them, the answer is that to some 
extent partially initialized objects may have components that have been 
fully initialized, these must be finalized. We are back to that other 
comment you made.

What you as an author want is that any object that is correctly 
initialized will be finalized, that any object which is not initialized 
will not be finalized, and there are no objects in the middle.  This is 
why I like to use an extension aggregate as the first line of an 
Initialize procedure.  If there is an exception raised, Adjust doesn't 
get called, and I don't have to worry about cascading exceptions.  Once 
the aggregate assignment succeeds I have an object which is not 
abnormal, in either the Ada technical sense or the practical sense.


>>However,
>>I can see that it could occur if the object is assigned a value by an
>>aggregate assignment inside a user-defined initialize.
>  
> It *has to* occur in that case, which was Hyman's point. I don't think it
> can be optimized out.

And I think it can be--but it won't be.  This is one of those complex 
areas where the permissions in the RM envision an implementation 
strategy, and no one knows if there is any other way for a compiler to 
comply with the standard.  But there are things which are not required 
by the language, but even trying to imagine an implementation trying to 
take advantage of the opportunity to get into trouble is just not going 
to happen.

For example in early days (I think it persisted into Ada82) there were 
legal Ada source strings where the separation into tokens required 
semantic information.  Of course, if an implementation knew that there 
were no single character attributes, there was no real problem.  Then 
the scanner/lexer could assume that 'A' was never an attribute followed 
by an apostrophe, so it was either a character literal or an error.  By 
the time Ada 83 was approved, we had a way to do the scanning of very 
complex lines without trouble, but still no compiler, AFAIK has ever 
defined a single character attribute.

In this case the wording of 7.6(21) would allow some improper 
optimizations except for the phrase "...if it can safely create...", so 
every implementation only does this optimization in a way that is 
semantically equivalent to the canonical approach.  As all this 
discussion shows, there are cases where the rules lead into grey areas, 
but in practice there is no grey.  As I mentioned above, an 
implmentation is allowed to have regular aggregates in Ada.Finalization, 
but aside from that, all values of a controlled type must have been 
initialized.


-- 
                                           Robert I. Eachus

"The only thing necessary for the triumph of evil is for good men to do 
nothing." --Edmund Burke