1. Ticket #937: assigning to integer destroys the object prematurely

Hi

https://openeuphoria.org/ticket/937.wc

This raised a ton of questions for me

include std/io.e  
include std/error.e  
include std/unittest.e  
  
type enum boolean T,F=0 end type  
  
boolean enable_my_close = F  
  
procedure my_close(integer fh)  
    if fh > io:STDERR then  
    	printf(io:STDERR, "Closing file %d\n", {fh})  
    	if not enable_my_close then  
    		crash("premature file closing")  
    	end if  
        close(fh)  
    end if  
end procedure  
  
integer f_debug = open("example.log", "w")  
if f_debug =-1 then  
	f_debug = open("/dev/null", "w")  
  	puts(io:STDERR, "Unable to create log file.")  
else  
    f_debug = delete_routine(f_debug, routine_id("my_close"))  
end if  
  
enable_my_close = T  
  
test_report() 
 

My interpretation of this is :

  • call a routine with an integer as the first paremeter.
  • the way it should work is the integer is passed (in this case f_debug), enacted, and then cleaned up afterwards
  • the way the ticket implies it's working is that the integer is cleaned up straight away.
  • this is beacause the integer has at some point had something called a destructor added to it
  • and when this is present in this instance destroys the integer immediately on calling the routine.

Please correct me.

Is this still relevent?
Has it been fixed?
Why would anyone want to call a routine this way?

new topic     » topic index » view message » categorize

2. Re: Ticket #937: assigning to integer destroys the object prematurely

ChrisB said...

Is this still relevent?
Has it been fixed?

To my knowledge this has been fixed. The solution was to simply not allow this behavior. When you run this code on Euphoria 4.2 you'll now get this error message:

Cannot assign value with a destructor to an integer 

ChrisB said...

Why would anyone want to call a routine this way?

They likely wouldn't, but the example is contrived specifically to demonstrate a worthwhile edge case that has to be considered and accounted for.

-Greg

new topic     » goto parent     » topic index » view message » categorize

3. Re: Ticket #937: assigning to integer destroys the object prematurely

In the end this was the quickest path to something that didn't just malfunction without an explanation. You're right. I was supposed to make huge changes so this would simply work in a way so that the file handle destructor wouldn't get called until the program ended and the behavior of ending the program with this error message was supposed to be temporary, like income taxes were supposed to be temporary.

The task of getting the destructors to delay themselves in this circumstance only turned out to be far too great for me in the end.

new topic     » goto parent     » topic index » view message » categorize

4. Re: Ticket #937: assigning to integer destroys the object prematurely

Thanks, good to know.

new topic     » goto parent     » topic index » view message » categorize

5. Re: Ticket #937: assigning to integer destroys the object prematurely

SDPringle said...

In the end this was the quickest path to something that didn't just malfunction without an explanation. You're right. I was supposed to make huge changes so this would simply work in a way so that the file handle destructor wouldn't get called until the program ended and the behavior of ending the program with this error message was supposed to be temporary, like income taxes were supposed to be temporary. The task of getting the destructors to delay themselves in this circumstance only turned out to be far too great for me in the end.

Honestly I think that's too great of a challenge to try implementing anyway. I'd rather leave it as-is and then focus on a different approach to implement classes and structures which can have more "proper" destructors instead.

-Greg

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu