> The inflated symbol table will have much more trouble with cache, which > will penalise runtime performance if you're using lazy symbol resolution, > which is compounded by most of the log_* messages incurring a lookup since > they use different symbols.
In theory, but again in practice we haven't had any indication that it is a problem. I count 700 log_* symbols, by the way. The more important argument is that there are important differences between boost::format and printf: 1. boost::format automatically makes use of an available ostream operator<< for a class, and we use this frequently. It's not possible, and certainly not legal, to send these to vsnprintf. 2. boost::format has other substitutions, such as %1% and %2%, which are used in some places and not recognized by printf. 3. The printf substitutions are no longer used correctly in many places (for instance we have %s for some numeric values) because it is no longer checked, and boost::format doesn't care. 4. Even when they are used correctly, printf always made problems with pointer sizes, because they require a different substitution on different platforms. The abomination that was used to work around this was dropped when it was no longer needed. In short, using va_args and printf will at best give nonsense, and at worst format your hard drive and start a nuclear war. > http://stdcxx.apache.org/doc/stdlibug/13-5.html describes the std::remove > algorithm, which bubbles the all non-removed elements to the beginning of > the sequence so should be logically equivalent to having relocated the > removed elements to the end. One doesn't follow from the other... vector<int> v = { 1, 2, 3, 4, 5 }; remove(v.begin(), v.end(), 3)); The result at least in the gcc stdlib implementation is 1, 2, 4, 5, 5. The standard specifies only that the container remains the same size, the non-removed elements are copied to the front, and the function returns an iterator pointing to the end of the non-removed sequence. There are no guarantees about what is or isn't at the end (though generally it will be the original values, because otherwise the algorithm would do unnecessary copying). > This is O(n^2) and the commented code should be O(n*log n) if I used a > list instead of the typedef'd vector. I don't see any point for a short > string so I'll just remove the commented code. We're talking about a container of about 4 strings. A lunatic might possibly multiply that by a factor of 10. Why would you need to parse 40 gnashrcs? I don't know. He's a lunatic. In both cases, the number of insertions ought to be relatively low. So we should have code that is simple, self-documenting, and easy to read before even thinking about complexity. > I don't even know what NellyMoser is. ;) > So are you just suggesting substituting magic constant for the #define > (that file seems to be full of them)? Yes, I'm suggesting using a named const double as a magic constant. Also I'm suggesting removing the file, but I'm not sure who knows enough about it to make that decision. I know ffmpeg handles NellyMoser (it's an audio codec) if the version is new enough and that file is a fallback for older versions. But I don't think it works, so the advantage over having no fallback isn't very obvious. bwy -- Free Flash, use Gnash http://www.gnu.org/software/gnash/ Benjamin Wolsey, Software Developer - http://benjaminwolsey.de
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
