But Michael Hatherly's showed code above that uses a generated function to
solve this. It seems to work pretty well in the short while I tried it in
the REPL. Granted I didn't time it or do anything complicated. It works on
Stefan's example above with no problem. The only difference is that one
must type fmt("format") instead of "format". Possibly that could be
shortened to fmt"format" using a str_macro (although that had some effects
when I tried it).What am I missing? Bob On Tue, Sep 22, 2015 at 6:32 PM, Tom Breloff <t...@breloff.com> wrote: > 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 <lstagne...@gmail.com> > 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 <dcar...@gmail.com> >>> wrote: >>> >>>> >>>> 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. >>>> >>> >>> >
