On Monday 12 of December 2011, Michael Meeks wrote: > On Mon, 2011-12-12 at 16:30 +0100, Lubos Lunak wrote: > > The format-based usage uses a printf-like function that, unlike printf, > > is typesafe and extensible. If people would be interested, the function > > itself could be made public API (after all, there's a reason why printf > > is still popular even nowadays, despite all its shortcomings). > > I'd love that personally; I'd love to have it as a way to construct > OUStrings as well - potentially rather more readable and more > efficient/faster than an OUStringBuffer for those cases where we can > calculate a precise allocation size from our arguments first. There are > a lot of call sites like: > > avmedia/source/framework/mediaitem.cxx: > ::rtl::OUStringBuffer > :: buf(::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( > > "vnd.sun.star.Package:"))); > buf.append(media); > buf.append(sal_Unicode('/')); > buf.append(filename); > o_rEmbeddedURL = buf.makeStringAndClear(); > > That are crying out to be one-liners with this sort of thing :-) in > fact, large numbers of rtl::OUStringBuffer usage sites could be made > more succinct, readable, maintainable and potentially more efficient > with this :-)
Note that as shown in the 'message construction bloat' thread this can easily be o_rEmbeddedURL = "vnd.sun.star.Package:" + media + '/' + filename; and be as efficient as possible. As soon as SUSE has the next HackWeek :). Stephan's reply made me realize it would be better to have the format functionality specialized for logging, so that there can be easy conversions even for types like SwNode where one definitely does not want a conversion to a string in any other case. There could be a separate functionality for strings as well, but I can't quite judge the usefulness for LO - Qt has this and it's used in KDE a lot, but it's mostly for creating UI strings ("Open file %1 in %2?" is certainly better for both coders and translators) and LO has a different system for translations. > > Attached source code has a testing implementation of the format function > > and a simple logging macro. It still needs few final touches but it's > > generally ready. The templates may look scary at first, but it's rather > > simple, they are just making the function to take up to 9 arguments of > > each of the supported arguments and the template for return type is > > SFINAE[1]. > > We can (presumably) inline them - they all evaporate away. It seems > that it does indeed turn into a single function call. I imagine we > should put the virtual 'append' methods into a separate shared object > though. That depends exactly on the requirements. If one wants a small single call in the place of use, then all those templates have to be generated somewhere, and although the most used ones can be made external, the number of possible combinations explodes here. The other extreme would be inlining everything but then the place of the call would generate larger code. And if this is to end up in an ABI stable library then there's not much room for later experiments :-/. -- Lubos Lunak l.lu...@suse.cz _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice