[Gambas-devel] Early auto-instance

[tobi]

On Sat, 12 May 2012, Benoît Minisini wrote:
> Le 12/05/2012 21:14, tobi a écrit :
> > On Sat, 12 May 2012, tobi wrote:
> >> Hi,
> >>
> >> I have a compilation unit that provides a function which in turn depends on the state of an object.
> >> The default object is the auto-instance of a class (it is just a simple buffered output) but the
> >> auto-instance of a class seems to be created on-the-fly when first requested. Now this auto-instance
> >> may not be created normally before I need to take actions depending on its state (call the exported
> >> function by another piece of code)... I thought of having
> >>
> >> GB.AutoCreate(GB.FindClass("Screen"), 0);
> >>
> >> called from within the GB_INIT() of my component to ensure that there exists a valid object. The
> >> program works now but I get a segfault:
> >>
> >> Program received signal SIGSEGV, Segmentation fault.
> >> MEMORY_clear_cache () at ../share/gb_alloc_temp.h:96
> >> 96                              next = *((void **)ptr);
> >> (gdb) print ptr
> >> $1 = (void *) 0x123
> >>
> >> when the program is going to exit. Is there somehting, I should keep in mind when manually creating
> >> this auto-instance?
> 
> GB_INIT() is called before the component classes are registered, so 
> GB.FindClass("Screen") should return NULL. So this is not the good place 
> for that!
> 
> The goal of having auto-creatable class is the ability of using the 
> class name as the default object of a class. That's all.
> 
> >>
> >> Another point: This is provisional only; I will have to rewrite it anyway when I make Screen a true
> >> creatable class.
> 
> GB_AUTO_CREATABLE() is for true creatable class, even if you add 
> GB_NOT_CREATABLE(), that just means that we cannot use the New operator 
> to instantiate the class in code. But the class keeps being creatable 
> internally.

When I said "true creatable", I meant that for now only the auto-instance could be used as other
objects created via New would entirely confuse the component - that's what I'm going to correct and
afterwards call it "true creatable" ;) Sorry for the misunderstanding...

> 
> A class that is not creatable class has GB_VIRTUAL(), or a size of 0 in 
> the GB_DECLARE() statement and only static methods.
> 
> >> So there is my next question regarding coding style in gambas: Is it common to save
> >> a pointer to another gambas object (the parent object) when creating? This would solve the
> >> auto-instance problem as my Screen class (which is to auto-create earlily) is reference during
> >> instanciation of the Window object and the latter is the object which calls the function in question
> >> (which depends on the active Screen class to enable buffered output on screen).
> 
> Of course you can have child/parent relationship through object 
> pointers, provided that you use GB.Ref() and GB.Unref() effectively.
> 
> But why do you need to instanciate the default Screen class object 
> early? It seems weird to me...

Yes, well, GB.Ref() and .Unref() are used for reference counting, right? I don't have to worry about
anything, only the balance of my calls to either of them?

Consider the following code:

.src/MMain.module
--8<---------------
' Gambas module file

Public Sub Main()
  Window.Print("test")
End
--8<---------------

This would print text and then exit. Printing text involves a screen refresh - as the name suggests,
I moved the corresponding routine to the Screen class (formerly known as WINDOW_refresh,
WINDOW_real_refresh and macros), the buffering mechanism, too. But at the time, I call
Window.Print(), there is no Screen class available of which I can check buffer settings.
For future, when Screen becomes usable as a creatable class (s.a.), it would be convenient to
associate Windows to the Screen they are printing their data on so this is required. I could have

static void SCREEN_refresh(void *_object)
{
	if (!THIS) {
		SCREEN_real_refresh();
		return;
	}
	if (THIS->buffered) {
		...
}

But I would likely need the Screen auto-instance somewhere else.

If it is so complicated, my approach almost appears like a design failure to me...

> 
> >> That sounds tricky,
> >> so I wanted to ask if it is considered good style in gambas or if there are other ways to do it. The
> >> place I knew to look for was the gb.qt4 component which delegates the parent object stuff to qt
> >> itself...
> >>
> >> Regards,
> >> Tobi
> >>
> >
> > Oops!
> > I also auto-create a Window object so the parent is to be optional... This solution wouldn't prevent
> > me from manually auto-creating the Screen class. I tend to remove the GB_AUTO_CREATABLE() statement
> > from both descriptions :/
> >
> 
> -- 
> Benoît Minisini
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>