Would it be possible to rewrite @printf as a generated function instead of a macro. That way the calling syntax would be more familiar.
On Tuesday, September 22, 2015 at 1:07:23 PM UTC-7, 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. >> > >
