I don't think Leif and Bryan are taking this seriously. For instance, I
went and checked the PRs dealing with BufferWriter formatting (3332). I
found one. In the same period, there was also a PR to deal with a compiler
problem with printf() (3476). One of these is dangerously unstable, the
other solid and reliable.
The code is hardly pushing the compiler technology envelope - it's all
C++11 with one small utility class ported from C++14 (which uses only C++11
features). This is 7 year old technology, it only seems new because we're
so far behind.
Similarly Bryan complains "On the design, formatting of objects shouldn't
be centralized. This creates dependency problems and problems with access
private members. Each object should have its own way of formatting in a
decentralized design." Which is exactly what the design does, lets each
type define its own formatting overload function. This isn't an incidental
feature, it's the core of the work.
I do appreciate your concern for my time, but as the person who has (1)
done the work and (2) used the library, my view is I expect an overall time
saving from the endeavor. Frankly, just using it for IP addresses I would
consider a win. Even ignoring that, it's a sunk cost now, almost all the
work is done.
P.S. So, if I say I don't want to replace printf, there's no problem? Of
course, no small part of the reason for the work on basic types like
integers was to get the performance level Leif and Bryan said was required.
When Bryan asked me to do the write up for the mailing list, I deliberately
took out any mention of Debug() in order to focus on the actual work, not
future plans. But that wasn't taken seriously either.
On Fri, Apr 20, 2018 at 7:22 PM, Leif Hedstrom <zw...@apache.org> wrote:
> Traveling, so keeping this short for now...
>
> > On Apr 20, 2018, at 10:18 AM, Jason Kenny <jke...@oath.com.INVALID>
> wrote:
> >
> > Is the concern bufferwritter or the use fo bufferwritter in TSDebug. I
> > agree the "extra" value is small for TSDebug. I feel the use of
> > bufferwritter is great within our code base.
>
>
> Many of us have spent significant amounts of time dealing with how to deal
> with he integration of this library on various platforms. I have yet to see
> the benefits here outweigh the work efforts. I have little confidence that
> the code would not continue to be a PITA when dealing with cross platforms
> / compilers. It’s just really pushing the envelope on how compilers
> implement these some of these features.
>
> The other concern I have is that we might be building a library that is to
> difficult to use,that people wont bother and rather just printf things. I
> know you fixed the performance issues that were noticeable before, but this
> is still a complex piece of code that IMO has yet to show value.
>
> Yes, pretty harsh, and we should have had this discussion long ago. I also
> know that some of this work was done to deal with string expansion in
> header_rewrite; but this is definitely not what I had in mind at the time.
> I wanted to just to be able to efficiently expand the %{} conditions in
> strings, not implement printf as it is.
>
> Ciao,
>
> — Leif
> >
> > -Jason
> >
> >> On Thu, Apr 19, 2018 at 5:42 PM, Bryan Call <bc...@apache.org> wrote:
> >>
> >> Replacing Debug()/TSDebug() with BufferWriter/bwformat has little
> >> benefit. Also, I don’t think adding another formatting interface for
> >> strings is something we want to maintain or use.
> >>
> >> The main downside, with snprintf(), I see reading the examples is having
> >> to keep track of the length and position in the buffer if you are
> calling
> >> snprintf() multiple times. This can be handled writing a simple wrapper
> >> around snprintf(), which I have done before in about 20 lines of code.
> If
> >> we want to expose a wrapper around snprintf(), I would be in favor of
> that.
> >>
> >> -Bryan
> >>
> >>> On Apr 19, 2018, at 11:20 AM, Alan Carroll <solidwallofc...@oath.com.
> INVALID>
> >> wrote:
> >>>
> >>> I have several pull requests up currently involving updates to output
> >>> formatting for BufferWriter. I was asked to provide more detail on the
> >>> point of these pulls requests. Anyone who is interested can read this
> >>> document - https://solidwallofcode.github.io/buffer-writer.en.html for
> >> that
> >>> detail.
> >>
> >>
>
>
