On 22 September 2015 at 20:40, Stefan Karpinski <ste...@karpinski.org> wrote:
> I think that before any further discussion takes place of how easy or hard > implementing a high-performance printf is, anyone who'd like to comment > should spend some time perusing GNU libc's vfprintf implementation > <http://repo.or.cz/w/glibc.git/blob/ec999b8e5ede67f42759657beb8c5fef87c8cc63:/stdio-common/vfprintf.c>. > This code is neither easy nor trivial – it's batsh*t crazy. > That is insane... 2388 lines, half of it macros, and I have no idea how it works. > And we want to match its performance yet be much more flexible and > generic. The current printf implementation does just that, while being > somewhat less insane GNU's printf code. If someone has bright ideas for how > to *also* allow runtime format specification without sacrificing > performance or generality, I'm all ears. > This might be a stupid question, but what's the harm in sacrificing performance as long as we keep the current @sprintf for scenarios that call for performance? I don't always need printf() to be fast. > I have some thoughts, but they're just that – thoughts. One option is to > change the design and avoid printf-style formatting altogether. But then > I'm sure I'll never hear the end of it with people kvetching about how we > don't have printf. > Probably. Everyone is used to printf and they are comfortable with it. Daniel.
