[Gambas-devel] Early auto-instance
tobi
tobias at ...692...
Sat May 12 23:46:11 CEST 2012
On Sat, 12 May 2012, tobi wrote:
> 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
> >
>
>
> ------------------------------------------------------------------------------
> 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
>
I would go like this:
- Window not auto-creatable, parent Screen is mandatory for Window constructor
- Screen auto-creatable
It means that the user will have to create a Window to paint on first in every gb.ncurses program.
If I would make the parent parameter optional, I would have to use a default screen and then it
would be the same issue as above, I would need the auto-instance of Screen for this...
More information about the Devel
mailing list