Stefan, don't beat yourself up so much :) Sometimes the choice of fast or flexible just has to be made. Maybe call them @fast_printf() and printf() (after appropriate deprecation time of course). So long as the flexible printf is "adequate" performance (as Rolls Royce used to say).
Then if your ideas for flexible printf work out they can improve it over time, as convenient. And of course other non-printf APIs can be added (but please don't (re)invent C++ << :). Cheers Lex On Wednesday, September 23, 2015 at 6:07:23 AM UTC+10, Stefan Karpinski wrote: > > Possible, but I don't relish the thought of forever explaining to people > that they need to use printf with or without the @ depending on if they > want it to be fast or flexible. If you really don't care about speed, you > can just do this right now: > > printf(fmt::AbstractString, args...) = @eval @printf($(bytestring(fmt)), > $(args...)) > > > But actually don't do that because it's so horrifically slow and > inefficient I just can't. > > On Tue, Sep 22, 2015 at 3:57 PM, Daniel Carrera <dcar...@gmail.com > <javascript:>> wrote: > >> >> On 22 September 2015 at 20:40, Stefan Karpinski <ste...@karpinski.org >> <javascript:>> 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. >> > >
