I think not Luke. Generated functions work on the types of the arguments. If someone wants to format based on an input string, then you either need a hardcoded value which can go into a macro, or a dynamic value that would go in a normal function.
If all you want to do is print out some arbitrary list of objects with pre-defined format, then a normal function should be plenty fast (and if it's a fixed format string, the current macro is the way to go). On Tue, Sep 22, 2015 at 8:21 PM, Luke Stagner <[email protected]> wrote: > 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 <[email protected]> >> wrote: >> >>> >>> On 22 September 2015 at 20:40, Stefan Karpinski <[email protected]> >>> 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. >>> >> >>
