Re: [boost] [RFC] string inserter/extractor "q u o t i n g"

Subject: Re: [boost] [RFC] string inserter/extractor "q u o t i n g"
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-06-23 06:51:24

Daniel James wrote:
> On 23 June 2010 03:49, Rob Stewart <robertstewart_at_[hidden]> wrote:
> >
> > My intention is that unquote() should handle a string with
> > multiple quoted substrings rather than just assuming that the
> > entire string is quoted.  It is certainly reasonable to think
> > that it should only handle whole strings.  In that case, it
> > would be easy to identify malformed strings on input: either
> > it starts and ends with the delimiter, and all other
> > occurrences are escaped, or it is malformed.
>
> I don't think that's right,

I take it you mean the current implementation isn't right and not the alternative I noted, or is it that you mean neither is right.

> since multiple quoted substrings normally means multiple values
> (apart from in C family languages, but then text outside the
> quotes is interpreted differently).

The point of unquoting a string is to remove the quotation marks and escape characters, not to split a string into parts.

> Looking at your code, the escape should work outside of the
> quotes and you don't check for the end of the string after an
> escape.

Thanks.

> > I quickly chose to throw std::logic_error from unquoted()
> > when it fails to find a closing delimiter.  There may well be
> > a better approach; feel free to suggest alternatives.
>
> You should inherit from std::runtime_error, since that would be
> usually caused by bad input rather than programmer error.

Reasonable.

> To be honest, I don't see the value of this. As this is the
> kind of thing which is handled well in other ways (e.g. using a
> parser or lexer generator, or a standard data format such as
> XML, JSON etc.).  There tends to be odd differences in quoting,
> encoding and escaping styles making a generic function awkward.
> It's not as specific as a filename extractor and not as generic
> as a parser and it's not clear why there's a need for something
> in between.

Those other approaches are heavier than these algorithms, which can serve simple cases quite well.  If you'd care to enumerate the special cases to which you allude, we can consider how best to address them, if support is warranted.

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

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.