[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