Re: [boost] Re: outputformatters - using just one decorator string

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-09-23 08:46:44

From: Reece Dunn <msclrhd_at_[hidden]>
> John Torjo wrote:
> > Rob Stewart wrote:
> >> Agreed, but pipes ("|") are easier to grok:
> >>
> >>   "<elem> | </elem><elem> | </elem>"
> > 
> > That's fine too.
> 
> This again runs into the problem of what if you want '|' in your format 
> string? One possibility is to use non-printable characters, e.g. \xFF, 
> but I don't think this would have widespread support.
> 
> Implementing escaping for the above will complicate the evaluation of 
> the format string as you cannot use str.find( "|" ). One possibility is 
> to check if '\' exists before '|' after a find; if yes, repeat. Thus '\' 
> becomes context-sensitive. This approach leads to "< |\\| >" for "< 
> a\\b\\c >" formatting being ill-defined.

The point is that this notation is far simpler to understand than
what you currently offer in your library, so it seems like a good
idea.  If you accept that point, then you must choose a
delimiter.  Your choice of delimiter should be based upon
readability and frequency of use elsewhere in the format string.
Nevertheless, whichever delimiter you choose, you must allow it
to be escaped because someone, somewhere, sometime will want the
delimiter to be part of the text used to format the data.

Pipes shine in the readability category, but are probably
somewhat likely to appear in output -- for the same reason they
are readable in the format string.

Some other good choices are "#", "@", "!", "^", and "_".  Have a
look at the previous example (I've removed the spaces so the
delimiters are set apart with spaces so we can see how good they
really are):

   "<elem>|</elem><elem>|</elem>"

   "<elem>#</elem><elem>#</elem>"

   "<elem>@</elem><elem>@</elem>"

   "<elem>!</elem><elem>!</elem>"

   "<elem>^</elem><elem>^</elem>"

   "<elem>_</elem><elem>_</elem>"

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;