[PATCH 1/7] Refactor device handling threads

Anton Lundin glance at acc.umu.se
Tue Jan 20 15:12:22 PST 2015


On 20 January, 2015 - Thiago Macieira wrote:

> On Tuesday 20 January 2015 23:34:59 Anton Lundin wrote:
> > It's part of the whole get-progress-events series, and I thought using a
> > common ancestor to all those classes made it easier to implement the
> > whole progress event thingie.
> > 
> > That way i can have them all behave the same way in that respect.
> > 
> > 
> > I also have some unfinished code for generating trace logs from
> > different actions for debugging purposes. I've used it my self to
> > diagnose some older bugs, but its kinda rough, and I haven't had the
> > time to clean that code up. (And it hasn't bin needed to get any debug
> > logs from users yet...)
> > 
> > 
> > Does that make more sense?
> 
> Yes, it does.
> 
> It's just that a quick look at the progress patches didn't seem to require the 
> common ancestor.
> 
> Wait, I see it now in patch 3. The callback is in DeviceThread.
> 
> Never mind, nothing to see here...
> 

Yea, the ordering of the patches wasn't great, but i think it can pass
as acceptable.

> 
> Useless trivia (and at the risk of making Dirk and Linus hate C++ even more): 
> passing a C++ static method as a callback to a C function is not standards-
> compliant. The callback should be a non-member static function inside an 
> extern "C" block.
> 
> No, don't do that. This is useless.

But how would you do the cast to get the object to execute the callback
on then?


//Anton - Who cursed at c++ for not accepting designated initializers..


-- 
Anton Lundin	+46702-161604


More information about the subsurface mailing list