On Sat, Jul 07, 2007 at 03:33:35PM +0200, Udo Giacomozzi wrote: > Honestly, I think you're actually making a problem out of it. The name > of the file/function is badly choosen. Ok, let's change that. However, > the code itself is fine and no reason to go for big libraries like > Boost. After all, we're just talking about simple timing functions...
The problem with tu_ was initially knowledge. I tought it was best to use existing *standard* or de-facto standard classes rather then custom ones, in particular to help a team of developers with a good documentation and more peer-reviewd implementations of common algorithms. I haven't seen the timer one, but that's a single function and I don't have any big problem with it. If boost provides an equivalent function "for free" (ie: not increasing deps) that's fine too for me. Again: it's not the names, it's the lack of classes documentation, proper copy constructors or assignment operators and so on... it's usually not-clean code in general. And yes, I confirm we never discussed timers in particular till now. > usleep() is *not* a timing function. It's primary purpose is to tell > the system scheduler that the process is not going to do anything > within the next X nanoseconds. The scheduler then gives the next > process the running state. Could it be worth to use an inlined task_switch() call for clarity ? > case) and it does not use tu_timer. I'd like to change the latter in > favour to some generic timing but one has to tell me where I can find > that. (I'd opt for tu_timer renamed to whatever name you prefer). I think Markus is doing some research about ligher boost headers for that. --strk; _______________________________________________ Gnash-commit mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-commit
