On Thu, Jul 28, 2011 at 2:05 AM, Larry Gritz <[email protected]> wrote:
> Wow, this is exceptionally cool. I'm highly tempted to pull this into every
> project I work on. Do you consider it stable at this point?
Haha, excellent! I suspect the fact that this is a nice fit for OIIO is
the OIIO project development culture rubbing off on me :-)
Regarding stability, if you look at the test cases you'll see that all
the basic stuff works already. I'm sure there's some rough corners I
haven't thought about though since the project is no more than a few
days old. One issue I haven't fixed is to decide how the current stream
state should affect the formatting (the right answer probably being: it
shouldn't).
By the way, if you (or anyone else here) have any suggestions to make
the code better I'm all ears.
> I think I hadn't really seen variadic templates used before. Do you think
> they are supported on all the compilers we care about?
Unfortunately not. Guess which important and well known compiler
doesn't support them yet... yup, you guessed it, it's the visual studio
compiler. The developers have apparenly stated that support is planned
for VS2011, so it will be coming soon. You probably noticed that I've
given thought to C++98 support, so that's not necessarily a deal
breaker. However, it's rather painful to wrap tfm::format() inside
another interface (for example, ErrorHandler::error()) if you don't have
varadic templates. A bit of judicious code generation using python can
avoid any manual copy & paste, but it's still not incredibly nice.
> With everything inlined, do you see a lot of code bloat if you riddle a big
> project with format calls? Do you think there's any advantage to making the
> header small and having a single .cpp that holds the implementations of some
> of the bigger inline functions?
In response to these questions, here's a test I did:
I generated 100 cpp files, a00.cpp to a99.cpp, each containing a unique
function which looks like
void doFormat_a99()
{
printf("%s\n", "somefile.cpp");
printf("%s:%d\n", "somefile.cpp", 99);
printf("%s:%d:%s\n", "somefile.cpp", 99, "asdf");
printf("%s:%d:%d:%s\n", "somefile.cpp", 99, 1, "asdf");
printf("%s:%d:%d:%d:%s\n", "somefile.cpp", 99, 1, 2, "asdf");
}
So, that's 100 translation units with a total of 500 tinyformat printf()
calls. Then I linked all these together and called them from main.cpp.
I also made the comparable thing using boost::format, and a version of
tinyformat.h where all the inline functions possible were moved out into
a cpp file.
Results:
| | total compile time | a.out size (stripped)
| printf | 1.2s | 44K (36K)
| tinyformat | 12.9s | 172K (140K)
| tinyformat, c++0x mode | 14.8s | 172K (140K)
| tinyformat, no inlines | 12.0s | 128K (100K)
| boost::format | 51.6s | 772K (676K)
As shown above, there is about 40% avoidable bloat due to inlines when
the project does _nothing else_ but call tfm::printf(). In a large
project the total percentage overhead will be really minimal I think, so
I think it's worth keeping tinyformat a header-only library for sheer
convenience.
You can see that printf() really wipes the floor with the alternatives
in terms of compile time and executable size. This isn't surprising but
I think the tinyformat overhead is worth it for the extra type safety.
Finally, it's clear that users of boost::format really pay for the extra
completeness, given both the compile time overhead and extra executable
bloating.
~Chris
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
