But Michael Hatherly’s showed code above that uses a generated function to
solve this.
What am I missing?
It’s probably because the thread was getting quite long and what I wrote
simply got missed.
— Mike
On Wednesday, 23 September 2015 03:15:23 UTC+2, Bob Nnamtrop wrote:
>
> 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
> <javascript:>> 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 <lstag...@gmail.com
>> <javascript:>> 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.
>>>>>
>>>>
>>>>
>>
>
