On 22/06/2011 04:18, Chris Frey wrote: > >> I've moved usbwrap to use a context which is currently just static >> within common.cc in b144ccb9199b4295db40. > Hmmm, I still don't like the Uninit() call in the destructor. Maybe > I'm just paranoid, but I can see cases where the application writer might > not ever want to call Uninit(), depending on his library dependencies. > At least for libusb 0.1 anyway, where the library is initialized only once.
Good point. >> I had a go at creating a Barry::Context, but it turns out there's quite >> a lot to do. Every use of dout(), ddout() and eout() needs to have a >> context passed to it and that means that almost every Barry object has >> to hold a reference to the context object. Are you happy for this to be >> the case? > Not really. :-) > I suspected that would be the case. > > I think it is important to have generic debug logging, though, without > context, because sometimes you just need to log an error, no matter what. > So I think it is ok to leave dout and friends as-is, for now, and not > include the logging stream in the context. In the future, we can > add context-oriented logging macros, that could take a controller object > as an argument, which would give the context. > > What do you think? Sounds reasonable. It certainly makes the changes smaller and it makes sense now you've pointed out the separation between debug logging for Barry developers vs. logging for Barry API users. I'm going to be a bit busy for the next couple of weeks so I'll leave the Barry context changes for now and use that time to think about it a bit more. > I'm ok with this. I think this danger already exists in the Probe API > ever since it began. It's the second Probe() that is the problem, not > the ~Probe(), I believe. And that makes sense. Even iterators > can't outlive their container getting reorganized. ProbeResults are > even more stable than iterators here, since they can outlive Probe. You're right that it's the second Probe() not the ~Probe() call and that it's pre-existing behaviour. I just wanted to draw attention to it as libusb 1.0 will work correctly in this situation, so it's possible that someone will write an application using Barry which only works if Barry is using libusb 1.0. Regards, Toby ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
