The documentation doesn’t mention Debug(), but you have talked that you would like to see this as a complete replacement for Debug(). That also needs to be discussed.
Open source projects (proxies, and https servers) I have looked at use printf() or iostreams. I haven’t seen one that implements is own formatting library. 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. -Bryan > On Apr 20, 2018, at 6:27 AM, Alan Carroll <solidwallofc...@oath.com.INVALID> > wrote: > > The document doesn't mention Debug() nor TSDebug(). > > I think the downsides of (1) having to do pre-string conversions for > non-builtin types such as IP Addresses and (2) having to select from a > confusing and sometimes (as in PR 3476) impossible to be cross platform > portable set of integer format codes are much bigger downsides and unlikely > to be fixed by a length tracking wrapper. > > I would say the overall utility of this is demonstrated by the repeated > attempts to bypass printf, e.g. the entire C++ stream I/O library, and the > other near-standard Boost with Boost.Format. > > I think you are overestimating the maintenance cost. At this point, with > the built in types written, further work would be done any way, simply with > different syntactic wrapping. For instance, the IP Address formatting could > be done via a family of additional ats_ip_XXX functions, > or even done cut&paste style in multiple locations, but I fail to see > either of those as less work. Such work is going (or has been) done, it > would be good to have a mechanism where such work could be done only once. > My view is the overall maintenance costs of the code base would be reduced. > > 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. >> >>
