--Apple-Mail=_B85897B9-EC0E-429B-BF6A-805FD5A5F0FB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

Hi there,

I am wondering whether JSON [RFC7159] support would be a helpful extension =
to the C++ standard library (pure library extension), including, but not li=
mited to, the following aspects:

1. A variant-like container type (for this mail, let's call it "std::json")=
 that combines C++ types for the JSON value types [RFC7159, chapter 3]:
  - string (e.g. std::string),
  - number (e.g., double or int64_t),
  - boolean (e.g., bool),
  - array (e.g., std::vector), and
  - object (e.g., std::map).

This type should have an intuitive API (i.e., all expected container method=
s), but also use as much syntactic sugar as possible (e.g., using initializ=
er lists to express arrays like "std::json my_array =3D {"a string", 17, 42=
..12};".

2. A serialization function to create a textual representation (called "JSO=
N text" in [RFC7159]) from a std::json value that conforms to the JSON gram=
mar [RFC7159, chapter 2-7].

3. A deserialization function (i.e., a parser) [RFC7159, chapter 9] to crea=
te a std::json value from a JSON text.

There are currently dozens of libraries [json.org] written in C or C++ solv=
ing these aspects. However, it would be of great convenience to have JSON b=
e part of the C++ standard library. In particular, the wide use of JSON as =
exchange format for structured data as well as to express simple configurat=
ion data would could solve a lot of use cases within the C++ standard libra=
ry.

I would be willing to draft a proposal based on the experience I made with =
my C++ JSON library [nlohmann/json]. Of course, I would be interested in yo=
ur thoughts on this.

All the best,
Niels

References

[RFC7159] https://tools.ietf.org/html/rfc7159.html
[json.org] http://json.org
[nlohmann/json] https://github.com/nlohmann/json

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3DF8137F-C90E-4D25-96AB-FF8B766418DF%40nlohmann.=
me.

--Apple-Mail=_B85897B9-EC0E-429B-BF6A-805FD5A5F0FB
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename=signature.asc
Content-Type: application/pgp-signature;
 name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYtzxIAAoJEH886mOuJRtp9CcP/A8hUM+Foy6FaNS7NGGnE0yk
9cyd3UtkgCNDfLliQrbkOOOrX/LLRWkc73TVMn3KF4xky5DdCk2PHY80YrGI19N/
LrOZ7NHhR+T8/tI5p9P5rgezhwl3tB4Rfw0oTpAygEI1srV/4Hrdobhb5JKMdVvi
tLeEHtIw0/5YyTq1f42kQB8bDPPAkqSBrAu0bvzB/jd86KsR1Bm5FOL05k8d6Rbj
8WuOXXHuBY7V+7OiexG4uQkZlK8FiB83Win6Sbepd4qSGq7mt0mT2R7AxHLsyyxc
AEQnjLtw8MLRQiQN/lciTNOs+uAaP125arts3OorcP6lEtLb/Ilm+7HYm9mJHKa9
usa973hzYG9JHFtAszlImdyzYRGD+dVLVykxp+zI50PhnlSI1C/B64bldTGwrdG/
0/rJym1OEPIpM7XdZWuZb18mzkg0kPSkG7mPMoWGlC2anMmXCQoFGSc4ervXu1bz
BQzPuvHXP4cS7cA0htj6ZAuBqquRBpelp8l4SbgxtL+L2kGCDrthe66in2rBXElH
Acs/R8f6XakxA81YUaouqkL9FAxik+zvQxEVHa2/6jZrpGm/WIje8fk2roYOWWsR
6GrhFLMkGZbMbc0uYp+47VPLzBR+9Ii4z2xxgRzWjtAg+vEsNAOTuomQvFRyh7WF
yH26s8y+/rzhtKfagodM
=gEej
-----END PGP SIGNATURE-----

--Apple-Mail=_B85897B9-EC0E-429B-BF6A-805FD5A5F0FB--

.

------=_Part_1613_592952379.1488404519614
Content-Type: multipart/alternative;
 boundary="----=_Part_1614_95997979.1488404519615"

------=_Part_1614_95997979.1488404519615
Content-Type: text/plain; charset=UTF-8

On Wednesday, March 1, 2017 at 4:25:33 PM UTC-5, Niels Lohmann wrote:
>
> Hi there,
>
> I am wondering whether JSON [RFC7159] support would be a helpful extension
> to the C++ standard library (pure library extension), including, but not
> limited to, the following aspects:
>
> 1. A variant-like container type (for this mail, let's call it
> "std::json") that combines C++ types for the JSON value types [RFC7159,
> chapter 3]:
>   - string (e.g. std::string),
>   - number (e.g., double or int64_t),
>   - boolean (e.g., bool),
>   - array (e.g., std::vector), and
>   - object (e.g., std::map).
>
> This type should have an intuitive API (i.e., all expected container
> methods), but also use as much syntactic sugar as possible (e.g., using
> initializer lists to express arrays like "std::json my_array = {"a string",
> 17, 42.12};".
>

> 2. A serialization function to create a textual representation (called
> "JSON text" in [RFC7159]) from a std::json value that conforms to the JSON
> grammar [RFC7159, chapter 2-7].
>
> 3. A deserialization function (i.e., a parser) [RFC7159, chapter 9] to
> create a std::json value from a JSON text.
>
> There are currently dozens of libraries [json.org] written in C or C++
> solving these aspects. However, it would be of great convenience to have
> JSON be part of the C++ standard library. In particular, the wide use of
> JSON as exchange format for structured data as well as to express simple
> configuration data would could solve a lot of use cases within the C++
> standard library.
>
> I would be willing to draft a proposal based on the experience I made with
> my C++ JSON library [nlohmann/json]. Of course, I would be interested in
> your thoughts on this.
>

If you're going to do this, then you need to take into account the
following:

1) Allocator support. Whatever containers you use, the user must be able to
decide how allocation works.
2) Visitation support. Or just use `std::variant`.
3) For strings, you need to make a determination if the JSON object should
own the string or not. For JSON objects parsed from in-memory strings,
users might want to have it store `string_view`s that reference the string
directly rather than `string`.

Also, I wouldn't call it "serialization".

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9555f553-40c4-4266-9a30-1728421026be%40isocpp.org.

------=_Part_1614_95997979.1488404519615
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, March 1, 2017 at 4:25:33 PM UTC-5, Niels Loh=
mann wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi there,
<br>
<br>I am wondering whether JSON [RFC7159] support would be a helpful extens=
ion to the C++ standard library (pure library extension), including, but no=
t limited to, the following aspects:
<br>
<br>1. A variant-like container type (for this mail, let&#39;s call it &quo=
t;std::json&quot;) that combines C++ types for the JSON value types [RFC715=
9, chapter 3]:
<br>=C2=A0 - string (e.g. std::string),
<br>=C2=A0 - number (e.g., double or int64_t),
<br>=C2=A0 - boolean (e.g., bool),
<br>=C2=A0 - array (e.g., std::vector), and
<br>=C2=A0 - object (e.g., std::map).
<br>
<br>This type should have an intuitive API (i.e., all expected container me=
thods), but also use as much syntactic sugar as possible (e.g., using initi=
alizer lists to express arrays like &quot;std::json my_array =3D {&quot;a s=
tring&quot;, 17, 42.12};&quot;.<br></blockquote><div></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">
<br>2. A serialization function to create a textual representation (called =
&quot;JSON text&quot; in [RFC7159]) from a std::json value that conforms to=
 the JSON grammar [RFC7159, chapter 2-7].
<br>
<br>3. A deserialization function (i.e., a parser) [RFC7159, chapter 9] to =
create a std::json value from a JSON text.
<br>
<br>There are currently dozens of libraries [<a href=3D"http://json.org" ta=
rget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www=
..google.com/url?q\x3dhttp%3A%2F%2Fjson.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNH6GHLj2q4_Ao1l2Xd4-wR9sDnARA&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fjson.org\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNH6GHLj2q4_Ao1l2Xd4-wR9sDnARA&#39;;return true;">=
json.org</a>] written in C or C++ solving these aspects. However, it would =
be of great convenience to have JSON be part of the C++ standard library. I=
n particular, the wide use of JSON as exchange format for structured data a=
s well as to express simple configuration data would could solve a lot of u=
se cases within the C++ standard library.
<br>
<br>I would be willing to draft a proposal based on the experience I made w=
ith my C++ JSON library [nlohmann/json]. Of course, I would be interested i=
n your thoughts on this.
<br></blockquote><div><br>If you&#39;re going to do this, then you need to =
take into account the following:<br><br>1) Allocator support. Whatever cont=
ainers you use, the user must be able to decide how allocation works.<br>2)=
 Visitation support. Or just use `std::variant`.<br>3) For strings, you nee=
d to make a determination if the JSON object should own the string or not. =
For JSON objects parsed from in-memory strings, users might want to have it=
 store `string_view`s that reference the string directly rather than `strin=
g`.<br><br>Also, I wouldn&#39;t call it &quot;serialization&quot;.</div><br=
></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9555f553-40c4-4266-9a30-1728421026be%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9555f553-40c4-4266-9a30-1728421026be=
%40isocpp.org</a>.<br />

------=_Part_1614_95997979.1488404519615--

------=_Part_1613_592952379.1488404519614--

.

On Wed, Mar 1, 2017 at 3:25 PM, Niels Lohmann <mail@nlohmann.me> wrote:
>
> I would be willing to draft a proposal based on the experience I made with my C++ JSON library [nlohmann/json]. Of course, I would be interested in your thoughts on this.

You must have been aware of rapidjson for quite
long time, so it won't be too surprising to you if I
say "no SAX, no consideration" I guess :/

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuCd5YD0oJ0EV1ZqByrbcEyrzLZFf_J3fLgXACgFOno-LA%40mail.gmail.com.

.

Hi Niels, all,

> On 1 Mar 2017, at 22:25, Niels Lohmann <mail@nlohmann.me> wrote:
>=20
> I am wondering whether JSON [RFC7159] support would be a helpful extensio=
n to the C++ standard library (pure library extension), including, but not =
limited to, the following aspects:

I believe it would certainly be helpful to a large amount of users.

Disclaimer: I'm an author of a different JSON library, <https://github.com/=
taocpp/json>. Documentation is still a weak point, but the library is quite=
 usable already. More information about the library, including the below me=
ntioned SAX-approach can be found in some slides of a talk I gave: <http://=
www.wilkening-online.de/programmieren/c++-user-treffen-aachen/2016_11_10/ta=
ocpp-json_DanielFrey.pdf>

> 1. A variant-like container type (for this mail, let's call it "std::json=
") that combines C++ types for the JSON value types [RFC7159, chapter 3]:

Or std::json::value to have std::json::* available for a lot of other types=
/functions/... that fall into the JSON realm.

> This type should have an intuitive API (i.e., all expected container meth=
ods), but also use as much syntactic sugar as possible (e.g., using initial=
izer lists to express arrays like "std::json my_array =3D {"a string", 17, =
42.12};".

I think that having "all the expected container methods" is going to far, i=
t seems "forced" to me and not a natural fit. A JSON value *can* be a conta=
iner, but it is not generally a container. And all JSON values form a tree,=
 not a flat container.

Concerning the initializer list support, which I really like in practice:

1) No magic, please. In your library you scan the initializer list to check=
 if it *could* be an object, otherwise you turn it into an array. I'd avoid=
 that and use a clear and unambiguous syntax. In our library we use initial=
izer lists only to create JSON objects and json::value::array(std::initiali=
zer_list<...>) to create JSON arrays.

2) Initializer lists usually require *copies* of all elements. Hopefully th=
ere is some independent proposal to allow *moving* the values of an initial=
izer list. This is especially important for the JSON use case, as JSON valu=
es can be (deeply) nested.

3) Both of our libraries already have that feature, but I would think it is=
 also important for standardization that the specialization of UDTs is poss=
ible (how they are converted from and to JSON).

> 2. A serialization function to create a textual representation (called "J=
SON text" in [RFC7159]) from a std::json value that conforms to the JSON gr=
ammar [RFC7159, chapter 2-7].
>=20
> 3. A deserialization function (i.e., a parser) [RFC7159, chapter 9] to cr=
eate a std::json value from a JSON text.
>=20
> There are currently dozens of libraries [json.org] written in C or C++ so=
lving these aspects. However, it would be of great convenience to have JSON=
 be part of the C++ standard library. In particular, the wide use of JSON a=
s exchange format for structured data as well as to express simple configur=
ation data would could solve a lot of use cases within the C++ standard lib=
rary.
>=20
> I would be willing to draft a proposal based on the experience I made wit=
h my C++ JSON library [nlohmann/json]. Of course, I would be interested in =
your thoughts on this.

I think that the SAX-like approach we use in our library would be a very go=
od fit for a standardization proposal as it allows to decouple the differen=
t parts and if only a small sub-set of the possible event producers and con=
sumers are standardized, it allows the user to add and mix those parts with=
 other things like a non-JSON-conformant parser that accepts "relaxed JSON"=
 or binary formats like CBOR, etc.

It would even allow for different value classes, depending on the use case.=
 Some people might need the fastest value class possible and hence might wa=
nt something with special allocators to minimize the number of allocations =
(basically what RapidJSON does to achieve speed), some would need value cla=
sses which always sort the keys or allow multiple keys (which I personally =
don't like at all, but if it should be standardized, I am not the one to ma=
ke the call). It again allows a standardized value class for "most" users a=
nd still allows to combine all other parts (parsers, to_string, ...) to be =
re-used when the user decides to use another value class.

Thinking about the scope of what this proposal has to cover, I think this i=
s a *lot* of work. If you'd like help/cooperation on writing a proposal, I'=
m certainly interested.

Best regards,
Daniel

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7015CA97-5D3D-4DB0-BA67-62F768800B6E%40gmx.de.

.

=E2=80=8E>=C2=A01) No magic, please. In your library you scan the initializ=
er list to check if it *could* be an object, otherwise you turn it into an =
array.

Objects need names for each member, right? So the magic would check for str=
ing, value, string, value,... pattern? Yeah, that's a bit scary.=C2=A0

I once did a DSL that would allow something like

Json json =3D { "x"k =3D 17, "y"k =3D { 1,2,3 }, "z"k =3D "hello"} ;


=E2=80=8EYou can make it quite json-like (replace : with =3D, etc).=C2=A0



Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Daniel Frey
Sent: Wednesday, March 1, 2017 5:32 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Cc: Niels Lohmann
Subject: Re: [std-proposals] JSON support for the C++ standard library

Hi Niels, all,

> On 1 Mar 2017, at 22:25, Niels Lohmann <mail@nlohmann.me> wrote:
>=20
> I am wondering whether JSON [RFC7159] support would be a helpful extensio=
n to the C++ standard library (pure library extension), including, but not =
limited to, the following aspects:

I believe it would certainly be helpful to a large amount of users.

Disclaimer: I'm an author of a different JSON library, <https://github.com/=
taocpp/json>. Documentation is still a weak point, but the library is quite=
 usable already. More information about the library, including the below me=
ntioned SAX-approach can be found in some slides of a talk I gave: <http://=
www.wilkening-online.de/programmieren/c++-user-treffen-aachen/2016_11_10/ta=
ocpp-json_DanielFrey.pdf>

> 1. A variant-like container type (for this mail, let's call it "std::json=
") that combines C++ types for the JSON value types [RFC7159, chapter 3]:

Or std::json::value to have std::json::* available for a lot of other types=
/functions/... that fall into the JSON realm.

> This type should have an intuitive API (i.e., all expected container meth=
ods), but also use as much syntactic sugar as possible (e.g., using initial=
izer lists to express arrays like "std::json my_array =3D {"a string", 17, =
42.12};".

I think that having "all the expected container methods" is going to far, i=
t seems "forced" to me and not a natural fit. A JSON value *can* be a conta=
iner, but it is not generally a container. And all JSON values form a tree,=
 not a flat container.

Concerning the initializer list support, which I really like in practice:

1) No magic, please. In your library you scan the initializer list to check=
 if it *could* be an object, otherwise you turn it into an array. I'd avoid=
 that and use a clear and unambiguous syntax. In our library we use initial=
izer lists only to create JSON objects and json::value::array(std::initiali=
zer_list<...>) to create JSON arrays.

2) Initializer lists usually require *copies* of all elements. Hopefully th=
ere is some independent proposal to allow *moving* the values of an initial=
izer list. This is especially important for the JSON use case, as JSON valu=
es can be (deeply) nested.

3) Both of our libraries already have that feature, but I would think it is=
 also important for standardization that the specialization of UDTs is poss=
ible (how they are converted from and to JSON).

> 2. A serialization function to create a textual representation (called "J=
SON text" in [RFC7159]) from a std::json value that conforms to the JSON gr=
ammar [RFC7159, chapter 2-7].
>=20
> 3. A deserialization function (i.e., a parser) [RFC7159, chapter 9] to cr=
eate a std::json value from a JSON text.
>=20
> There are currently dozens of libraries [json.org] written in C or C++ so=
lving these aspects. However, it would be of great convenience to have JSON=
 be part of the C++ standard library. In particular, the wide use of JSON a=
s exchange format for structured data as well as to express simple configur=
ation data would could solve a lot of use cases within the C++ standard lib=
rary.
>=20
> I would be willing to draft a proposal based on the experience I made wit=
h my C++ JSON library [nlohmann/json]. Of course, I would be interested in =
your thoughts on this.

I think that the SAX-like approach we use in our library would be a very go=
od fit for a standardization proposal as it allows to decouple the differen=
t parts and if only a small sub-set of the possible event producers and con=
sumers are standardized, it allows the user to add and mix those parts with=
 other things like a non-JSON-conformant parser that accepts "relaxed JSON"=
 or binary formats like CBOR, etc.

It would even allow for different value classes, depending on the use case.=
 Some people might need the fastest value class possible and hence might wa=
nt something with special allocators to minimize the number of allocations =
(basically what RapidJSON does to achieve speed), some would need value cla=
sses which always sort the keys or allow multiple keys (which I personally =
don't like at all, but if it should be standardized, I am not the one to ma=
ke the call). It again allows a standardized value class for "most" users a=
nd still allows to combine all other parts (parsers, to_string, ...) to be =
re-used when the user decides to use another value class.

Thinking about the scope of what this proposal has to cover, I think this i=
s a *lot* of work. If you'd like help/cooperation on writing a proposal, I'=
m certainly interested.

Best regards,
Daniel

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7015CA97-5D3D-4DB0-BA67-62F768800B6E%40gmx.de.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20170301224620.89665620.88572.26232%40gmail.com.

.

> On 1 Mar 2017, at 23:46, Tony V E <tvaneerd@gmail.com> wrote:
>=20
> =E2=80=8E> 1) No magic, please. In your library you scan the initializer =
list to check if it *could* be an object, otherwise you turn it into an arr=
ay.
>=20
> Objects need names for each member, right? So the magic would check for s=
tring, value, string, value,... pattern? Yeah, that's a bit scary.=20

Our solution is nesting. Think: std::initializer_list<std::pair<std::string=
, std::json::value>>. Example:

std::json::value j =3D
{
  { "foo", 42 },
  { "bar", "Hello, world!" },
  { "baz",
    {
      { "nested", "object },
      { "key", true }
    }
  }
};

This worked quite well for us in practice.

> I once did a DSL that would allow something like
>=20
> Json json =3D { "x"k =3D 17, "y"k =3D { 1,2,3 }, "z"k =3D "hello"} ;
>=20
>=20
> =E2=80=8EYou can make it quite json-like (replace : with =3D, etc).

Your method sound more complicated and I'd be surprised if it is as efficie=
nt as the above way we have chosen. But it is interesting as it is closer t=
o the original JSON syntax and it potentially allows mixing objects and arr=
ays by providing overloads for different initializer lists? Not sure if the=
 latter would actually work.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/F6A262ED-E16E-4CAA-85A4-5C0DB1225F5A%40gmx.de.

.

------=_Part_1449_382409546.1488411587639
Content-Type: multipart/alternative;
 boundary="----=_Part_1450_326750177.1488411587639"

------=_Part_1450_326750177.1488411587639
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think I would be in flavor of keeping it in a 3rd party library.  There=
=20
are so many trade offs for different problem types and requirements.

Do you require an Input Iterator, Forward, or Random.  Each have a=20
cost/benefit.  With input you can pull straight from a network stream but=
=20
need to store the current string if the value is a string or a=20
number(majority of the time).  Forward lets you not have to buffer the=20
string internally or own more than a few iterators but precludes many data=
=20
sources that are common to json.  Random, similarly will allow for about=20
the same as forward plus being able to use the json file as storage for=20
many of the types or to do decoding on demand of the values(like numbers)=
=20
but is the most restrictive on file types.

Is decoding to a variant/map like structure the most cost effective, it=20
does allow for nice queries as some libraries have shown?  It will=20
definitely consume more memory than parsing direct to a previously known=20
c++ structure with a little bit of boiler plate to join the json member=20
names/types with the data structure.

Will there be more than one type?  Like a parse to variant/map and a sax=20
like version?  But what restrictions on source types?  Or with the variety=
=20
of needs/methods would be best not to put the std stamp on one of the nine=
=20
valid ways I listed.

On Wednesday, 1 March 2017 17:59:34 UTC-5, Daniel Frey wrote:
>
> > On 1 Mar 2017, at 23:46, Tony V E <tvan...@gmail.com <javascript:>>=20
> wrote:=20
> >=20
> > =E2=80=8E> 1) No magic, please. In your library you scan the initialize=
r list to=20
> check if it *could* be an object, otherwise you turn it into an array.=20
> >=20
> > Objects need names for each member, right? So the magic would check for=
=20
> string, value, string, value,... pattern? Yeah, that's a bit scary.=20
>
> Our solution is nesting. Think:=20
> std::initializer_list<std::pair<std::string, std::json::value>>. Example:=
=20
>
> std::json::value j =3D=20
> {=20
>   { "foo", 42 },=20
>   { "bar", "Hello, world!" },=20
>   { "baz",=20
>     {=20
>       { "nested", "object },=20
>       { "key", true }=20
>     }=20
>   }=20
> };=20
>
> This worked quite well for us in practice.=20
>
> > I once did a DSL that would allow something like=20
> >=20
> > Json json =3D { "x"k =3D 17, "y"k =3D { 1,2,3 }, "z"k =3D "hello"} ;=20
> >=20
> >=20
> > =E2=80=8EYou can make it quite json-like (replace : with =3D, etc).=20
>
> Your method sound more complicated and I'd be surprised if it is as=20
> efficient as the above way we have chosen. But it is interesting as it is=
=20
> closer to the original JSON syntax and it potentially allows mixing objec=
ts=20
> and arrays by providing overloads for different initializer lists? Not su=
re=20
> if the latter would actually work.=20
>
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/376772e0-7d86-4909-9695-3a232256d3e9%40isocpp.or=
g.

------=_Part_1450_326750177.1488411587639
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think I would be in flavor of keeping it in a 3rd party =
library. =C2=A0There are so many trade offs for different problem types and=
 requirements.<br><br>Do you require an Input Iterator, Forward, or Random.=
 =C2=A0Each have a cost/benefit. =C2=A0With input you can pull straight fro=
m a network stream but need to store the current string if the value is a s=
tring or a number(majority of the time). =C2=A0Forward lets you not have to=
 buffer the string internally or own more than a few iterators but preclude=
s many data sources that are common to json. =C2=A0Random, similarly will a=
llow for about the same as forward plus being able to use the json file as =
storage for many of the types or to do decoding on demand of the values(lik=
e numbers) but is the most restrictive on file types.<br><br>Is decoding to=
 a variant/map like structure the most cost effective, it does allow for ni=
ce queries as some libraries have shown? =C2=A0It will definitely consume m=
ore memory than parsing direct to a previously known c++ structure with a l=
ittle bit of boiler plate to join the json member names/types with the data=
 structure.<br><br>Will there be more than one type? =C2=A0Like a parse to =
variant/map and a sax like version? =C2=A0But what restrictions on source t=
ypes? =C2=A0Or with the variety of needs/methods would be best not to put t=
he std stamp on one of the nine valid ways I listed.<br><br>On Wednesday, 1=
 March 2017 17:59:34 UTC-5, Daniel Frey  wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">&gt; On 1 Mar 2017, at 23:46, Tony V E &lt;<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"IBiFKMTLCQAJ" rel=3D"no=
follow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;javascript:&#39;;return true;">tvan...@gmail.com</a=
>&gt; wrote:
<br>&gt;=20
<br>&gt; =E2=80=8E&gt; 1) No magic, please. In your library you scan the in=
itializer list to check if it *could* be an object, otherwise you turn it i=
nto an array.
<br>&gt;=20
<br>&gt; Objects need names for each member, right? So the magic would chec=
k for string, value, string, value,... pattern? Yeah, that&#39;s a bit scar=
y.=20
<br>
<br>Our solution is nesting. Think: std::initializer_list&lt;std::<wbr>pair=
&lt;std::string, std::json::value&gt;&gt;. Example:
<br>
<br>std::json::value j =3D
<br>{
<br>=C2=A0 { &quot;foo&quot;, 42 },
<br>=C2=A0 { &quot;bar&quot;, &quot;Hello, world!&quot; },
<br>=C2=A0 { &quot;baz&quot;,
<br>=C2=A0 =C2=A0 {
<br>=C2=A0 =C2=A0 =C2=A0 { &quot;nested&quot;, &quot;object },
<br>=C2=A0 =C2=A0 =C2=A0 { &quot;key&quot;, true }
<br>=C2=A0 =C2=A0 }
<br>=C2=A0 }
<br>};
<br>
<br>This worked quite well for us in practice.
<br>
<br>&gt; I once did a DSL that would allow something like
<br>&gt;=20
<br>&gt; Json json =3D { &quot;x&quot;k =3D 17, &quot;y&quot;k =3D { 1,2,3 =
}, &quot;z&quot;k =3D &quot;hello&quot;} ;
<br>&gt;=20
<br>&gt;=20
<br>&gt; =E2=80=8EYou can make it quite json-like (replace : with =3D, etc)=
..
<br>
<br>Your method sound more complicated and I&#39;d be surprised if it is as=
 efficient as the above way we have chosen. But it is interesting as it is =
closer to the original JSON syntax and it potentially allows mixing objects=
 and arrays by providing overloads for different initializer lists? Not sur=
e if the latter would actually work.
<br>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/376772e0-7d86-4909-9695-3a232256d3e9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/376772e0-7d86-4909-9695-3a232256d3e9=
%40isocpp.org</a>.<br />

------=_Part_1450_326750177.1488411587639--

------=_Part_1449_382409546.1488411587639--

.

--001a114fcd10da0a360549b4c818
Content-Type: text/plain; charset=UTF-8

On Wed, Mar 1, 2017 at 5:39 PM, <darrell.wright@gmail.com> wrote:

> I think I would be in flavor of keeping it in a 3rd party library.  There
> are so many trade offs for different problem types and requirements.
>
> Do you require an Input Iterator, Forward, or Random.  Each have a
> cost/benefit.  With input you can pull straight from a network stream but
> need to store the current string if the value is a string or a
> number(majority of the time).  Forward lets you not have to buffer the
> string internally or own more than a few iterators but precludes many data
> sources that are common to json.  Random, similarly will allow for about
> the same as forward plus being able to use the json file as storage for
> many of the types or to do decoding on demand of the values(like numbers)
> but is the most restrictive on file types.
>
> Is decoding to a variant/map like structure the most cost effective, it
> does allow for nice queries as some libraries have shown?  It will
> definitely consume more memory than parsing direct to a previously known
> c++ structure with a little bit of boiler plate to join the json member
> names/types with the data structure.
>
> Will there be more than one type?  Like a parse to variant/map and a sax
> like version?  But what restrictions on source types?  Or with the variety
> of needs/methods would be best not to put the std stamp on one of the nine
> valid ways I listed.
>

As someone who uses their own vector, string, span, and other classes I do
really sympathize with the desire to have a fully configurable library
solution with infinite flexibility. But--

I don't think that we have to have a perfect solution in the standard
library in order to have a useful version that we can point to and say,
hey, here's the easy built-in solution for json parsing. If you don't like
the std version you can still use an external library. Nothing we propose
is ever perfect. What it needs to be is useful for a large enough audience.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeS%3D6yfRWW1QLFjdCfdFpiX54Fw2df%3Dh5ejaxE2QamHF-g%40mail.gmail.com.

--001a114fcd10da0a360549b4c818
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Mar 1, 2017 at 5:39 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:darrel=
l.wright@gmail.com" target=3D"_blank">darrell.wright@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr">I think I would be in flavor of keeping it in a 3rd party library.=C2=
=A0 There are so many trade offs for different problem types and requiremen=
ts.<br><br>Do you require an Input Iterator, Forward, or Random.=C2=A0 Each=
 have a cost/benefit.=C2=A0 With input you can pull straight from a network=
 stream but need to store the current string if the value is a string or a =
number(majority of the time).=C2=A0 Forward lets you not have to buffer the=
 string internally or own more than a few iterators but precludes many data=
 sources that are common to json.=C2=A0 Random, similarly will allow for ab=
out the same as forward plus being able to use the json file as storage for=
 many of the types or to do decoding on demand of the values(like numbers) =
but is the most restrictive on file types.<br><br>Is decoding to a variant/=
map like structure the most cost effective, it does allow for nice queries =
as some libraries have shown?=C2=A0 It will definitely consume more memory =
than parsing direct to a previously known c++ structure with a little bit o=
f boiler plate to join the json member names/types with the data structure.=
<br><br>Will there be more than one type?=C2=A0 Like a parse to variant/map=
 and a sax like version?=C2=A0 But what restrictions on source types?=C2=A0=
 Or with the variety of needs/methods would be best not to put the std stam=
p on one of the nine valid ways I listed.<br></div></blockquote><div><br></=
div>As someone who uses their own vector, string, span, and other classes I=
 do really sympathize with the desire to have a fully configurable library =
solution with infinite flexibility. But--<div><br></div><div>I don&#39;t th=
ink that we have to have a perfect solution in the standard library in orde=
r to have a useful version that we can point to and say, hey, here&#39;s th=
e easy built-in solution for json parsing. If you don&#39;t like the std ve=
rsion you can still use an external library. Nothing we propose is ever per=
fect. What it needs to be is useful for a large enough audience.</div></div=
></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeS%3D6yfRWW1QLFjdCfdFpiX54Fw2=
df%3Dh5ejaxE2QamHF-g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeS%=
3D6yfRWW1QLFjdCfdFpiX54Fw2df%3Dh5ejaxE2QamHF-g%40mail.gmail.com</a>.<br />

--001a114fcd10da0a360549b4c818--

.

On 3/1/17 4:48 PM, Brittany Friedman wrote:

> As someone who uses their own vector, string, span, and other classes I
> do really sympathize with the desire to have a fully configurable
> library solution with infinite flexibility. But--
>
> I don't think that we have to have a perfect solution in the standard
> library in order to have a useful version that we can point to and say,
> hey, here's the easy built-in solution for json parsing. If you don't
> like the std version you can still use an external library. Nothing we
> propose is ever perfect. What it needs to be is useful for a large
> enough audience.

I really think that the standard contains too many "big".  This would be
a perfect example.  I know it's not big now, but by the time it got
massaged by the/a committee to try to placate differing trade offs, use
cases, etc. , it would be.  I think the committee would spend it's time
more wisely by focusing more on "core" type libraries.

Robert Ramey

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3d41a80d-122e-28b9-4815-00b290eb397d%40rrsd.com.

.

------=_Part_4_1625927498.1488418260784
Content-Type: multipart/alternative;
 boundary="----=_Part_5_1667183138.1488418260784"

------=_Part_5_1667183138.1488418260784
Content-Type: text/plain; charset=UTF-8

I am too naive of the ecosystem to know what would be the balance?  I
suspect a callback based(SAX like) parser would use the least
resources(cpu/memory) and requiring only Input Iterators would be the most
flexable in data sources but at the cost of a buffer to hold the current
value if it is a string or a number.   That would be a cost in a
non-callback parser too, but not with a Forward Iterator or Random as one
could store pointers(But then the source has to remain open).  The penalty
could be you might run out of memory on some strings.

On Wednesday, 1 March 2017 19:48:17 UTC-5, Brent Friedman wrote:
>
> On Wed, Mar 1, 2017 at 5:39 PM, <darrell...@gmail.com <javascript:>>
> wrote:
>
>> I think I would be in flavor of keeping it in a 3rd party library.  There
>> are so many trade offs for different problem types and requirements.
>>
>> Do you require an Input Iterator, Forward, or Random.  Each have a
>> cost/benefit.  With input you can pull straight from a network stream but
>> need to store the current string if the value is a string or a
>> number(majority of the time).  Forward lets you not have to buffer the
>> string internally or own more than a few iterators but precludes many data
>> sources that are common to json.  Random, similarly will allow for about
>> the same as forward plus being able to use the json file as storage for
>> many of the types or to do decoding on demand of the values(like numbers)
>> but is the most restrictive on file types.
>>
>> Is decoding to a variant/map like structure the most cost effective, it
>> does allow for nice queries as some libraries have shown?  It will
>> definitely consume more memory than parsing direct to a previously known
>> c++ structure with a little bit of boiler plate to join the json member
>> names/types with the data structure.
>>
>> Will there be more than one type?  Like a parse to variant/map and a sax
>> like version?  But what restrictions on source types?  Or with the variety
>> of needs/methods would be best not to put the std stamp on one of the nine
>> valid ways I listed.
>>
>
> As someone who uses their own vector, string, span, and other classes I do
> really sympathize with the desire to have a fully configurable library
> solution with infinite flexibility. But--
>
> I don't think that we have to have a perfect solution in the standard
> library in order to have a useful version that we can point to and say,
> hey, here's the easy built-in solution for json parsing. If you don't like
> the std version you can still use an external library. Nothing we propose
> is ever perfect. What it needs to be is useful for a large enough audience.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c2483a8e-b904-4fc2-adda-c544b9050ebb%40isocpp.org.

------=_Part_5_1667183138.1488418260784
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I am too naive of the ecosystem to know what would be the =
balance? =C2=A0I suspect a callback based(SAX like) parser would use the le=
ast resources(cpu/memory) and requiring only Input Iterators would be the m=
ost flexable in data sources but at the cost of a buffer to hold the curren=
t value if it is a string or a number. =C2=A0 That would be a cost in a non=
-callback parser too, but not with a Forward Iterator or Random as one coul=
d store pointers(But then the source has to remain open). =C2=A0The penalty=
 could be you might run out of memory on some strings.<br><br>On Wednesday,=
 1 March 2017 19:48:17 UTC-5, Brent Friedman  wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On W=
ed, Mar 1, 2017 at 5:39 PM,  <span dir=3D"ltr">&lt;<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"f_dSBrPRCQAJ" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"th=
is.href=3D&#39;javascript:&#39;;return true;">darrell...@gmail.com</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">I think I would be in flavor of keeping it in a 3rd party library.=
=C2=A0 There are so many trade offs for different problem types and require=
ments.<br><br>Do you require an Input Iterator, Forward, or Random.=C2=A0 E=
ach have a cost/benefit.=C2=A0 With input you can pull straight from a netw=
ork stream but need to store the current string if the value is a string or=
 a number(majority of the time).=C2=A0 Forward lets you not have to buffer =
the string internally or own more than a few iterators but precludes many d=
ata sources that are common to json.=C2=A0 Random, similarly will allow for=
 about the same as forward plus being able to use the json file as storage =
for many of the types or to do decoding on demand of the values(like number=
s) but is the most restrictive on file types.<br><br>Is decoding to a varia=
nt/map like structure the most cost effective, it does allow for nice queri=
es as some libraries have shown?=C2=A0 It will definitely consume more memo=
ry than parsing direct to a previously known c++ structure with a little bi=
t of boiler plate to join the json member names/types with the data structu=
re.<br><br>Will there be more than one type?=C2=A0 Like a parse to variant/=
map and a sax like version?=C2=A0 But what restrictions on source types?=C2=
=A0 Or with the variety of needs/methods would be best not to put the std s=
tamp on one of the nine valid ways I listed.<br></div></blockquote><div><br=
></div>As someone who uses their own vector, string, span, and other classe=
s I do really sympathize with the desire to have a fully configurable libra=
ry solution with infinite flexibility. But--<div><br></div><div>I don&#39;t=
 think that we have to have a perfect solution in the standard library in o=
rder to have a useful version that we can point to and say, hey, here&#39;s=
 the easy built-in solution for json parsing. If you don&#39;t like the std=
 version you can still use an external library. Nothing we propose is ever =
perfect. What it needs to be is useful for a large enough audience.</div></=
div></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c2483a8e-b904-4fc2-adda-c544b9050ebb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c2483a8e-b904-4fc2-adda-c544b9050ebb=
%40isocpp.org</a>.<br />

------=_Part_5_1667183138.1488418260784--

------=_Part_4_1625927498.1488418260784--

.

> On Wed, Mar 1, 2017 at 5:39 PM, <darrell.wright@gmail.com> wrote:
> I think I would be in flavor of keeping it in a 3rd party library.  There=
 are so many trade offs for different problem types and requirements.
>=20
> Do you require an Input Iterator, Forward, or Random.  Each have a cost/b=
enefit.  With input you can pull straight from a network stream but need to=
 store the current string if the value is a string or a number(majority of =
the time).  Forward lets you not have to buffer the string internally or ow=
n more than a few iterators but precludes many data sources that are common=
 to json.  Random, similarly will allow for about the same as forward plus =
being able to use the json file as storage for many of the types or to do d=
ecoding on demand of the values(like numbers) but is the most restrictive o=
n file types.
>=20
> Is decoding to a variant/map like structure the most cost effective, it d=
oes allow for nice queries as some libraries have shown?  It will definitel=
y consume more memory than parsing direct to a previously known c++ structu=
re with a little bit of boiler plate to join the json member names/types wi=
th the data structure.
>=20
> Will there be more than one type?  Like a parse to variant/map and a sax =
like version?  But what restrictions on source types?  Or with the variety =
of needs/methods would be best not to put the std stamp on one of the nine =
valid ways I listed.

With a SAX-like approach, you could have independent building blocks. Write=
 a parser that takes Input Iterators as a SAX producer. Write another parse=
r that takes Random Access Iterators, And another parser that read a file w=
ith mmap. Or write a SAX producer for your own binary format. Or for an nlo=
hmann::json instance.

And you don't have to put a "std" stamp on all of these, but the really gen=
eric ones that benefit the majority of users. But with the right SAX interf=
ace, you are still open for extensions. From the slides I linked, this is o=
ur SAX interface:

         struct ...
         {
            void null();

            void boolean( const bool );

            void number( const std::int64_t );
            void number( const std::uint64_t );
            void number( const double );

            void string( std::string && );
            void string( const std::string & );

            // array
            void begin_array();
            void element();
            void end_array();

            // object
            void begin_object();
            void key( std::string && );
            void key( const std::string & );
            void member();
            void end_object();
         };

In the slides, I also show an example of a SAX producer (e.g., a parser) an=
d a SAX consumer (e.g., stringify, pretty_print). Obviously, the above stil=
l has a lot of potential for discussion, mainly because of the question whi=
ch overloads should exist for numeric types and even for string/key (think =
std::string_view, ...).

<http://www.wilkening-online.de/programmieren/c++-user-treffen-aachen/2016_=
11_10/taocpp-json_DanielFrey.pdf>

> On 2 Mar 2017, at 01:48, Brittany Friedman <fourthgeek@gmail.com> wrote:
>=20
> As someone who uses their own vector, string, span, and other classes I d=
o really sympathize with the desire to have a fully configurable library so=
lution with infinite flexibility. But--

> I don't think that we have to have a perfect solution in the standard lib=
rary in order to have a useful version that we can point to and say, hey, h=
ere's the easy built-in solution for json parsing. If you don't like the st=
d version you can still use an external library. Nothing we propose is ever=
 perfect. What it needs to be is useful for a large enough audience.

Also here, the SAX interface could benefit you greatly. Have your own value=
 type to store the JSON values, but re-use a JSON Schema validator, parsers=
, stringify/prettify, support for binary formats, etc. For each value type =
to be useable with the rest of the ecosystem, your only need two SAX adapte=
rs: one SAX producer, one SAX consumer. In our library, those are

SAX producer: <https://github.com/taocpp/json/blob/master/include/tao/json/=
sax/from_value.hh> (137 lines for two version b/c move-semantics)
SAX consumer: <https://github.com/taocpp/json/blob/master/include/tao/json/=
sax/to_value.hh> (118 lines)

For Niels' library, those adapters look like:

SAX producer: <https://github.com/taocpp/json/blob/master/contrib/nlohmann/=
from_value.hh> (70 lines)
SAX consumer: <https://github.com/taocpp/json/blob/master/contrib/nlohmann/=
to_value.hh> (117 lines)

The stringify/prettify SAX consumers are also a good example how they can b=
e both simple and powerful, while also being quite efficient.

Stringify: <https://github.com/taocpp/json/blob/master/include/tao/json/sax=
/to_stream.hh> (137 lines)
Prettify: <https://github.com/taocpp/json/blob/master/include/tao/json/sax/=
to_pretty_stream.hh> (152 lines)

IMHO the above shows the power of the SAX-like approach. You could still ha=
ve 3rd-party libraries which implement better/different parsers, other libr=
aries implement binary formats, and yet some other libraries might concentr=
ate on providing a better/different value class (e.g. RapidJSON style for t=
hose that need pure speed above all else). Each of those libraries could co=
ncentrate one exactly *one* problem/solution and you can easily combine all=
 of these through a standardized SAX interface. RapidJSON, as an example, a=
lso uses a SAX approach, but has a slightly different interface than we hav=
e. Even if we could *only* standardize the SAX interface for JSON, that wou=
ld be an extremly helpful step for everyone.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5C6CBEC7-E409-4676-9144-3D970E66564A%40gmx.de.

.

------=_Part_29_2136913956.1488433967114
Content-Type: multipart/alternative;
 boundary="----=_Part_30_1790363052.1488433967114"

------=_Part_30_1790363052.1488433967114
Content-Type: text/plain; charset=UTF-8

Personally, I've always disliked the SAX approach, where reads are forced
on you. I much prefer the reader approach, where you read at whatever pace
you like. It's rather more like an iterator in that respect.

Such an approach makes it very easy on the code doing the reading, since it
can do things like pass the reader to other code to interpret those
parameters. Doing this with a SAX interface requires basically writing a
state machine into a type. And why would you want to encourage that kind of
coding?

You can get the same effects of a SAX interface with a Reader-like
approach. Rather than standardizing the struct that interprets the JSON,
you standardize the Reader as a Concept. A Reader has functions to read the
next datum, tell you want that datum is, etc. And you can standardize a
similar Writer Concept, which has interfaces for writing the data.

So you get all of the benefits you outline, but without the huge detriment
of using SAX to process stuff.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b4dc6d1f-821b-43e9-ac0d-e7d2dc17c4f5%40isocpp.org.

------=_Part_30_1790363052.1488433967114
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Personally, I&#39;ve always disliked the SAX approach, whe=
re reads are forced on you. I much prefer the reader approach, where you re=
ad at whatever pace you like. It&#39;s rather more like an iterator in that=
 respect.<br><br>Such an approach makes it very easy on the code doing the =
reading, since it can do things like pass the reader to other code to inter=
pret those parameters. Doing this with a SAX interface requires basically w=
riting a state machine into a type. And why would you want to encourage tha=
t kind of coding?<br><br>You can get the same effects of a SAX interface wi=
th a Reader-like approach. Rather than standardizing the struct that interp=
rets the JSON, you standardize the Reader as a Concept. A Reader has functi=
ons to read the next datum, tell you want that datum is, etc. And you can s=
tandardize a similar Writer Concept, which has interfaces for writing the d=
ata.<br><br>So you get all of the benefits you outline, but without the hug=
e detriment of using SAX to process stuff.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b4dc6d1f-821b-43e9-ac0d-e7d2dc17c4f5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b4dc6d1f-821b-43e9-ac0d-e7d2dc17c4f5=
%40isocpp.org</a>.<br />

------=_Part_30_1790363052.1488433967114--

------=_Part_29_2136913956.1488433967114--

.

Em quarta-feira, 1 de mar=C3=A7o de 2017, =C3=A0s 13:41:59 PST, Nicol Bolas=
 escreveu:
> 3) For strings, you need to make a determination if the JSON object shoul=
d
> own the string or not. For JSON objects parsed from in-memory strings,
> users might want to have it store `string_view`s that reference the strin=
g
> directly rather than `string`.

Zero-copy is not possible with JSON strings, since they can be escaped and =
the=20
parser needs to unescape it. There are certain characters that must always =
be=20
escaped in JSON text.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9422748.46uWQKsSDl%40tjmaciei-mobl1.

.

--001a113fb93047d6af0549ba5db8
Content-Type: text/plain; charset=UTF-8

On Wed, Mar 1, 2017 at 11:25 AM, Niels Lohmann <mail@nlohmann.me> wrote:

> Hi there,
>
> I am wondering whether JSON [RFC7159] support would be a helpful extension
> to the C++ standard library
>

Yes please. I'll leave it to y'all to figure out which existing library or
libraries should go into the exact proposal. Please do try to invent as
little as possible when writing the proposal: stay to behavior that's been
vetted by existing users or behavior that's been requested in bug reports
for existing libraries.

Thanks,
Jeffrey (LEWG chair)

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXm8NegC_J3_JM-1joCrRfiJEiOpr4zJDp1J3vvRqEzbeA%40mail.gmail.com.

--001a113fb93047d6af0549ba5db8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Mar 1, 2017 at 11:25 AM, Niels Lohmann <span dir=3D"ltr">&lt;<a href=3D=
"mailto:mail@nlohmann.me" target=3D"_blank" class=3D"cremed">mail@nlohmann.=
me</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi there,<br>
<br>
I am wondering whether JSON [RFC7159] support would be a helpful extension =
to the C++ standard library <br></blockquote><div><br></div><div>Yes please=
.. I&#39;ll leave it to y&#39;all to figure out which existing library or li=
braries should go into the exact proposal. Please do try to invent as littl=
e as possible when writing the proposal: stay to behavior that&#39;s been v=
etted by existing users or behavior that&#39;s been requested in bug report=
s for existing libraries.</div><div><br></div><div>Thanks,</div><div>Jeffre=
y (LEWG chair)</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh-dXm8NegC_J3_JM-1joCrRfiJEiOpr4zJ=
Dp1J3vvRqEzbeA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXm8NegC_J3_=
JM-1joCrRfiJEiOpr4zJDp1J3vvRqEzbeA%40mail.gmail.com</a>.<br />

--001a113fb93047d6af0549ba5db8--

.

Are there any limits on JSON strings?

If there ain't, wouldn't a method like

void string(json_string_iterator& begin, const json_string_iterator& end);

allow the processing of strings larger than the available memory (which might
be quite limited).

I think the same questuion is valid for number as well.

/MF

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20170302075103.GA8714%40noemi.

.

Em quarta-feira, 1 de mar=C3=A7o de 2017, =C3=A0s 21:52:46 PST, Nicol Bolas=
 escreveu:
> Personally, I've always disliked the SAX approach, where reads are forced
> on you. I much prefer the reader approach, where you read at whatever pac=
e
> you like.

That's called the StAX approach. https://en.wikipedia.org/wiki/StAX

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3116144.353StRvu1A%40tjmaciei-mobl1.

.

------=_Part_124_1239712379.1488446161272
Content-Type: multipart/alternative;
 boundary="----=_Part_125_1359530378.1488446161272"

------=_Part_125_1359530378.1488446161272
Content-Type: text/plain; charset=UTF-8

Op woensdag 1 maart 2017 22:25:33 UTC+1 schreef Niels Lohmann:
>
> There are currently dozens of libraries [json.org] written in C or C++
> solving these aspects. However, it would be of great convenience to have
> JSON be part of the C++ standard library. In particular, the wide use of
> JSON as exchange format for structured data as well as to express simple
> configuration data would could solve a lot of use cases within the C++
> standard library.
>

What's the advantage of a standard-library over a third-party library (in
this case), apart from not being a dependency?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/de5c0492-c210-4955-964f-e33d2ddafe86%40isocpp.org.

------=_Part_125_1359530378.1488446161272
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Op woensdag 1 maart 2017 22:25:33 UTC+1 schreef Niels Lohm=
ann:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">There are currently dozens=
 of libraries [<a href=3D"http://json.org" target=3D"_blank" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2=
F%2Fjson.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH6GHLj2q4_Ao1l2Xd4-wR9=
sDnARA&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com=
/url?q\x3dhttp%3A%2F%2Fjson.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH6G=
HLj2q4_Ao1l2Xd4-wR9sDnARA&#39;;return true;">json.org</a>] written in C or =
C++ solving these aspects. However, it would be of great convenience to hav=
e JSON be part of the C++ standard library. In particular, the wide use of =
JSON as exchange format for structured data as well as to express simple co=
nfiguration data would could solve a lot of use cases within the C++ standa=
rd library.
<br></blockquote><div><br></div><div>What&#39;s the advantage of a standard=
-library over a third-party library (in this case), apart from not being a =
dependency?=C2=A0</div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/de5c0492-c210-4955-964f-e33d2ddafe86%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/de5c0492-c210-4955-964f-e33d2ddafe86=
%40isocpp.org</a>.<br />

------=_Part_125_1359530378.1488446161272--

------=_Part_124_1239712379.1488446161272--

.

> On 2 Mar 2017, at 08:11, Thiago Macieira <thiago@macieira.org> wrote:
>=20
> Em quarta-feira, 1 de mar=C3=A7o de 2017, =C3=A0s 13:41:59 PST, Nicol Bol=
as escreveu:
>> 3) For strings, you need to make a determination if the JSON object shou=
ld
>> own the string or not. For JSON objects parsed from in-memory strings,
>> users might want to have it store `string_view`s that reference the stri=
ng
>> directly rather than `string`.
>=20
> Zero-copy is not possible with JSON strings, since they can be escaped an=
d the=20
> parser needs to unescape it. There are certain characters that must alway=
s be=20
> escaped in JSON text.

That is not necessarily true. If the source is a binary protocol or you cre=
ate a JSON value programmatically, the string may very well exist in raw fo=
rm already. Only the JSON string representation requires escaping/unescapin=
g, but not everyone will need that.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2054ACAD-6F34-4A53-80F0-C6ACE8BCBACA%40gmx.de.

.

> On 2 Mar 2017, at 10:16, olaf@join.cc wrote:
>=20
> Op woensdag 1 maart 2017 22:25:33 UTC+1 schreef Niels Lohmann:
> There are currently dozens of libraries [json.org] written in C or C++ so=
lving these aspects. However, it would be of great convenience to have JSON=
 be part of the C++ standard library. In particular, the wide use of JSON a=
s exchange format for structured data as well as to express simple configur=
ation data would could solve a lot of use cases within the C++ standard lib=
rary.=20
>=20
> What's the advantage of a standard-library over a third-party library (in=
 this case), apart from not being a dependency?=20

As I wrote in more detail in another mail already, a standard SAX-like inte=
rface would allow different libraries or parts to be mixed by the user as n=
eeded. With existing libraries it is often the choice between either/or.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/35A800A3-2DBC-4E5C-A1C3-AFAA35088C47%40gmx.de.

.

On 3/2/17 7:51 AM, Daniel Frey wrote:
>> On 2 Mar 2017, at 10:16, olaf@join.cc wrote:
>>
>> Op woensdag 1 maart 2017 22:25:33 UTC+1 schreef Niels Lohmann:
>> There are currently dozens of libraries [json.org] written in C or C++ s=
olving these aspects. However, it would be of great convenience to have JSO=
N be part of the C++ standard library. In particular, the wide use of JSON =
as exchange format for structured data as well as to express simple configu=
ration data would could solve a lot of use cases within the C++ standard li=
brary.
>>
>> What's the advantage of a standard-library over a third-party library (i=
n this case), apart from not being a dependency?
>
> As I wrote in more detail in another mail already, a standard SAX-like in=
terfacewould allow different libraries or parts to be mixed by the user as=
=20
needed. With existing libraries it is often the choice between either/or.
>

That's not the question. The questions are -

a) what's the advantage of having something like this in the standard vs=20
the current situation where one imports code from some other place?

b) adding it to the standard would require adding features, reconciling=20
differing points of view, a ton of work to code the spec, and time taken=20
from other (more important/urgent) tasks.  How would this benefit the=20
C++ community?

c) Why do we all have to agree on what a json library (or any non core)=20
library should look like?  What's the point of that?

d) what value are we adding here - as opposed just the current situation?

 > As I wrote in more detail in another mail already, a standard=20
SAX-like interface would allow different libraries or parts to be mixed=20
by the user as needed. With existing libraries it is often the choice=20
between either/or.

So you want to design/create a better version than the "dozens" of JSON=20
libraries "out there".  Why not just do it?  Why do you need to involve=20
the standards committee in this?

Robert Ramey

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/669d1885-55fc-9d89-837d-f184e231c7f8%40rrsd.com.

.

> On 2 Mar 2017, at 17:24, Robert Ramey <ramey@rrsd.com> wrote:
>=20
> So you want to design/create a better version than the "dozens" of JSON l=
ibraries "out there".  Why not just do it?  Why do you need to involve the =
standards committee in this?

a) I'm not the one who started the thread here, I just state my opinion and=
 offer to help *if* some people want to work on standardizing something. Fo=
r the record, Niels started the thread after being encouraged by STL on Red=
dit (and I think STL is not the only one who thinks that more larger librar=
ies should be standardized).

b) I already work on such a library. I will continue to do so and if nothin=
g gets standardized, that is also fine by me.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/BB30E36D-3C82-4FAA-A435-DFEE08E47A2D%40gmx.de.

.

On 3/2/17 8:38 AM, Daniel Frey wrote:
>> On 2 Mar 2017, at 17:24, Robert Ramey <ramey@rrsd.com> wrote:
>>
>> So you want to design/create a better version than the "dozens" of JSON libraries "out there".  Why not just do it?  Why do you need to involve the standards committee in this?
>
> a) I'm not the one who started the thread here, I just state my opinion and offer to help *if* some people want to work on standardizing something.

For the record, Niels started the thread after being encouraged by STL
on Reddit (and I think STL is not the only one who thinks that more
larger libraries should be standardized).

Hmmm - I'll have to talk to him about that!

>
> b) I already work on such a library. I will continue to do so and if nothing gets standardized, that is also fine by me.
>

I certainly don't want to discourage anyone from working on a library.
I just question that the goal of getting such a library in the standard
is the best one.  The standards process is a long distraction for
something like this.  It adds years to the effort.  I think it's more
productive for authors of such libraries to have a goal of getting their
library used by the largest number of users.  If the standards committee
want's to adopt some particular library as "standardization of existing
practice" fine.  But to aim at standardization as a means to making the
library widely used I think puts the cart before horse.

Of course I'm not really talking about the JSON library here - it could
have been any one of a number of them.  It just turns out that this is
perfect example of where I think the standards process goes wrong.

Robert Ramey

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/65123d63-7231-e9c3-19d9-2d8e52539a7a%40rrsd.com.

.

------=_Part_312_1322283868.1488474145672
Content-Type: multipart/alternative;
 boundary="----=_Part_313_446205669.1488474145672"

------=_Part_313_446205669.1488474145672
Content-Type: text/plain; charset=UTF-8

On Thursday, March 2, 2017 at 11:28:23 AM UTC-5, Robert Ramey wrote:
>
> On 3/2/17 7:51 AM, Daniel Frey wrote:
> >> On 2 Mar 2017, at 10:16, olaf wrote:
> >>
> >> Op woensdag 1 maart 2017 22:25:33 UTC+1 schreef Niels Lohmann:
> >> There are currently dozens of libraries [json.org] written in C or C++
> solving these aspects. However, it would be of great convenience to have
> JSON be part of the C++ standard library. In particular, the wide use of
> JSON as exchange format for structured data as well as to express simple
> configuration data would could solve a lot of use cases within the C++
> standard library.
> >>
> >> What's the advantage of a standard-library over a third-party library
> (in this case), apart from not being a dependency?
> >
> > As I wrote in more detail in another mail already, a standard SAX-like
> interfacewould allow different libraries or parts to be mixed by the user
> as
> needed. With existing libraries it is often the choice between either/or.
> >
>
> That's not the question. The questions are -
>
> a) what's the advantage of having something like this in the standard vs
> the current situation where one imports code from some other place?
>

What's the advantage of having *anything* in the standard library outside
of "Table 19: C++ headers for freestanding implementations"? After all, the
other stuff could just be a library you download. So why put it in the
standard?

Because people need this stuff.

People need networking. People need containers. People need filesystem
access. People need to spawn threads and deal with inter-thread
communication. People need to match strings against regular expressions.
And so on.

Having a standard way to do this stuff facilitates interoperability and
allows people to use the language without having to rely on so many
external libraries.

It is not unreasonable for the standard library to provide a tool that
programmers commonly use to get things done.

b) adding it to the standard would require adding features, reconciling
> differing points of view, a ton of work to code the spec, and time taken
> from other (more important/urgent) tasks.  How would this benefit the
> C++ community?
>

See above.


> c) Why do we all have to agree on what a json library (or any non core)
> library should look like?  What's the point of that?
>

What is "non core"? How do you define what is and is not "core"?

d) what value are we adding here - as opposed just the current situation?
>

That users can parse JSON without having to download a library. That users
can have and rely on this functionality without having to fish around among
dozens of different solutions of various quality, functionality, and
behavior.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/319ffcbe-1a68-4d94-aebe-a364cdc5cebc%40isocpp.org.

------=_Part_313_446205669.1488474145672
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 2, 2017 at 11:28:23 AM UTC-5, Robert Ra=
mey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 3/2/17 7:51 AM, D=
aniel Frey wrote:
<br>&gt;&gt; On 2 Mar 2017, at 10:16, olaf wrote:
<br>&gt;&gt;
<br>&gt;&gt; Op woensdag 1 maart 2017 22:25:33 UTC+1 schreef Niels Lohmann:
<br>&gt;&gt; There are currently dozens of libraries [<a href=3D"http://jso=
n.org" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;h=
ttp://www.google.com/url?q\x3dhttp%3A%2F%2Fjson.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNH6GHLj2q4_Ao1l2Xd4-wR9sDnARA&#39;;return true;" onclick=3D=
"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fjson.org\x26s=
a\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH6GHLj2q4_Ao1l2Xd4-wR9sDnARA&#39;;retur=
n true;">json.org</a>] written in C or C++ solving these aspects. However, =
it would be of great convenience to have JSON be part of the C++ standard l=
ibrary. In particular, the wide use of JSON as exchange format for structur=
ed data as well as to express simple configuration data would could solve a=
 lot of use cases within the C++ standard library.
<br>&gt;&gt;
<br>&gt;&gt; What&#39;s the advantage of a standard-library over a third-pa=
rty library (in this case), apart from not being a dependency?
<br>&gt;
<br>&gt; As I wrote in more detail in another mail already, a standard SAX-=
like interfacewould allow different libraries or parts to be mixed by the u=
ser as=20
<br>needed. With existing libraries it is often the choice between either/o=
r.
<br>&gt;
<br>
<br>That&#39;s not the question. The questions are -
<br>
<br>a) what&#39;s the advantage of having something like this in the standa=
rd vs=20
<br>the current situation where one imports code from some other place?
<br></blockquote><div><br>What&#39;s the advantage of having <i>anything</i=
> in the standard library outside of &quot;Table 19: C++ headers for freest=
anding implementations&quot;? After all, the other stuff could just be a li=
brary you download. So why put it in the standard?<br><br>Because people ne=
ed this stuff.<br><br>People need networking. People need containers. Peopl=
e need filesystem access. People need to spawn threads and deal with inter-=
thread communication. People need to match strings against regular expressi=
ons. And so on.<br><br>Having a standard way to do this stuff facilitates i=
nteroperability and allows people to use the language without having to rel=
y on so many external libraries.<br><br>It is not unreasonable for the stan=
dard library to provide a tool that programmers commonly use to get things =
done.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
b) adding it to the standard would require adding features, reconciling=20
<br>differing points of view, a ton of work to code the spec, and time take=
n=20
<br>from other (more important/urgent) tasks. =C2=A0How would this benefit =
the=20
<br>C++ community?
<br></blockquote><div><br>See above.<br>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">
c) Why do we all have to agree on what a json library (or any non core)=20
<br>library should look like? =C2=A0What&#39;s the point of that?
<br></blockquote><div><br>What is &quot;non core&quot;? How do you define w=
hat is and is not &quot;core&quot;?<br><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">
d) what value are we adding here - as opposed just the current situation?
<br></blockquote><div><br>That users can parse JSON without having to downl=
oad a library. That users can have and rely on this functionality without h=
aving to fish around among dozens of different solutions of various quality=
, functionality, and behavior.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/319ffcbe-1a68-4d94-aebe-a364cdc5cebc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/319ffcbe-1a68-4d94-aebe-a364cdc5cebc=
%40isocpp.org</a>.<br />

------=_Part_313_446205669.1488474145672--

------=_Part_312_1322283868.1488474145672--

.

For some reason my mail client (MacOS Mail) screws up the quoting levels - =
sorry.

> On 2 Mar 2017, at 17:46, Nicol Bolas <jmckesson@gmail.com> wrote:
>=20
> On Thursday, March 2, 2017 at 1:07:29 AM UTC-5, Daniel Frey wrote:
> > On 2 Mar 2017, at 06:52, Nicol Bolas <jmck...@gmail.com> wrote:=20
> >=20
> > Personally, I've always disliked the SAX approach, where reads are forc=
ed on you. I much prefer the reader approach, where you read at whatever pa=
ce you like. It's rather more like an iterator in that respect.=20
> >=20
> > Such an approach makes it very easy on the code doing the reading, sinc=
e it can do things like pass the reader to other code to interpret those pa=
rameters. Doing this with a SAX interface requires basically writing a stat=
e machine into a type. And why would you want to encourage that kind of cod=
ing?=20
> >=20
> > You can get the same effects of a SAX interface with a Reader-like appr=
oach. Rather than standardizing the struct that interprets the JSON, you st=
andardize the Reader as a Concept. A Reader has functions to read the next =
datum, tell you want that datum is, etc. And you can standardize a similar =
Writer Concept, which has interfaces for writing the data.=20
> >=20
> > So you get all of the benefits you outline, but without the huge detrim=
ent of using SAX to process stuff.=20
>=20
> I wonder if the SAX approach when combined with coroutines could provide =
the kind of decoupling you are looking for. We (the authors of taocpp/json =
and the PEGTL, which is the underlying parser library) are already waiting =
for coroutines to be able to play with pull-like interfaces instead of push=
-like interfaces. I do wonder about the efficiency, though. Anyways, for no=
w, we are using the SAX-like interface and I'd like to see some real code o=
f an alternative, as your above statement are too theoretical for me. Do yo=
u have a link to a library which uses such an approach?
>=20
> I haven't investigated JSON parsers, but Reader/StAX-style APIs are signi=
ficant in the XML parsing world. C# lives by them; XMLReader and XMLWriter =
are the foundation of their XML processing systems. Even LibXML2 has a read=
er interface.

After reading the examples you linked, I still feel that JSON is different =
from XML. And the SAX-like approach I am currently using is more light-weig=
ht and can be used to feed a coroutine-based reader approach. I would like =
to explore this option with real code in the future, but for now I'll just =
keep it in the back of my head unless you could come up with something conc=
rete :)

Also, you might have misunderstood the SAX approach wrt struct vs. concept.=
 The struct I posted earlier implements the methods that the SAX interface =
(concept) requires. Depending on whether the "SAX consumer" (an actual clas=
s) benefits from, for example, the move-overloads it can drop those. Severa=
l of my consumers don't have them which also makes them easier. I linked ex=
amples of real-world SAX producers and consumers earlier, I hope the can cl=
ear up any possible confusion in this area.

Daniel

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/E27AFBDD-7E42-4CE8-89F5-4C2008087413%40gmx.de.

.

On 3/2/17 9:02 AM, Nicol Bolas wrote:
> On Thursday, March 2, 2017 at 11:28:23 AM UTC-5, Robert Ramey wrote:
>
>     On 3/2/17 7:51 AM, Daniel Frey wrote:
>     >> On 2 Mar 2017, at 10:16, olaf wrote:
>     >>
>     >> Op woensdag 1 maart 2017 22:25:33 UTC+1 schreef Niels Lohmann:
>     >> There are currently dozens of libraries [json.org
>     <http://json.org>] written in C or C++ solving these aspects.
>     However, it would be of great convenience to have JSON be part of
>     the C++ standard library. In particular, the wide use of JSON as
>     exchange format for structured data as well as to express simple
>     configuration data would could solve a lot of use cases within the
>     C++ standard library.
>     >>
>     >> What's the advantage of a standard-library over a third-party
>     library (in this case), apart from not being a dependency?
>     >
>     > As I wrote in more detail in another mail already, a standard
>     SAX-like interfacewould allow different libraries or parts to be
>     mixed by the user as
>     needed. With existing libraries it is often the choice between
>     either/or.
>     >
>
>     That's not the question. The questions are -
>
>     a) what's the advantage of having something like this in the
>     standard vs
>     the current situation where one imports code from some other place?
>
>
> What's the advantage of having /anything/ in the standard library
> outside of "Table 19: C++ headers for freestanding implementations"?
> After all, the other stuff could just be a library you download. So why
> put it in the standard?
>
> Because people need this stuff.

Right.  People need lot's of stuff.  It doesn't have to be in the standard.
>
> People need networking. People need containers.

> People need filesystem access.
> People need to spawn threads and deal with inter-thread
> communication.

Here I see the value and importance.  The standards specifies a common
interface over variable implementations.  It's necessary to have a
standard here for application portability.  Note that I'm not against
the standards effort itself.  I'm advocating for narrowing it's focus to
those important issues where the standards effort can really make a
difference.

> People need to match strings against regular expressions.
> And so on.

>
> Having a standard way to do this stuff facilitates interoperability and
> allows people to use the language without having to rely on so many
> external libraries.

Even if one imports <vector> he is relying on an "external" library.
There's no real guarantee that's better than some other version.  Or
that it doesn't have a bug. It does have the guarantee that it meets the
standard interface so that's something.

Of course this raises the question that a compiler isn't considered
"conforming" if it doesn't include and implementation of the standard
library.  (leave aside that it's doubtful that any compiler can actually
implement the standard correctly).  To me we're coupling things where
the coupling doesn't add anything and has detrimental effects.

>
> It is not unreasonable for the standard library to provide a tool that
> programmers commonly use to get things done.
>
>     b) adding it to the standard would require adding features, reconciling
>     differing points of view, a ton of work to code the spec, and time
>     taken
>     from other (more important/urgent) tasks.  How would this benefit the
>     C++ community?
>
>
> See above.
>
>
>     c) Why do we all have to agree on what a json library (or any non core)
>     library should look like?  What's the point of that?
>
>
> What is "non core"? How do you define what is and is not "core"?

non core would be something like JSON for which adding to the standard
doesn't add value.

>
>     d) what value are we adding here - as opposed just the current
>     situation?
>
>
> That users can parse JSON without having to download a library. That
> users can have and rely on this functionality without having to fish
> around among dozens of different solutions of various quality,
> functionality, and behavior.

Right.  So now you download the library as part of your compiler.

The issues of quality, documentation, tests etc. still remain. Some
standard libraries are better than others. It's harder to mix/match
components between standard libraries when their distributed as
something monolithic..

There are a number of issues with third party libraries.  But adding
every thing to the standard library doesn't really address them - rather
it hides them.

Robert Ramey


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3e0232a3-441d-d37d-9c99-75af009fb15c%40rrsd.com.

.

--94eb2c12f94cd5cf800549c37b70
Content-Type: text/plain; charset=UTF-8

One particular advantage of having a library in the standard library that
seems to be frequently overlooked is that having a thing in the standard
guarantees at least a minimal amount of maintenance for both its interface
*and* its implementations. A third party library's author can one day
disappear and you might end up having to either find someone else to
maintain that particular library you're using, or maintaining it yourself,
or migrating to a different one. This is not an issue with the standard
library (well, unless you heavily depend on <codecvt>, but that is not a
thing, right?), since the interface will be maintained and updated for as
long as the committee functions by the committee itself, and multiple
implementations will exist in the wild for you to choose from.

On Thu, Mar 2, 2017 at 6:48 PM Robert Ramey <ramey@rrsd.com> wrote:

> On 3/2/17 9:02 AM, Nicol Bolas wrote:
> > On Thursday, March 2, 2017 at 11:28:23 AM UTC-5, Robert Ramey wrote:
> >
> >     On 3/2/17 7:51 AM, Daniel Frey wrote:
> >     >> On 2 Mar 2017, at 10:16, olaf wrote:
> >     >>
> >     >> Op woensdag 1 maart 2017 22:25:33 UTC+1 schreef Niels Lohmann:
> >     >> There are currently dozens of libraries [json.org
> >     <http://json.org>] written in C or C++ solving these aspects.
> >     However, it would be of great convenience to have JSON be part of
> >     the C++ standard library. In particular, the wide use of JSON as
> >     exchange format for structured data as well as to express simple
> >     configuration data would could solve a lot of use cases within the
> >     C++ standard library.
> >     >>
> >     >> What's the advantage of a standard-library over a third-party
> >     library (in this case), apart from not being a dependency?
> >     >
> >     > As I wrote in more detail in another mail already, a standard
> >     SAX-like interfacewould allow different libraries or parts to be
> >     mixed by the user as
> >     needed. With existing libraries it is often the choice between
> >     either/or.
> >     >
> >
> >     That's not the question. The questions are -
> >
> >     a) what's the advantage of having something like this in the
> >     standard vs
> >     the current situation where one imports code from some other place?
> >
> >
> > What's the advantage of having /anything/ in the standard library
> > outside of "Table 19: C++ headers for freestanding implementations"?
> > After all, the other stuff could just be a library you download. So why
> > put it in the standard?
> >
> > Because people need this stuff.
>
> Right.  People need lot's of stuff.  It doesn't have to be in the standard.
> >
> > People need networking. People need containers.
>
> > People need filesystem access.
> > People need to spawn threads and deal with inter-thread
> > communication.
>
> Here I see the value and importance.  The standards specifies a common
> interface over variable implementations.  It's necessary to have a
> standard here for application portability.  Note that I'm not against
> the standards effort itself.  I'm advocating for narrowing it's focus to
> those important issues where the standards effort can really make a
> difference.
>
> > People need to match strings against regular expressions.
> > And so on.
>
> >
> > Having a standard way to do this stuff facilitates interoperability and
> > allows people to use the language without having to rely on so many
> > external libraries.
>
> Even if one imports <vector> he is relying on an "external" library.
> There's no real guarantee that's better than some other version.  Or
> that it doesn't have a bug. It does have the guarantee that it meets the
> standard interface so that's something.
>
> Of course this raises the question that a compiler isn't considered
> "conforming" if it doesn't include and implementation of the standard
> library.  (leave aside that it's doubtful that any compiler can actually
> implement the standard correctly).  To me we're coupling things where
> the coupling doesn't add anything and has detrimental effects.
>
> >
> > It is not unreasonable for the standard library to provide a tool that
> > programmers commonly use to get things done.
> >
> >     b) adding it to the standard would require adding features,
> reconciling
> >     differing points of view, a ton of work to code the spec, and time
> >     taken
> >     from other (more important/urgent) tasks.  How would this benefit the
> >     C++ community?
> >
> >
> > See above.
> >
> >
> >     c) Why do we all have to agree on what a json library (or any non
> core)
> >     library should look like?  What's the point of that?
> >
> >
> > What is "non core"? How do you define what is and is not "core"?
>
> non core would be something like JSON for which adding to the standard
> doesn't add value.
>
> >
> >     d) what value are we adding here - as opposed just the current
> >     situation?
> >
> >
> > That users can parse JSON without having to download a library. That
> > users can have and rely on this functionality without having to fish
> > around among dozens of different solutions of various quality,
> > functionality, and behavior.
>
> Right.  So now you download the library as part of your compiler.
>
> The issues of quality, documentation, tests etc. still remain. Some
> standard libraries are better than others. It's harder to mix/match
> components between standard libraries when their distributed as
> something monolithic..
>
> There are a number of issues with third party libraries.  But adding
> every thing to the standard library doesn't really address them - rather
> it hides them.
>
> Robert Ramey
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3e0232a3-441d-d37d-9c99-75af009fb15c%40rrsd.com
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTQdS1%3D3k65Vevo6yBEw7Tor9JTdN8VKkqRRh7iphRCLQ%40mail.gmail.com.

--94eb2c12f94cd5cf800549c37b70
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">One particular advantage of having a library in the standa=
rd library that seems to be frequently overlooked is that having a thing in=
 the standard guarantees at least a minimal amount of maintenance for both =
its interface <i>and</i>=C2=A0its implementations. A third party library&#3=
9;s author can one day disappear and you might end up having to either find=
 someone else to maintain that particular library you&#39;re using, or main=
taining it yourself, or migrating to a different one. This is not an issue =
with the standard library (well, unless you heavily depend on &lt;codecvt&g=
t;, but that is not a thing, right?), since the interface will be maintaine=
d and updated for as long as the committee functions by the committee itsel=
f, and multiple implementations will exist in the wild for you to choose fr=
om.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Mar 2, 201=
7 at 6:48 PM Robert Ramey &lt;<a href=3D"mailto:ramey@rrsd.com">ramey@rrsd.=
com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 3/2/17 9:02 A=
M, Nicol Bolas wrote:<br class=3D"gmail_msg">
&gt; On Thursday, March 2, 2017 at 11:28:23 AM UTC-5, Robert Ramey wrote:<b=
r class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0On 3/2/17 7:51 AM, Daniel Frey wrote:<br class=3D"g=
mail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0&gt;&gt; On 2 Mar 2017, at 10:16, olaf wrote:<br cl=
ass=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0&gt;&gt;<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0&gt;&gt; Op woensdag 1 maart 2017 22:25:33 UTC+1 sc=
hreef Niels Lohmann:<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0&gt;&gt; There are currently dozens of libraries [<=
a href=3D"http://json.org" rel=3D"noreferrer" class=3D"gmail_msg" target=3D=
"_blank">json.org</a><br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0&lt;<a href=3D"http://json.org" rel=3D"noreferrer" =
class=3D"gmail_msg" target=3D"_blank">http://json.org</a>&gt;] written in C=
 or C++ solving these aspects.<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0However, it would be of great convenience to have J=
SON be part of<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0the C++ standard library. In particular, the wide u=
se of JSON as<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0exchange format for structured data as well as to e=
xpress simple<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0configuration data would could solve a lot of use c=
ases within the<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0C++ standard library.<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0&gt;&gt;<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0&gt;&gt; What&#39;s the advantage of a standard-lib=
rary over a third-party<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0library (in this case), apart from not being a depe=
ndency?<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0&gt;<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0&gt; As I wrote in more detail in another mail alre=
ady, a standard<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0SAX-like interfacewould allow different libraries o=
r parts to be<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0mixed by the user as<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0needed. With existing libraries it is often the cho=
ice between<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0either/or.<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0&gt;<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0That&#39;s not the question. The questions are -<br=
 class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0a) what&#39;s the advantage of having something lik=
e this in the<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0standard vs<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0the current situation where one imports code from s=
ome other place?<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; What&#39;s the advantage of having /anything/ in the standard library<=
br class=3D"gmail_msg">
&gt; outside of &quot;Table 19: C++ headers for freestanding implementation=
s&quot;?<br class=3D"gmail_msg">
&gt; After all, the other stuff could just be a library you download. So wh=
y<br class=3D"gmail_msg">
&gt; put it in the standard?<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Because people need this stuff.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
Right.=C2=A0 People need lot&#39;s of stuff.=C2=A0 It doesn&#39;t have to b=
e in the standard.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; People need networking. People need containers.<br class=3D"gmail_msg"=
>
<br class=3D"gmail_msg">
&gt; People need filesystem access.<br class=3D"gmail_msg">
&gt; People need to spawn threads and deal with inter-thread<br class=3D"gm=
ail_msg">
&gt; communication.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
Here I see the value and importance.=C2=A0 The standards specifies a common=
<br class=3D"gmail_msg">
interface over variable implementations.=C2=A0 It&#39;s necessary to have a=
<br class=3D"gmail_msg">
standard here for application portability.=C2=A0 Note that I&#39;m not agai=
nst<br class=3D"gmail_msg">
the standards effort itself.=C2=A0 I&#39;m advocating for narrowing it&#39;=
s focus to<br class=3D"gmail_msg">
those important issues where the standards effort can really make a<br clas=
s=3D"gmail_msg">
difference.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt; People need to match strings against regular expressions.<br class=3D"=
gmail_msg">
&gt; And so on.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; Having a standard way to do this stuff facilitates interoperability an=
d<br class=3D"gmail_msg">
&gt; allows people to use the language without having to rely on so many<br=
 class=3D"gmail_msg">
&gt; external libraries.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
Even if one imports &lt;vector&gt; he is relying on an &quot;external&quot;=
 library.<br class=3D"gmail_msg">
There&#39;s no real guarantee that&#39;s better than some other version.=C2=
=A0 Or<br class=3D"gmail_msg">
that it doesn&#39;t have a bug. It does have the guarantee that it meets th=
e<br class=3D"gmail_msg">
standard interface so that&#39;s something.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
Of course this raises the question that a compiler isn&#39;t considered<br =
class=3D"gmail_msg">
&quot;conforming&quot; if it doesn&#39;t include and implementation of the =
standard<br class=3D"gmail_msg">
library.=C2=A0 (leave aside that it&#39;s doubtful that any compiler can ac=
tually<br class=3D"gmail_msg">
implement the standard correctly).=C2=A0 To me we&#39;re coupling things wh=
ere<br class=3D"gmail_msg">
the coupling doesn&#39;t add anything and has detrimental effects.<br class=
=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; It is not unreasonable for the standard library to provide a tool that=
<br class=3D"gmail_msg">
&gt; programmers commonly use to get things done.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0b) adding it to the standard would require adding f=
eatures, reconciling<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0differing points of view, a ton of work to code the=
 spec, and time<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0taken<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0from other (more important/urgent) tasks.=C2=A0 How=
 would this benefit the<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0C++ community?<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; See above.<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0c) Why do we all have to agree on what a json libra=
ry (or any non core)<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0library should look like?=C2=A0 What&#39;s the poin=
t of that?<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; What is &quot;non core&quot;? How do you define what is and is not &qu=
ot;core&quot;?<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
non core would be something like JSON for which adding to the standard<br c=
lass=3D"gmail_msg">
doesn&#39;t add value.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0d) what value are we adding here - as opposed just =
the current<br class=3D"gmail_msg">
&gt;=C2=A0 =C2=A0 =C2=A0situation?<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt;<br class=3D"gmail_msg">
&gt; That users can parse JSON without having to download a library. That<b=
r class=3D"gmail_msg">
&gt; users can have and rely on this functionality without having to fish<b=
r class=3D"gmail_msg">
&gt; around among dozens of different solutions of various quality,<br clas=
s=3D"gmail_msg">
&gt; functionality, and behavior.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
Right.=C2=A0 So now you download the library as part of your compiler.<br c=
lass=3D"gmail_msg">
<br class=3D"gmail_msg">
The issues of quality, documentation, tests etc. still remain. Some<br clas=
s=3D"gmail_msg">
standard libraries are better than others. It&#39;s harder to mix/match<br =
class=3D"gmail_msg">
components between standard libraries when their distributed as<br class=3D=
"gmail_msg">
something monolithic..<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
There are a number of issues with third party libraries.=C2=A0 But adding<b=
r class=3D"gmail_msg">
every thing to the standard library doesn&#39;t really address them - rathe=
r<br class=3D"gmail_msg">
it hides them.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
Robert Ramey<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
--<br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br class=3D"gmail_msg=
">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" class=3D"=
gmail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br c=
lass=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3e0232a3-441d-d37d-9c99-75af009fb15c%=
40rrsd.com" rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https:=
//groups.google.com/a/isocpp.org/d/msgid/std-proposals/3e0232a3-441d-d37d-9=
c99-75af009fb15c%40rrsd.com</a>.<br class=3D"gmail_msg">
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTQdS1%3D3k65Vevo6yBEw7Tor9JTdN=
8VKkqRRh7iphRCLQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTQdS1%3D=
3k65Vevo6yBEw7Tor9JTdN8VKkqRRh7iphRCLQ%40mail.gmail.com</a>.<br />

--94eb2c12f94cd5cf800549c37b70--

.

On 3/2/17 10:20 AM, Micha=C5=82 Dominiak wrote:
> One particular advantage of having a library in the standard library
> that seems to be frequently overlooked is that having a thing in the
> standard guarantees at least a minimal amount of maintenance for both
> its interface /and/ its implementations. A third party library's author
> can one day disappear and you might end up having to either find someone
> else to maintain that particular library you're using, or maintaining it
> yourself, or migrating to a different one. This is not an issue with the
> standard library (well, unless you heavily depend on <codecvt>, but that
> is not a thing, right?), since the interface will be maintained and
> updated for as long as the committee functions by the committee itself,
> and multiple implementations will exist in the wild for you to choose fro=
m.

Damn - I do depend on codecvt (more accurately codecvt facets) and it's=20
been a PITA for the last 15 years.

I appreciate the point.  And generally maintenence by compiler providers=20
had been pretty good.  On the other hand, I'm really wondering how they=20
are going to sustain that with incorporation of very large and elaborate=20
packages such as Ranges, ASIO and ?.  Then what?
are we going to fall back on the original ASIO package?  If I do that,=20
why not just depend on that in the first place.

Basically, I'm worried about

a) where are libraries going to come from.
b) how long is it going to take to "get them into the standard"
c) what happens when they need to be deprecated or fixed in some=20
fundamental way.  For example, we've got problems with complexity of the=20
io streams.  How is that going to evolve in the future?
d) who is going to keep maintenance of the giant things up to date?
e) and who is going to pay for it?

When something is successful, there is a natural tendency to expand it's=20
scope.  Often times this ends up stifling the progress that one is=20
actually hoping to promote.  Often times - less is more.

Robert Ramey

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/59e8bbb1-c45d-dca0-97bd-3ae8dea49959%40rrsd.com.

.

------=_Part_298_2057472529.1488483672301
Content-Type: multipart/alternative;
 boundary="----=_Part_299_1449697090.1488483672301"

------=_Part_299_1449697090.1488483672301
Content-Type: text/plain; charset=UTF-8

On Thursday, March 2, 2017 at 12:41:10 PM UTC-5, Daniel Frey wrote:
>
> For some reason my mail client (MacOS Mail) screws up the quoting levels -
> sorry.
>
> > On 2 Mar 2017, at 17:46, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> >
> > On Thursday, March 2, 2017 at 1:07:29 AM UTC-5, Daniel Frey wrote:
> > > On 2 Mar 2017, at 06:52, Nicol Bolas <jmck...@gmail.com> wrote:
> > >
> > > Personally, I've always disliked the SAX approach, where reads are
> forced on you. I much prefer the reader approach, where you read at
> whatever pace you like. It's rather more like an iterator in that respect.
> > >
> > > Such an approach makes it very easy on the code doing the reading,
> since it can do things like pass the reader to other code to interpret
> those parameters. Doing this with a SAX interface requires basically
> writing a state machine into a type. And why would you want to encourage
> that kind of coding?
> > >
> > > You can get the same effects of a SAX interface with a Reader-like
> approach. Rather than standardizing the struct that interprets the JSON,
> you standardize the Reader as a Concept. A Reader has functions to read the
> next datum, tell you want that datum is, etc. And you can standardize a
> similar Writer Concept, which has interfaces for writing the data.
> > >
> > > So you get all of the benefits you outline, but without the huge
> detriment of using SAX to process stuff.
> >
> > I wonder if the SAX approach when combined with coroutines could provide
> the kind of decoupling you are looking for. We (the authors of taocpp/json
> and the PEGTL, which is the underlying parser library) are already waiting
> for coroutines to be able to play with pull-like interfaces instead of
> push-like interfaces. I do wonder about the efficiency, though. Anyways,
> for now, we are using the SAX-like interface and I'd like to see some real
> code of an alternative, as your above statement are too theoretical for me.
> Do you have a link to a library which uses such an approach?
> >
> > I haven't investigated JSON parsers, but Reader/StAX-style APIs are
> significant in the XML parsing world. C# lives by them; XMLReader and
> XMLWriter are the foundation of their XML processing systems. Even LibXML2
> has a reader interface.
>
> After reading the examples you linked, I still feel that JSON is different
> from XML.


SAX stands for "Simple API for XML". If one XML-based interface was good
enough for JSON, why not the other? StAX-style interfaces would work just
as well as SAX.

And the SAX-like approach I am currently using is more light-weight


How is StAX more heavy-weight? Indeed, I find that StAX is lower-level.

You can implement SAX APIs on top of an StAX API; doing the opposite is far
more complex. Just look at what you said: "We [...] are already waiting for
coroutines to be able to play with pull-like interfaces instead of
push-like interfaces." Why would you wait for a complex feature like
coroutines, instead of just making your parser work in a pull fashion?

And implementing SAX on top of StAX doesn't require coroutines or anything
of the sort.

and can be used to feed a coroutine-based reader approach. I would like to
> explore this option with real code in the future, but for now I'll just
> keep it in the back of my head unless you could come up with something
> concrete :)
>
> Also, you might have misunderstood the SAX approach wrt struct vs.
> concept. The struct I posted earlier implements the methods that the SAX
> interface (concept) requires.


I have a working understanding of SAX-style interfaces. My problem with
SAX-style interfaces is that it forces you to implement a state machine,
because all data is routed through a single object.

Pull APIs allow you to structure your code in a way that is *structured*.
You get in a value. You test what it is. You then pass call a function to
process that kind of data, passing it the StAX reader. That function reads
more values, recursively descending through the JSON in a manner
reminiscent of a recursive descent parser.

Push APIs require you to route all of this processing work through a single
object. And therefore, it has to store which state its currently on, so
that it can send that state the data in question. It's just a big pain to
deal with, one which doesn't use the C++ stack effectively.

If you're parsing tiny JSON fragments, then such an approach is probably
OK. But if you're parsing anything of particular size and/or complexity, it
becomes increasingly unwieldy.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f4583ee3-5402-48f8-b8f7-3b910dec7c75%40isocpp.org.

------=_Part_299_1449697090.1488483672301
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 2, 2017 at 12:41:10 PM UTC-5, Daniel Fr=
ey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">For some reason my ma=
il client (MacOS Mail) screws up the quoting levels - sorry.
<br>
<br>&gt; On 2 Mar 2017, at 17:46, Nicol Bolas &lt;<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"SVMd4PgICgAJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrot=
e:
<br>&gt;=20
<br>&gt; On Thursday, March 2, 2017 at 1:07:29 AM UTC-5, Daniel Frey wrote:
<br>&gt; &gt; On 2 Mar 2017, at 06:52, Nicol Bolas &lt;<a>jmck...@gmail.com=
</a>&gt; wrote:=20
<br>&gt; &gt;=20
<br>&gt; &gt; Personally, I&#39;ve always disliked the SAX approach, where =
reads are forced on you. I much prefer the reader approach, where you read =
at whatever pace you like. It&#39;s rather more like an iterator in that re=
spect.=20
<br>&gt; &gt;=20
<br>&gt; &gt; Such an approach makes it very easy on the code doing the rea=
ding, since it can do things like pass the reader to other code to interpre=
t those parameters. Doing this with a SAX interface requires basically writ=
ing a state machine into a type. And why would you want to encourage that k=
ind of coding?=20
<br>&gt; &gt;=20
<br>&gt; &gt; You can get the same effects of a SAX interface with a Reader=
-like approach. Rather than standardizing the struct that interprets the JS=
ON, you standardize the Reader as a Concept. A Reader has functions to read=
 the next datum, tell you want that datum is, etc. And you can standardize =
a similar Writer Concept, which has interfaces for writing the data.=20
<br>&gt; &gt;=20
<br>&gt; &gt; So you get all of the benefits you outline, but without the h=
uge detriment of using SAX to process stuff.=20
<br>&gt;=20
<br>&gt; I wonder if the SAX approach when combined with coroutines could p=
rovide the kind of decoupling you are looking for. We (the authors of taocp=
p/json and the PEGTL, which is the underlying parser library) are already w=
aiting for coroutines to be able to play with pull-like interfaces instead =
of push-like interfaces. I do wonder about the efficiency, though. Anyways,=
 for now, we are using the SAX-like interface and I&#39;d like to see some =
real code of an alternative, as your above statement are too theoretical fo=
r me. Do you have a link to a library which uses such an approach?
<br>&gt;=20
<br>&gt; I haven&#39;t investigated JSON parsers, but Reader/StAX-style API=
s are significant in the XML parsing world. C# lives by them; XMLReader and=
 XMLWriter are the foundation of their XML processing systems. Even LibXML2=
 has a reader interface.
<br>
<br>After reading the examples you linked, I still feel that JSON is differ=
ent from XML.</blockquote><div><br>SAX stands for &quot;Simple API for XML&=
quot;. If one XML-based interface was good enough for JSON, why not the oth=
er? StAX-style interfaces would work just as well as SAX.<br><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">And the SAX-like approach I am cur=
rently using is more light-weight</blockquote><div><br>How is StAX more hea=
vy-weight? Indeed, I find that StAX is lower-level.<br><br>You can implemen=
t SAX APIs on top of an StAX API; doing the opposite is far more complex. J=
ust look at what you said: &quot;We [...] are already waiting for coroutine=
s to be able to play=20
with pull-like interfaces instead of push-like interfaces.&quot; Why would =
you wait for a complex feature like coroutines, instead of just making your=
 parser work in a pull fashion?<br><br>And implementing SAX on top of StAX =
doesn&#39;t require coroutines or anything of the sort.<br><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">and can be used to feed a coroutine-=
based reader approach. I would like to explore this option with real code i=
n the future, but for now I&#39;ll just keep it in the back of my head unle=
ss you could come up with something concrete :)
<br>
<br>Also, you might have misunderstood the SAX approach wrt struct vs. conc=
ept. The struct I posted earlier implements the methods that the SAX interf=
ace (concept) requires.</blockquote><div><br>I have a working understanding=
 of SAX-style interfaces. My problem with SAX-style interfaces is that it f=
orces you to implement a state machine, because all data is routed through =
a single object.<br><br>Pull APIs allow you to structure your code in a way=
 that is <i>structured</i>. You get in a value. You test what it is. You th=
en pass call a function to process that kind of data, passing it the StAX r=
eader. That function reads more values, recursively descending through the =
JSON in a manner reminiscent of a recursive descent parser.<br><br>Push API=
s require you to route all of this processing work through a single object.=
 And therefore, it has to store which state its currently on, so that it ca=
n send that state the data in question. It&#39;s just a big pain to deal wi=
th, one which doesn&#39;t use the C++ stack effectively.<br><br>If you&#39;=
re parsing tiny JSON fragments, then such an approach is probably OK. But i=
f you&#39;re parsing anything of particular size and/or complexity, it beco=
mes increasingly unwieldy.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f4583ee3-5402-48f8-b8f7-3b910dec7c75%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f4583ee3-5402-48f8-b8f7-3b910dec7c75=
%40isocpp.org</a>.<br />

------=_Part_299_1449697090.1488483672301--

------=_Part_298_2057472529.1488483672301--

.

What is 'core':

- vocabulary types. That is, types that are likely to be used as building b=
locks for other APIs. If we didn't all use the same unique_ptr, then my API=
 would need to invent one way to express "you own this now", and your API a=
nother. Vocabulary types include: unique/shared_ptr, variant, optional,any,=
expected, the base exceptions, iterators (for template APIs at least - a AB=
I stable type erased iterator could also be useful) string, string_view, et=
c.=C2=A0

I would add vector, although most would put it in the next category. When y=
ou want to take or return a 'bunch' of items, we have no good vocabulary ty=
pe - you either do iterators (forcing templates), or callbacks/visitors/lam=
bdas, or coroutines...? or just use vector, since that's what your client i=
s probably using anyhow.

- common/generic building blocks - containers like vector and (unordered_)m=
ap. And the generic algorithms. These are building blocks - they don't solv=
e your problem, but they are pieces used to solve a wide variety of problem=
s. They are not domain specific.=C2=A0

- compiler specific / platform specific. Intrinsic type_traits such as is_u=
nion, etc. =E2=80=8EPlatform things like threads. These are required to avo=
id writing compiler specific or platform spcific code.=C2=A0

I think that may be it. (I probably forgot something). That's core.

Having said that, the other question is:
Should the STL only do core?

Robert has some good reasons for 'yes'. I agree.=C2=A0
There are also good reasons for 'no':
1. other languages ship with more in the box
2. we have no good or (de facto) standard way to manage library packages.
3. Picking the right non-standard library takes time - just try starting a =
new Web project - with a new UI paradigm each week, there are too many choi=
ces - literally too many to be able to make an informed choice.

If we could do 2, that might lessen the need for 1.
Boost helps with 3. And 2 somewhat (and thus 1)

Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Robert Ramey
Sent: Thursday, March 2, 2017 1:41 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: [std-proposals] Re: JSON support for the C++ standard library

On 3/2/17 10:20 AM, Micha=C5=82 Dominiak wrote:
> One particular advantage of having a library in the standard library
> that seems to be frequently overlooked is that having a thing in the
> standard guarantees at least a minimal amount of maintenance for both
> its interface /and/ its implementations. A third party library's author
> can one day disappear and you might end up having to either find someone
> else to maintain that particular library you're using, or maintaining it
> yourself, or migrating to a different one. This is not an issue with the
> standard library (well, unless you heavily depend on <codecvt>, but that
> is not a thing, right?), since the interface will be maintained and
> updated for as long as the committee functions by the committee itself,
> and multiple implementations will exist in the wild for you to choose fro=
m.

Damn - I do depend on codecvt (more accurately codecvt facets) and it's=20
been a PITA for the last 15 years.

I appreciate the point. And generally maintenence by compiler providers=20
had been pretty good. On the other hand, I'm really wondering how they=20
are going to sustain that with incorporation of very large and elaborate=20
packages such as Ranges, ASIO and ?. Then what?
are we going to fall back on the original ASIO package? If I do that,=20
why not just depend on that in the first place.

Basically, I'm worried about

a) where are libraries going to come from.
b) how long is it going to take to "get them into the standard"
c) what happens when they need to be deprecated or fixed in some=20
fundamental way. For example, we've got problems with complexity of the=20
io streams. How is that going to evolve in the future?
d) who is going to keep maintenance of the giant things up to date?
e) and who is going to pay for it?

When something is successful, there is a natural tendency to expand it's=20
scope. Often times this ends up stifling the progress that one is=20
actually hoping to promote. Often times - less is more.

Robert Ramey

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/59e8bbb1-c45d-dca0-97bd-3ae8dea49959%40rrsd.com.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20170302212643.5095507.42588.26427%40gmail.com.

.

> On 2 Mar 2017, at 21:37, Nicol Bolas <jmckesson@gmail.com> wrote:
>=20
> On Thursday, March 2, 2017 at 3:01:12 PM UTC-5, Daniel Frey wrote:
> > > On 2 Mar 2017, at 20:41, Nicol Bolas <jmck...@gmail.com> wrote:=20
> > >=20
> > > I have a working understanding of SAX-style interfaces. My problem wi=
th SAX-style interfaces is that it forces you to implement a state machine,=
 because all data is routed through a single object.=20
>=20
> > No.
>=20
> Um... yes? Your examples show precisely that interface. Every time the pa=
rser reaches a new JSON value, you get a function call in that object. And =
therefore, it must forward that information to the place where it will actu=
ally be processed.

The "No" refers to "forces you to implement a state machine". You make a ge=
neral claim that is simply not true. In some use-cases you might need a sta=
te machine, and in those use-cases the StAX approach might work better. But=
 it's a trade-off, not a clear win. You are pessimizing other use-cases whe=
re the intermediate generic value (and a switch on the type) is not needed.=
 An example would be a pretty printer. Reading a file generates SAX events,=
 passed directly to the SAX pretty printer. No json::value instance (or wha=
tever the reader in the StAX case stores as its state) is created/updated.

> > > Pull APIs allow you to structure your code in a way that is structure=
d. You get in a value. You test what it is. You then pass call a function t=
o process that kind of data, passing it the StAX reader. That function read=
s more values, recursively descending through the JSON in a manner reminisc=
ent of a recursive descent parser.=20

You are thinking of a use-case where you are not creating/using a generic J=
SON value, but a JSON value with a specific schema and you are skipping the=
 JSON level, directly using the structure you are expecting, right? I can s=
ee how the StAX approach is helpful there, but...

> If you're referring to this post, those are examples of trivial things th=
at don't need state, or whose state is trivial. "stringify" and "prettify" =
do the same operation on the same things, no matter where they appear in th=
e JSON hierarhcy. Yes, SAX shines in such circumstances.
>=20
> But these are not useful circumstances for parsing JSON files. Generally =
speaking, the way you interpret data depends on how that data was interpret=
ed before you.

....you are the one who defines for other what are "useful" circumstances?? =
You can't just declare everyone else's use-cases as "not useful" and only y=
our own as "useful". For me, your use-case never came up. In fact the most =
important use-case to me is:

* Construct json::value instances with an std::initializer_list directly in=
 the code. (More information was in the presentation I linked earlier)
* Stringify the value.
* Efficiency - it must be *very* fast.

I don't think a StAX approach would benefit me.

> Show me what your code would have to look like to be able to parse a JSON=
 langauge of decent complexity, like glTF. I guarantee you that you're goin=
g to have to build some form of state machine.

Yes, sure, but that is your use-case - not mine. Show me the StAX-style cod=
e (and benchmarks) of my use-case, will you?

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CE698787-58D9-472B-A7A9-D0EBC7A7BA52%40gmx.de.

.

--001a113f58c00edc750549c6f5c7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2017-03-02 19:41 GMT+01:00 Robert Ramey <ramey@rrsd.com>:

> On 3/2/17 10:20 AM, Micha=C5=82 Dominiak wrote:
>
>> One particular advantage of having a library in the standard library
>> that seems to be frequently overlooked is that having a thing in the
>> standard guarantees at least a minimal amount of maintenance for both
>> its interface /and/ its implementations. A third party library's author
>> can one day disappear and you might end up having to either find someone
>> else to maintain that particular library you're using, or maintaining it
>> yourself, or migrating to a different one. This is not an issue with the
>> standard library (well, unless you heavily depend on <codecvt>, but that
>> is not a thing, right?), since the interface will be maintained and
>> updated for as long as the committee functions by the committee itself,
>> and multiple implementations will exist in the wild for you to choose
>> from.
>>
>
> Damn - I do depend on codecvt (more accurately codecvt facets) and it's
> been a PITA for the last 15 years.
>
> I appreciate the point.  And generally maintenence by compiler providers
> had been pretty good.  On the other hand, I'm really wondering how they a=
re
> going to sustain that with incorporation of very large and elaborate
> packages such as Ranges, ASIO and ?.  Then what?
> are we going to fall back on the original ASIO package?  If I do that, wh=
y
> not just depend on that in the first place.
>
> Basically, I'm worried about
>
> a) where are libraries going to come from.
> b) how long is it going to take to "get them into the standard"
> c) what happens when they need to be deprecated or fixed in some
> fundamental way.  For example, we've got problems with complexity of the =
io
> streams.  How is that going to evolve in the future?
> d) who is going to keep maintenance of the giant things up to date?
> e) and who is going to pay for it?
>
> When something is successful, there is a natural tendency to expand it's
> scope.  Often times this ends up stifling the progress that one is actual=
ly
> hoping to promote.  Often times - less is more.


Unfortunately you need to have balance between larger libraries and
primitives in the standard in order for a language to grow in use.

You produced a valid list but unfortunately other languages come with
larger standard libraries out of the box and allot of hype mixed with some
truth regarding better equipped languages for a task can produce an even
larger list of worries of what will happen over time.
And yes it's annoying that from the looks of it in the development world
hype is far more influential than quality and truth but that's the mess
we're in so I'm guessing that either the standard library will grow over
time or the hype will distort the truth so much that C++ will really just
become a language without support. I might be wrong but my experience over
the years are telling me that I'm right...

Regarding external libraries - at the company where I work there was a veto
on Boost libraries already before my time and the ban still stands
(argument was that requiring to patch Boost before compiling it with xlC_r
IBM compiler on AIX is not stable enough). In the end in my case it's
easier to get a newer version of the compiler than to get a new library
into a project (and IBM with poorly implemented C++11 support in their
compiler on AIX surely doesn't help when arguing for the language). That's
the state of things from where I stand.

In the end our company migrated most of the software to Java mostly due to
hype and the promise of allot of extra standard library features which are
mostly not used (and hasn't changed nearly as much as the hype promised but
people don't like to admit such things). Years later I was told that the
hype over the years caused that C++ people are harder to find than Java in
our country so that was possibly the main reason for the migration... All I
know for certain is that most of the conversations when deciding whether to
write something in C++ or Java boils down to
java-has-more-standard-library-features-so-its-better (it's surprising how
people like to agree with more is better statement) so seeing C++ as a low
level language only doesn't help anyone.

Regarding who's going to pay... Well either compiler vendors will bother as
they do with languages such as Java or they'll stop bothering no matter
what as they'll be able to sell more compilers for other languages with
larger libraries - standing still only makes things worse over time.

That being said while I don't agree that Ranges and ASIO fall into
non-essential basket I do admit that while my job and arguments would be
allot easier by having an XML and Json library integrated into the language
I would instead prefer a Boost Spirit Qi/X3 and Karma style of library in
the standard (specially if it were implemented via pattern matching
integrated into the language so that I'd be able to write/generate my own
grammar/schema specific pattern matching/generating code).

But as a less generic alternative a Json library would still be a nice
start non the less (it's still a basic building block for communication,
configuration, data storing etc.).

Regards,
Domen

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKgx6BLxeG1sON%3DPWMwU6AY9WnRmkVPA1QjX4GQkgJc_o=
O%3DUAA%40mail.gmail.com.

--001a113f58c00edc750549c6f5c7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">2017-03-02 19:41 GMT+01:00 Robert Ramey <span dir=3D"ltr">=
&lt;<a href=3D"mailto:ramey@rrsd.com" target=3D"_blank">ramey@rrsd.com</a>&=
gt;</span>:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-">On 3/2/1=
7 10:20 AM, Micha=C5=82 Dominiak wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"gma=
il-">
One particular advantage of having a library in the standard library<br>
that seems to be frequently overlooked is that having a thing in the<br>
standard guarantees at least a minimal amount of maintenance for both<br></=
span>
its interface /and/ its implementations. A third party library&#39;s author=
<span class=3D"gmail-"><br>
can one day disappear and you might end up having to either find someone<br=
>
else to maintain that particular library you&#39;re using, or maintaining i=
t<br>
yourself, or migrating to a different one. This is not an issue with the<br=
>
standard library (well, unless you heavily depend on &lt;codecvt&gt;, but t=
hat<br>
is not a thing, right?), since the interface will be maintained and<br>
updated for as long as the committee functions by the committee itself,<br>
and multiple implementations will exist in the wild for you to choose from.=
<br>
</span></blockquote>
<br>
Damn - I do depend on codecvt (more accurately codecvt facets) and it&#39;s=
 been a PITA for the last 15 years.<br>
<br>
I appreciate the point.=C2=A0 And generally maintenence by compiler provide=
rs had been pretty good.=C2=A0 On the other hand, I&#39;m really wondering =
how they are going to sustain that with incorporation of very large and ela=
borate packages such as Ranges, ASIO and ?.=C2=A0 Then what?<br>
are we going to fall back on the original ASIO package?=C2=A0 If I do that,=
 why not just depend on that in the first place.<br>
<br>
Basically, I&#39;m worried about<br>
<br>
a) where are libraries going to come from.<br>
b) how long is it going to take to &quot;get them into the standard&quot;<b=
r>
c) what happens when they need to be deprecated or fixed in some fundamenta=
l way.=C2=A0 For example, we&#39;ve got problems with complexity of the io =
streams.=C2=A0 How is that going to evolve in the future?<br>
d) who is going to keep maintenance of the giant things up to date?<br>
e) and who is going to pay for it?<br>
<br>
When something is successful, there is a natural tendency to expand it&#39;=
s scope.=C2=A0 Often times this ends up stifling the progress that one is a=
ctually hoping to promote.=C2=A0 Often times - less is more.<span class=3D"=
gmail-"></span></blockquote><div><br></div><div>Unfortunately you need to h=
ave balance between larger libraries and primitives in the standard in orde=
r for a language to grow in use.<br></div><br></div>You produced a valid li=
st but unfortunately other languages come with larger standard libraries ou=
t of the box and allot of hype mixed with some truth regarding better equip=
ped languages for a task can produce an even larger list of worries of what=
 will happen over time.<br></div><div class=3D"gmail_extra">And yes it&#39;=
s annoying that from the looks of it in the development world hype is far m=
ore influential than quality and truth but that&#39;s the mess we&#39;re in=
 so I&#39;m guessing that either the standard library will grow over time o=
r the hype will distort the truth so much that C++ will really just become =
a language without support. I might be wrong but my experience over the yea=
rs are telling me that I&#39;m right...<br><br></div><div class=3D"gmail_ex=
tra">Regarding external libraries - at the company where I work there was a=
 veto on Boost libraries already before my time and the ban still stands (a=
rgument was that requiring to patch Boost before compiling it with xlC_r IB=
M compiler on AIX is not stable enough). In the end in my case it&#39;s eas=
ier to get a newer version of the compiler than to get a new library into a=
 project (and IBM with poorly implemented C++11 support in their compiler o=
n AIX surely doesn&#39;t help when arguing for the language). That&#39;s th=
e state of things from where I stand.<br></div><div class=3D"gmail_extra"><=
br>In the end our company migrated most of the software to Java mostly due=
=20
to hype and the promise of allot of extra standard library features which a=
re mostly not used (and hasn&#39;t changed nearly as much as the hype promi=
sed but people don&#39;t like to admit such things). Years later I was told=
 that the hype over the years caused that C++ people are=20
harder to find than Java in our country so that was possibly the main reaso=
n for the migration... All I know for certain is that most of the conversat=
ions when deciding whether to write something in C++ or Java boils down to =
java-has-more-standard-library-features-so-its-better (it&#39;s surprising =
how people like to agree with more is better statement) so seeing C++ as a =
low level language only doesn&#39;t help anyone.<br><br></div><div class=3D=
"gmail_extra">Regarding who&#39;s going to pay... Well either compiler vend=
ors will bother as they do with languages such as Java or they&#39;ll stop =
bothering no matter what as they&#39;ll be able to sell more compilers for =
other languages with larger libraries - standing still only makes things wo=
rse over time.<br></div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra">That being said while I don&#39;t agree that Ranges and ASIO f=
all into non-essential basket I do admit that while my job and arguments wo=
uld be allot easier by having an XML and Json library integrated into the l=
anguage I would instead prefer a Boost Spirit Qi/X3 and Karma style of libr=
ary in the standard (specially if it were implemented via pattern matching =
integrated into the language so that I&#39;d be able to write/generate my o=
wn grammar/schema specific pattern matching/generating code).<br><br></div>=
<div class=3D"gmail_extra">But as a less generic alternative a Json library=
 would still be a nice start non the less (it&#39;s still a basic building =
block for communication, configuration, data storing etc.).<br></div><div c=
lass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Regards,<br></div=
><div class=3D"gmail_extra">Domen<br></div><div class=3D"gmail_extra"><br><=
br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><br></div></=
div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKgx6BLxeG1sON%3DPWMwU6AY9WnRmkVPA1Q=
jX4GQkgJc_oO%3DUAA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BLxeG1s=
ON%3DPWMwU6AY9WnRmkVPA1QjX4GQkgJc_oO%3DUAA%40mail.gmail.com</a>.<br />

--001a113f58c00edc750549c6f5c7--

.

------=_Part_410_850302021.1488527345680
Content-Type: multipart/alternative;
 boundary="----=_Part_411_1464195096.1488527345681"

------=_Part_411_1464195096.1488527345681
Content-Type: text/plain; charset=UTF-8

On Thursday, March 2, 2017 at 4:57:05 PM UTC-5, Daniel Frey wrote:
>
> > On 2 Mar 2017, at 21:37, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> >
> > On Thursday, March 2, 2017 at 3:01:12 PM UTC-5, Daniel Frey wrote:
> > > > On 2 Mar 2017, at 20:41, Nicol Bolas <jmck...@gmail.com> wrote:
> > > >
> > > > I have a working understanding of SAX-style interfaces. My problem
> with SAX-style interfaces is that it forces you to implement a state
> machine, because all data is routed through a single object.
> >
> > > No.
> >
> > Um... yes? Your examples show precisely that interface. Every time the
> parser reaches a new JSON value, you get a function call in that object.
> And therefore, it must forward that information to the place where it will
> actually be processed.
>
> The "No" refers to "forces you to implement a state machine". You make a
> general claim that is simply not true. In some use-cases you might need a
> state machine, and in those use-cases the StAX approach might work better.
> But it's a trade-off, not a clear win. You are pessimizing other use-cases
> where the intermediate generic value (and a switch on the type) is not
> needed. An example would be a pretty printer.


The problem with tossing that example around is that it is *trivial*. It's
so trivial that you could write it without even using a framework; just
take the JSON-C++ objects and walk the hierarchy, outputting to the stream
as you go. Seriously, your `to_stream` example is *maybe* an hour's worth
of coding, assuming you have a JSON data structure in C++.

Your argument seems to be that SAX makes easy things easier. You're right;
it does. But it also makes hard things *harder*. Why should we optimize the
infrastructure for tasks so easy that they barely justify that
infrastructure, rather than for the hard tasks where people actually need
that JSON infrastructure?

Reading a file generates SAX events, passed directly to the SAX pretty
> printer. No json::value instance (or whatever the reader in the StAX case
> stores as its state) is created/updated.
>

But it does create that data. Just not in a visible or obvious way.

A SAX-style parser puts that data on the stack when it calls one of your
functions, since the value is now a parameter. A StAX-reader puts that data
in the object. Since readers will, more likely than not, be stack objects,
their members will be on the C++ stack. Just like the function parameter.

The only difference is that StAX readers function as a variant of sorts. So
they have to store a byte that tells what kind of data is in the variant.
For SAX parsers, that's handled implicitly.

One byte is not much.

It should also be noted that SAX for parsing has other problems.
Specifically, it's terrible at handling errors. The only thing it can do is
throw; by contrast, a StAX reader is capable of using error
codes/`expected` or various other mechanisms to represent malformed input.

> > > Pull APIs allow you to structure your code in a way that is
> structured. You get in a value. You test what it is. You then pass call a
> function to process that kind of data, passing it the StAX reader. That
> function reads more values, recursively descending through the JSON in a
> manner reminiscent of a recursive descent parser.
>
> You are thinking of a use-case where you are not creating/using a generic
> JSON value, but a JSON value with a specific schema and you are skipping
> the JSON level, directly using the structure you are expecting, right? I
> can see how the StAX approach is helpful there, but...
>
> > If you're referring to this post, those are examples of trivial things
> that don't need state, or whose state is trivial. "stringify" and
> "prettify" do the same operation on the same things, no matter where they
> appear in the JSON hierarhcy. Yes, SAX shines in such circumstances.
> >
> > But these are not useful circumstances for parsing JSON files. Generally
> speaking, the way you interpret data depends on how that data was
> interpreted before you.
>
> ...you are the one who defines for other what are "useful" circumstances??
> You can't just declare everyone else's use-cases as "not useful" and only
> your own as "useful".


My issue is not merely one of "useful" vs. "not useful". It's a question of
"easy" vs. "hard." And you cannot deny that `stringify` and `prettify` are
far easier than "process glTF", as far as tasks go.

For me, your use-case never came up. In fact the most important use-case to
> me is:
>
> * Construct json::value instances with an std::initializer_list directly
> in the code. (More information was in the presentation I linked earlier)
>
* Stringify the value.
>
* Efficiency - it must be *very* fast.
>

I see no reason why the StAX approach would be any slower than the SAX
approach.

I don't think a StAX approach would benefit me.


And I'm quite sure a SAX approach would not benefit me. The difference is
that an StAX approach would not *harm* you. Whereas a SAX approach very
much would harm me. To you, StAX is a lateral move; to me, it's the
difference between sane code and a lot of boilerplate.

It should also be noted that SAX, in its original XML definition
<https://en.wikipedia.org/wiki/Simple_API_for_XML>, doesn't have a
"writing" form. SAX is purely a parsing mechanism; generating textual XML,
or JSON in this case, is not an operation that SAX handles.

What you're really talking about with your SAX "writer" is JSON *visitation*,
a recursive-descent pass over a JSON C++ data structure which gets called
appropriately. Now, given that JSON defines a recursive variant data
structure, recursive visitation of that data structure is a perfectly
legitimate operation. But this should not be considered the same sort of
thing as parsing or writing. While obviously you can *use* it to do
writing, that's merely one application of recursive visitation.

So I say we should have the following tools:

1: A JSON DOM (for want of a better term): A C++ data structure that
represents the recursive variant concept defined by JSON.

2: The ability to apply a recursive visitor over a JSON DOM. Perhaps even
with the ability to change the visitation object at different levels, but
that's more of a wish-list feature than a requirement.

3: A StAX-style reader for processing text that is formatted in accord with
JSON. The purpose of this object is to read data from a JSON file,
typically into arbitrary data structures rather than the JSON DOM.

4: A StAX-style writer for generating text from JSON data. This is not
something you can directly manipulate formatting issues like pretty
printing and the like. But it should have options for that sort of thing.
The purpose of this object is to write data to a JSON file, where the
source data is not in the JSON DOM data structure.

5: A function that takes a reader and builds a JSON DOM of the data being
read.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/59784e15-6e8b-4c0e-a38f-0a29b582eb17%40isocpp.org.

------=_Part_411_1464195096.1488527345681
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 2, 2017 at 4:57:05 PM UTC-5, Daniel Fre=
y wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
&gt; On 2 Mar 2017, at 21:37, Nicol Bolas &lt;<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"qotg4u8WCgAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;=20
<br>&gt; On Thursday, March 2, 2017 at 3:01:12 PM UTC-5, Daniel Frey wrote:
<br>&gt; &gt; &gt; On 2 Mar 2017, at 20:41, Nicol Bolas &lt;<a>jmck...@gmai=
l.com</a>&gt; wrote:=20
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; I have a working understanding of SAX-style interfaces. =
My problem with SAX-style interfaces is that it forces you to implement a s=
tate machine, because all data is routed through a single object.=20
<br>&gt;=20
<br>&gt; &gt; No.
<br>&gt;=20
<br>&gt; Um... yes? Your examples show precisely that interface. Every time=
 the parser reaches a new JSON value, you get a function call in that objec=
t. And therefore, it must forward that information to the place where it wi=
ll actually be processed.
<br>
<br>The &quot;No&quot; refers to &quot;forces you to implement a state mach=
ine&quot;. You make a general claim that is simply not true. In some use-ca=
ses you might need a state machine, and in those use-cases the StAX approac=
h might work better. But it&#39;s a trade-off, not a clear win. You are pes=
simizing other use-cases where the intermediate generic value (and a switch=
 on the type) is not needed. An example would be a pretty printer.</blockqu=
ote><div><br>The problem with tossing that example around is that it is <i>=
trivial</i>. It&#39;s so trivial that you could write it without even using=
 a framework; just take the JSON-C++ objects and walk the hierarchy, output=
ting to the stream as you go. Seriously, your `to_stream` example is <i>may=
be</i> an hour&#39;s worth of coding, assuming you have a JSON data structu=
re in C++.<br><br>Your argument seems to be that SAX makes easy things easi=
er. You&#39;re right; it does. But it also makes hard things <i>harder</i>.=
 Why should we optimize the infrastructure for tasks so easy that they bare=
ly justify that infrastructure, rather than for the hard tasks where people=
 actually need that JSON infrastructure?<br><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">Reading a file generates SAX events, passed directl=
y to the SAX pretty printer. No json::value instance (or whatever the reade=
r in the StAX case stores as its state) is created/updated.<br></blockquote=
><div><br>But it does create that data. Just not in a visible or obvious wa=
y.<br><br>A SAX-style parser puts that data on the stack when it calls one =
of your functions, since the value is now a parameter. A StAX-reader puts t=
hat data in the object. Since readers will, more likely than not, be stack =
objects, their members will be on the C++ stack. Just like the function par=
ameter.<br><br>The only difference is that StAX readers function as a varia=
nt of sorts. So they have to store a byte that tells what kind of data is i=
n the variant. For SAX parsers, that&#39;s handled implicitly.<br><br>One b=
yte is not much.<br><br>It should also be noted that SAX for parsing has ot=
her problems. Specifically, it&#39;s terrible at handling errors. The only =
thing it can do is throw; by contrast, a StAX reader is capable of using er=
ror codes/`expected` or various other mechanisms to represent malformed inp=
ut.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
&gt; &gt; &gt; Pull APIs allow you to structure your code in a way that is =
structured. You get in a value. You test what it is. You then pass call a f=
unction to process that kind of data, passing it the StAX reader. That func=
tion reads more values, recursively descending through the JSON in a manner=
 reminiscent of a recursive descent parser.=20
<br>
<br>You are thinking of a use-case where you are not creating/using a gener=
ic JSON value, but a JSON value with a specific schema and you are skipping=
 the JSON level, directly using the structure you are expecting, right? I c=
an see how the StAX approach is helpful there, but...
<br>
<br>&gt; If you&#39;re referring to this post, those are examples of trivia=
l things that don&#39;t need state, or whose state is trivial. &quot;string=
ify&quot; and &quot;prettify&quot; do the same operation on the same things=
, no matter where they appear in the JSON hierarhcy. Yes, SAX shines in suc=
h circumstances.
<br>&gt;=20
<br>&gt; But these are not useful circumstances for parsing JSON files. Gen=
erally speaking, the way you interpret data depends on how that data was in=
terpreted before you.
<br>
<br>...you are the one who defines for other what are &quot;useful&quot; ci=
rcumstances?? You can&#39;t just declare everyone else&#39;s use-cases as &=
quot;not useful&quot; and only your own as &quot;useful&quot;.</blockquote>=
<div><br>My issue is not merely one of &quot;useful&quot; vs. &quot;not use=
ful&quot;. It&#39;s a question of &quot;easy&quot; vs. &quot;hard.&quot; An=
d you cannot deny that `stringify` and `prettify` are far easier than &quot=
;process glTF&quot;, as far as tasks go.<br><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">For me, your use-case never came up. In fact the mo=
st important use-case to me is:
<br>
<br>* Construct json::value instances with an std::initializer_list directl=
y in the code. (More information was in the presentation I linked earlier)<=
br></blockquote><div></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">* S=
tringify the value.<br></blockquote><div></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">* Efficiency - it must be *very* fast.<br></blockquote><di=
v><br>I see no reason why the StAX approach would be any slower than the SA=
X approach.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
I don&#39;t think a StAX approach would benefit me.</blockquote><br>And I&#=
39;m quite sure a SAX approach would not benefit me. The difference is that=
 an StAX approach would not <i>harm</i> you. Whereas a SAX approach very mu=
ch would harm me. To you, StAX is a lateral move; to me, it&#39;s the diffe=
rence between sane code and a lot of boilerplate.<br><br>It should also be =
noted that SAX, in <a href=3D"https://en.wikipedia.org/wiki/Simple_API_for_=
XML">its original XML definition</a>, doesn&#39;t have a &quot;writing&quot=
; form. SAX is purely a parsing mechanism; generating textual XML, or JSON =
in this case, is not an operation that SAX handles.<br><br>What you&#39;re =
really talking about with your SAX &quot;writer&quot; is JSON <i>visitation=
</i>, a recursive-descent pass over a JSON C++ data structure which gets ca=
lled appropriately. Now, given that JSON defines a recursive variant data s=
tructure, recursive visitation of that data structure is a perfectly legiti=
mate operation. But this should not be considered the same sort of thing as=
 parsing or writing. While obviously you can <i>use</i> it to do writing, t=
hat&#39;s merely one application of recursive visitation.<br><br>So I say w=
e should have the following tools:<br><br>1: A JSON DOM (for want of a bett=
er term): A C++ data structure that represents the recursive variant concep=
t defined by JSON.<br><br>2: The ability to apply a recursive visitor over =
a JSON DOM. Perhaps even with the ability to change the visitation object a=
t different levels, but that&#39;s more of a wish-list feature than a requi=
rement.<br><br>3: A StAX-style reader for processing text that is formatted=
 in accord with JSON. The purpose of this object is to read data from a JSO=
N file, typically into arbitrary data structures rather than the JSON DOM.<=
br><br>4: A StAX-style writer for generating text from JSON data. This is n=
ot something you can directly manipulate formatting issues like pretty prin=
ting and the like. But it should have options for that sort of thing. The p=
urpose of this object is to write data to a JSON file, where the source dat=
a is not in the JSON DOM data structure.<br><br>5: A function that takes a =
reader and builds a JSON DOM of the data being read.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/59784e15-6e8b-4c0e-a38f-0a29b582eb17%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/59784e15-6e8b-4c0e-a38f-0a29b582eb17=
%40isocpp.org</a>.<br />

------=_Part_411_1464195096.1488527345681--

------=_Part_410_850302021.1488527345680--

.

------=_Part_588_1521368252.1488530740318
Content-Type: multipart/alternative;
 boundary="----=_Part_589_1881097522.1488530740318"

------=_Part_589_1881097522.1488530740318
Content-Type: text/plain; charset=UTF-8

Op donderdag 2 maart 2017 16:51:10 UTC+1 schreef Daniel Frey:
>
> > On 2 Mar 2017, at 10:16, Olaf wrote:
> >
> > Op woensdag 1 maart 2017 22:25:33 UTC+1 schreef Niels Lohmann:
> > There are currently dozens of libraries [json.org] written in C or C++
> solving these aspects. However, it would be of great convenience to have
> JSON be part of the C++ standard library. In particular, the wide use of
> JSON as exchange format for structured data as well as to express simple
> configuration data would could solve a lot of use cases within the C++
> standard library.
> >
> > What's the advantage of a standard-library over a third-party library
> (in this case), apart from not being a dependency?
>
> As I wrote in more detail in another mail already, a standard SAX-like
> interface would allow different libraries or parts to be mixed by the user
> as needed. With existing libraries it is often the choice between
> either/or.
>

Standard interfaces are nice to have but that doesn't mean it has to be
part of ISO C++..

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/afd18952-c371-47a2-8dc1-ba654a63ce67%40isocpp.org.

------=_Part_589_1881097522.1488530740318
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Op donderdag 2 maart 2017 16:51:10 UTC+1 schreef Daniel Fr=
ey:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">&gt; On 2 Mar 2017, at 10:1=
6, Olaf wrote:
<br>&gt;=20
<br>&gt; Op woensdag 1 maart 2017 22:25:33 UTC+1 schreef Niels Lohmann:
<br>&gt; There are currently dozens of libraries [<a href=3D"http://json.or=
g" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http:=
//www.google.com/url?q\x3dhttp%3A%2F%2Fjson.org\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNH6GHLj2q4_Ao1l2Xd4-wR9sDnARA&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fjson.org\x26sa\x3=
dD\x26sntz\x3d1\x26usg\x3dAFQjCNH6GHLj2q4_Ao1l2Xd4-wR9sDnARA&#39;;return tr=
ue;">json.org</a>] written in C or C++ solving these aspects. However, it w=
ould be of great convenience to have JSON be part of the C++ standard libra=
ry. In particular, the wide use of JSON as exchange format for structured d=
ata as well as to express simple configuration data would could solve a lot=
 of use cases within the C++ standard library.=20
<br>&gt;=20
<br>&gt; What&#39;s the advantage of a standard-library over a third-party =
library (in this case), apart from not being a dependency?=20
<br>
<br>As I wrote in more detail in another mail already, a standard SAX-like =
interface would allow different libraries or parts to be mixed by the user =
as needed. With existing libraries it is often the choice between either/or=
..
<br></blockquote><div><br></div><div>Standard interfaces are nice to have b=
ut that doesn&#39;t mean it has to be part of ISO C++..=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/afd18952-c371-47a2-8dc1-ba654a63ce67%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/afd18952-c371-47a2-8dc1-ba654a63ce67=
%40isocpp.org</a>.<br />

------=_Part_589_1881097522.1488530740318--

------=_Part_588_1521368252.1488530740318--

.

------=_Part_518_1256187984.1488531704150
Content-Type: multipart/alternative;
 boundary="----=_Part_519_10256139.1488531704150"

------=_Part_519_10256139.1488531704150
Content-Type: text/plain; charset=UTF-8

Op donderdag 2 maart 2017 23:29:09 UTC+1 schreef Domen Vrankar:
>
> Regarding external libraries - at the company where I work there was a
> veto on Boost libraries already before my time and the ban still stands
> (argument was that requiring to patch Boost before compiling it with xlC_r
> IBM compiler on AIX is not stable enough). In the end in my case it's
> easier to get a newer version of the compiler than to get a new library
> into a project (and IBM with poorly implemented C++11 support in their
> compiler on AIX surely doesn't help when arguing for the language). That's
> the state of things from where I stand.
>

If IBM can't be bothered to implement C++11 properly what's the chance
they'll bother implementing a much larger standard library properly?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/751befa1-a71e-4063-8180-c27aff1c9573%40isocpp.org.

------=_Part_519_10256139.1488531704150
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Op donderdag 2 maart 2017 23:29:09 UTC+1 schreef Domen Vra=
nkar:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Reg=
arding external libraries - at the company where I work there was a veto on=
 Boost libraries already before my time and the ban still stands (argument =
was that requiring to patch Boost before compiling it with xlC_r IBM compil=
er on AIX is not stable enough). In the end in my case it&#39;s easier to g=
et a newer version of the compiler than to get a new library into a project=
 (and IBM with poorly implemented C++11 support in their compiler on AIX su=
rely doesn&#39;t help when arguing for the language). That&#39;s the state =
of things from where I stand.</div></div></blockquote><div><br></div><div>I=
f IBM can&#39;t be bothered to implement C++11 properly what&#39;s the chan=
ce they&#39;ll bother implementing a much larger standard library properly?=
</div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/751befa1-a71e-4063-8180-c27aff1c9573%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/751befa1-a71e-4063-8180-c27aff1c9573=
%40isocpp.org</a>.<br />

------=_Part_519_10256139.1488531704150--

------=_Part_518_1256187984.1488531704150--

.

------=_Part_543_1024066562.1488533277105
Content-Type: multipart/alternative;
 boundary="----=_Part_544_1027590209.1488533277105"

------=_Part_544_1027590209.1488533277105
Content-Type: text/plain; charset=UTF-8



Op donderdag 2 maart 2017 22:26:47 UTC+1 schreef Tony V E:
>
> I think that may be it. (I probably forgot something). That's core.
>
> Having said that, the other question is:
> Should the STL only do core?
>
> Robert has some good reasons for 'yes'. I agree.
> There are also good reasons for 'no':
> 1. other languages ship with more in the box
> 2. we have no good or (de facto) standard way to manage library packages.
> 3. Picking the right non-standard library takes time - just try starting a
> new Web project - with a new UI paradigm each week, there are too many
> choices - literally too many to be able to make an informed choice.
>
> If we could do 2, that might lessen the need for 1.
> Boost helps with 3. And 2 somewhat (and thus 1)
>

Including some libraries in the standard isn't solving #2.
Most (if not all) programs require third-party libraries, so #2 is a
problem worth working on.

Other languages do ship with more in the box but that box is not an ISO
standard. What box are we talking about anyway?

I think #2 is more of a problem of library development, maintenance,
especially long term, and distribution.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3204c11d-6fe8-4331-b6b8-d1eba463188d%40isocpp.org.

------=_Part_544_1027590209.1488533277105
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Op donderdag 2 maart 2017 22:26:47 UTC+1 schreef T=
ony V E:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I think that may be it=
.. (I probably forgot something). That&#39;s core.
<br>
<br>Having said that, the other question is:
<br>Should the STL only do core?
<br>
<br>Robert has some good reasons for &#39;yes&#39;. I agree.=C2=A0
<br>There are also good reasons for &#39;no&#39;:
<br>1. other languages ship with more in the box
<br>2. we have no good or (de facto) standard way to manage library package=
s.
<br>3. Picking the right non-standard library takes time - just try startin=
g a new Web project - with a new UI paradigm each week, there are too many =
choices - literally too many to be able to make an informed choice.
<br>
<br>If we could do 2, that might lessen the need for 1.
<br>Boost helps with 3. And 2 somewhat (and thus 1)
<br></blockquote><div><br></div><div>Including some libraries in the standa=
rd isn&#39;t solving #2.</div><div>Most (if not all) programs require third=
-party libraries, so #2 is a problem worth working on.<br></div><div><br></=
div><div>Other languages do ship with more in the box but that box is not a=
n ISO standard. What box are we talking about anyway?</div><div><br></div><=
div>I think #2 is more of a problem of library development, maintenance, es=
pecially long term, and distribution.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3204c11d-6fe8-4331-b6b8-d1eba463188d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3204c11d-6fe8-4331-b6b8-d1eba463188d=
%40isocpp.org</a>.<br />

------=_Part_544_1027590209.1488533277105--

------=_Part_543_1024066562.1488533277105--

.

> On 3 Mar 2017, at 08:49, Nicol Bolas <jmckesson@gmail.com> wrote:
>=20
> The problem with tossing that example around is that it is trivial. It's =
so trivial that you could write it without even using a framework; just tak=
e the JSON-C++ objects and walk the hierarchy, outputting to the stream as =
you go. Seriously, your `to_stream` example is maybe an hour's worth of cod=
ing, assuming you have a JSON data structure in C++.

Great, so what I do is "trivial" and "maybe an hour's worth of coding". You=
 enjoy judging and disregarding other people's efforts?

It is far from trivial to come up with the right interface and the right im=
plementation. Why do we have element() and member() methods in the SAX inte=
rface? Why key() when we already have string()? Those are counter-measures =
against state tracking. How many other libraries track the state with a sin=
gle boolean for the stringify consumer? And get it right with arbitrary nes=
ting? But that might just be me, for you it's trivial and maybe an hour's w=
ork.

Also, just because it's trivial does not mean it's not important. In fact, =
stringify is a very fundamental thing in the JSON world. Feeding log data t=
o an ELK stack? Stringify. Writing a REST server? Stringify. My goal is to =
make the simple things simple and efficient, while making the hard things p=
ossible. I am *not* trying to make the hard things harder on purpose. If I =
can make them simpler, fine, but not when it compromises the simplicity and=
 efficiency of the simple cases. You seem to be willing to trade, or maybe =
you don't see it. But:

> A SAX-style parser puts that data on the stack when it calls one of your =
functions, since the value is now a parameter.

The data is a double, a std::int64_t, a boolean or maybe a std::string.

> A StAX-reader puts that data in the object. Since readers will, more like=
ly than not, be stack objects, their members will be on the C++ stack. Just=
 like the function parameter.
>=20
> The only difference is that StAX readers function as a variant of sorts. =
So they have to store a byte that tells what kind of data is in the variant=
.. For SAX parsers, that's handled implicitly.
>=20
> One byte is not much.

It is an enormous different to me. You need that one byte and you need to h=
old a value of different types (union, std::variant, ...). And always switc=
h on the type in the consumer. This is unneeded overhead for a lot of use-c=
ases, this is where you are pessimizing simple use-cases in order to make t=
he harder use-cases more simple. Write a JSON library using your approach a=
nd benchmark it.

> My issue is not merely one of "useful" vs. "not useful". It's a question =
of "easy" vs. "hard." And you cannot deny that `stringify` and `prettify` a=
re far easier than "process glTF", as far as tasks go.

I strongly object to the notion that a hard use-case justifies making "stri=
ngify/prettify" more complex/inefficient. See above.

> What you're really talking about with your SAX "writer" is JSON visitatio=
n, a recursive-descent pass over a JSON C++ data structure which gets calle=
d appropriately. Now, given that JSON defines a recursive variant data stru=
cture, recursive visitation of that data structure is a perfectly legitimat=
e operation. But this should not be considered the same sort of thing as pa=
rsing or writing. While obviously you can use it to do writing, that's mere=
ly one application of recursive visitation.

I am well aware that there are a lot more things that qualify as SAX produc=
ers and SAX consumers. How do you even arrive at such "conclusions"??

> So I say we should have the following tools:
>=20
> 1: A JSON DOM (for want of a better term): A C++ data structure that repr=
esents the recursive variant concept defined by JSON.
>=20
> 2: The ability to apply a recursive visitor over a JSON DOM. Perhaps even=
 with the ability to change the visitation object at different levels, but =
that's more of a wish-list feature than a requirement.

That wouldn't even clash with *also* having a SAX-visitor. If you already h=
ave a JSON DOM object, attach a StAX reader to it and use it for your hard =
use-cases. I *might* even add a reader to our library for that, but don't h=
old your breath.

> 3: A StAX-style reader for processing text that is formatted in accord wi=
th JSON. The purpose of this object is to read data from a JSON file, typic=
ally into arbitrary data structures rather than the JSON DOM.
>=20
> 4: A StAX-style writer for generating text from JSON data. This is not so=
mething you can directly manipulate formatting issues like pretty printing =
and the like. But it should have options for that sort of thing. The purpos=
e of this object is to write data to a JSON file, where the source data is =
not in the JSON DOM data structure.
>=20
> 5: A function that takes a reader and builds a JSON DOM of the data being=
 read.

Finally, I don't think this will lead to anything here and it is apparently=
 way to early for standardization. I'll stop discussing JSON libraries on t=
his list now, feel free to send pull request for my library or, even better=
, create your own. Instead of claiming your approach is better, let code sp=
eak.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/BAACADD4-C042-4224-98DF-EB9FA23047B1%40gmx.de.

.

Em quinta-feira, 2 de mar=C3=A7o de 2017, =C3=A0s 08:46:15 PST, Nicol Bolas=
 escreveu:
> I haven't investigated JSON parsers, but Reader/StAX-style APIs are
> significant in the XML parsing world. C# lives by them; XMLReader
> <https://msdn.microsoft.com/en-us/library/system.xml.xmlreader(v=3Dvs.110=
).asp
> x> and XMLWriter
> <https://msdn.microsoft.com/en-us/library/system.xml.xmlwriter(v=3Dvs.110=
).asp
> x> are the foundation of their XML processing systems. Even LibXML2 has a
> reader interface <http://xmlsoft.org/examples/index.html#xmlReader>.

Not to mention QXmlStreamReader and QXmlStreamWriter.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1874725.c80vihms7o%40tjmaciei-mobl1.

.

Em quinta-feira, 2 de mar=C3=A7o de 2017, =C3=A0s 23:49:05 PST, Nicol Bolas=
 escreveu:
> 1: A JSON DOM (for want of a better term): A C++ data structure that
> represents the recursive variant concept defined by JSON.

Prior art: QJsonDocument, QJsonObject, QJsonArray, QJsonValue:

http://doc.qt.io/qt-5/qjsondocument.html

Given that the document that QJsonDocument refers to is known to be well-
formed, there is very little need to do error checking. You can easily acce=
ss=20
any sub-object in the tree, and if one of the parents doesn't exist, you=20
simply end up with an invalid-state (not the same as null) QJsonValue.

> 2: The ability to apply a recursive visitor over a JSON DOM. Perhaps even
> with the ability to change the visitation object at different levels, but
> that's more of a wish-list feature than a requirement.

Sorry, can't help. We don't use that idiom in Qt, so I have nothing to offe=
r.

> 3: A StAX-style reader for processing text that is formatted in accord wi=
th
> JSON. The purpose of this object is to read data from a JSON file,
> typically into arbitrary data structures rather than the JSON DOM.
>=20
> 4: A StAX-style writer for generating text from JSON data. This is not
> something you can directly manipulate formatting issues like pretty
> printing and the like. But it should have options for that sort of thing.
> The purpose of this object is to write data to a JSON file, where the
> source data is not in the JSON DOM data structure.

Not available in QJsonDocument, but I have an equivalent one for CBOR. It's=
 in=20
C, though, but extremely small. And I mean *extremely*: compiled with -Os, =
the=20
parser is 3kB and the writer is 1kB. See https://01org.github.io/tinycbor/0=
..4/

> 5: A function that takes a reader and builds a JSON DOM of the data being
> read.

QJsonDocument has all of that internal.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3432230.kGPQtS90Zb%40tjmaciei-mobl1.

.

Em quinta-feira, 2 de mar=C3=A7o de 2017, =C3=A0s 10:20:17 PST, Micha=C5=82=
 Dominiak=20
escreveu:
> One particular advantage of having a library in the standard library that
> seems to be frequently overlooked is that having a thing in the standard
> guarantees at least a minimal amount of maintenance for both its interfac=
e
> *and* its implementations. A third party library's author can one day
> disappear and you might end up having to either find someone else to
> maintain that particular library you're using, or maintaining it yourself=
,
> or migrating to a different one. This is not an issue with the standard
> library (well, unless you heavily depend on <codecvt>, but that is not a
> thing, right?), since the interface will be maintained and updated for as
> long as the committee functions by the committee itself, and multiple
> implementations will exist in the wild for you to choose from.

I can turn the argument around: one of the reasons the Standard Library is=
=20
well-maintained is that it is small and limited. If we start adding things =
to=20
it, its maintenance will grow and some parts of it may become less maintain=
ed.

As you've noted, parts of the Standard Library are already like that.

And what if JSON becomes less important in 5 years' time? It wasn't that lo=
ng=20
ago that XML was more important. Remember when SOAP was important?

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4459165.H2OAbOznyv%40tjmaciei-mobl1.

.

On 03/01/2017 10:25 PM, Niels Lohmann wrote:

> I would be willing to draft a proposal based on the experience I made with my C++ JSON library [nlohmann/json]. Of course, I would be interested in your thoughts on this.

Your suggestion is going to introduce many concepts. The bulk of your
suggestion is to introduce a dynamic variable (given your emphasis on
JSON, I assume that you want to model the JavaScript dynamic variable.)

Dynamic variables introduces data structures such as heterogenous
arrays, heterogenous maps, and hierarchical containers (nested
heteregenous arrays/maps.)

The heterogenous nature of dynamic variables means that illegal
operations (e.g. appending a string to a bool) have to be handled at
run-time instead of at compile-time. Should traversal be done with
iterators or visitors? How does it integrate with std algorithms?

The hierarchical nature of dynamic variables means that they can act
as trees, which immediately raises the question why we have no tree
structures in C++ despite proposals like N3700?

Then there is the topic of JSON serialization/deserialization. You
suggest a simple DOM-like parser/generator, and others have been quick
to point out that a SAX-like parser is missing. I side with Nicol on
this. A better starting point is a pull parser (reader). Pull parsers
are like (GOF) iterators where the user explicitly requests the next
token.

   * Pull parsers can use lazy conversion, meaning that values are only
     converted into C++ basic types (e.g. integers or strings) when the
     user explicity requests it. That way we can create applications
     like JSON prettifiers that never converts anything.

   * Pull parsers can be used in parser combinators.

   * Pull parsers are easy to integrate into serialization frameworks
     such as Boost.Serialization or Cereal. This gives us the ability
     to parse JSON directly into custom C++ data structures without
     having to go through a dynamic variable.

   * Push (SAX) parsers can be build from pull parsers quite easily.

   * Full (DOM) parsers can be build from either pull or push parsers
     fairly easy.

You can find such a JSON pull parser (with Boost.Serialization
integration) at

   https://github.com/breese/trial.protocol
   http://breese.github.io/trial/protocol/trial_protocol/json.html

The above project also contains a dynamic variable (still work in
progress, hence undocumented) at:


https://github.com/breese/trial.protocol/tree/feature/dynamic/include/trial/protocol/dynamic

It appears that you, Daniel, and I have arrived independently at many
of the same solutions for the dynamic variable (my work took its offset
in the C++03 dynamic::var by Ferruccio Barletta), but we deviate
substantially on the parser side.

In summary, I believe that your suggestion is going to be larger than
you may anticipate now, so I recommend that it should be split into two:

   1. A proposal for dynamic variables, which should be completely
      independent on JSON (albeit JSON is going to figure prominently in
      the motivation section.)

   2. A proposal for JSON parsing/generation.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/675d49c6-9aeb-2484-b2b2-76f333ceede5%40mail1.stofanet.dk.

.

Em s=C3=A1bado, 4 de mar=C3=A7o de 2017, =C3=A0s 04:23:05 PST, Bjorn Reese =
escreveu:
>    * Pull parsers can use lazy conversion, meaning that values are only
>      converted into C++ basic types (e.g. integers or strings) when the
>      user explicity requests it. That way we can create applications
>      like JSON prettifiers that never converts anything.

Pull parsers can also operate in zero-copy mode and most JSON strings can=
=20
benefit from that, though the API needs to offer an option to unescape a=20
possibly-encoded string. One just has to be careful in designing the API so=
=20
that users will default to unescaping the string unless they specifically=
=20
choose the zero-copy mode to get the escaped data.

Another big benefit is that the API paradigm can be reused for other, binar=
y=20
formats, where zero-copy is even more interesting.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2859573.osgcZ99YNz%40tjmaciei-mobl1.

.

On 03/04/2017 05:26 PM, Thiago Macieira wrote:

> Pull parsers can also operate in zero-copy mode and most JSON strings can
> benefit from that, though the API needs to offer an option to unescape a
> possibly-encoded string. One just has to be careful in designing the API so
> that users will default to unescaping the string unless they specifically
> choose the zero-copy mode to get the escaped data.

I have no dereferencing operator* in my API for that reason. Instead
there are two differently named getters. The zero-copy getter is called
reader::literal() and returns a string_view. The converting getter,
called reader::value<R>(), converts the content to an object of type R
and returns that.

> Another big benefit is that the API paradigm can be reused for other, binary
> formats, where zero-copy is even more interesting.

Absolutely agree.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/954961a9-5b89-10f2-e1bf-0a06891a7292%40mail1.stofanet.dk.

.

On 2017-03-03 12:01, Daniel Frey wrote:
> On 3 Mar 2017, at 08:49, Nicol Bolas <jmckesson@gmail.com> wrote:
>> The problem with tossing that example around is that it is trivial.
>> It's so trivial that you could write it without even using a
>> framework; just take the JSON-C++ objects and walk the hierarchy,=20
>> outputting to the stream as you go. Seriously, your `to_stream`
>> example is maybe an hour's worth of coding, assuming you have a
>> JSON data structure in C++.
>=20
> Great, so what I do is "trivial" and "maybe an hour's worth of=20
> coding". You enjoy judging and disregarding other people's efforts?

Processing JSON from an arbitrary source to convert it to a
pretty-printed string, *without an intermediary representation*, is
useful to... jsonlint. I'll certainly challenge you to name another.

The majority of applications that consume data from JSON are going to
expect that data to conform to some sort of schema in order to map to
some internal data structure. A SAX-style parser for these uses =E2=80=94 *=
which
are the majority* =E2=80=94 is clunky at best. If they don't just read the
entire input data as a JSON object=C2=B9 and deal with it as a structured C=
++
object once it's in memory, a pull-style API is much more usable.

(=C2=B9 The library implementation is free to use SAX for that, but that's =
an
*implementation detail*, not the API that consumers are expected to use.)

And yes, writing a pretty-printer (on top of an existing API) is
trivial. It's the parsing equivalent of "hello world". (Note that that
comment was not in reference to writing the implementation of the
SAX-like API, it was in reference to writing the just-about-only program
for which said API is not a poor fit.)

> Also, just because it's trivial does not mean it's not important.

True, but that functionality is almost certainly part of the library,
not something that consumers have to write themselves. Even if that's
not the case, SAX-like parsing has nothing to do with traversing an
existing in-memory representation, which is what you are almost always
doing when you want to serialize JSON (as a string or otherwise).

I repeat: just about the only time you will ever want to convert from an
input stream directly to a JSON string, *without* using the data in some
application-specific internal representation in between those steps, is
when you are jsonlint.

> My goal is to make the simple things simple and efficient, while
> making the hard things possible. I am *not* trying to make the hard
> things harder on purpose. If I can make them simpler, fine, but not
> when it compromises the simplicity and efficiency of the simple=20
> cases. You seem to be willing to trade.

I am certainly willing to trade simplicity of the cases that I actually
care about for simplicity of cases I don't! You seem to be focused on
making the simplest case, which only 0.01% of users will actually use,
as fast as possible, even though it makes life much harder for 99.99% of
users.

That's nice for doing something "because you can", as a benchmark, as a
proof of concept, etc., but it's not useful for a library meant to be
used by many people.

>> My issue is not merely one of "useful" vs. "not useful". It's a=20
>> question of "easy" vs. "hard." And you cannot deny that `stringify`
>> and `prettify` are far easier than "process glTF", as far as tasks
>> go.
>=20
> I strongly object to the notion that a hard use-case justifies making
> "stringify/prettify" more complex/inefficient.

I strongly object to the notion that optimization of a rare use case
justifies making the common use case more complex. I'd rather have a
library that is a little slower but makes it easy to write readable code
than a library that is faster but makes it much harder to write useful
code. In much the same manner, I prefer to write programs in C++ (or
even Python), rather than assembly.

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/58BDBC85.5050600%40gmail.com.

.

> On 6 Mar 2017, at 20:46, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote=
:
>=20
> On 2017-03-03 12:01, Daniel Frey wrote:
>> On 3 Mar 2017, at 08:49, Nicol Bolas <jmckesson@gmail.com> wrote:
>>> The problem with tossing that example around is that it is trivial.
>>> It's so trivial that you could write it without even using a
>>> framework; just take the JSON-C++ objects and walk the hierarchy,=20
>>> outputting to the stream as you go. Seriously, your `to_stream`
>>> example is maybe an hour's worth of coding, assuming you have a
>>> JSON data structure in C++.
>>=20
>> Great, so what I do is "trivial" and "maybe an hour's worth of=20
>> coding". You enjoy judging and disregarding other people's efforts?
>=20
> Processing JSON from an arbitrary source to convert it to a
> pretty-printed string, *without an intermediary representation*, is
> useful to... jsonlint. I'll certainly challenge you to name another.

Please at least read what we were talking about (you even quoted it above).

The example was not about taking an input stream and pretty-printing it wit=
hout an intermediate representation, it was about walking a JSON-C++ object=
 and stringify/prettify it to a stream. And as I wrote, the use-cases in my=
 case are REST servers and feeding data to an ELK stack.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/D45E569F-227F-4E45-A675-92938B9FA087%40gmx.de.

.

On 2017-03-02 16:26, Tony V E wrote:
> Should the STL only do core?
>=20
> Robert has some good reasons for 'yes'. I agree.=20
> There are also good reasons for 'no':
> 1. other languages ship with more in the box
> 2. we have no good or (de facto) standard way to manage library packages.
> 3. Picking the right non-standard library takes time.
>=20
> If we could do 2, that might lessen the need for 1.

I agree with Olaf; #2 is a real issue. It's not entirely clear if this
is within WG21's domain to try to solve, but solving it would certainly
benefit the software ecosystem as a whole. Certainly it helps with #1,
by blurring the lines between what is "the box" and what is outside the
box. (I would guess a lot of what seems to be "in the box" in some other
languages, actually isn't, but only appears to be by virtue of decent
packaging and distribution tools and a tendency to slurp down a lot of
technically third party stuff in default installs of the core language
tools.)

The biggest reason to limit the scope of the C++ libraries is that being
in an ISO standard makes it harder to change things later. Imagine what
Qt would look like now if it had needed to maintain compatibility with
the API it had 10+ years ago.

As far as #2... there are two facets of the problem; distribution, and
consumption. On the consumption side, CPS=C2=B9 might help, if it can be
completed enough to be useful and if enough users adopt it.

(=C2=B9 https://github.com/mwoehlke/cps =E2=80=94 note that this is still i=
n its
infancy; there *will* be breaking changes before 1.0! That said, anyone
wanting to help is more than welcome!)

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/58BDC10C.80300%40gmail.com.

.

On 2017-03-06 14:59, Daniel Frey wrote:
> On 6 Mar 2017, at 20:46, Matthew Woehlke wrote:
>> On 2017-03-03 12:01, Daniel Frey wrote:
>>> On 3 Mar 2017, at 08:49, Nicol Bolas <jmckesson@gmail.com> wrote:
>>>> The problem with tossing that example around is that it is trivial.
>>>> It's so trivial that you could write it without even using a
>>>> framework; just take the JSON-C++ objects and walk the hierarchy,=20
>>>> outputting to the stream as you go. Seriously, your `to_stream`
>>>> example is maybe an hour's worth of coding, assuming you have a
>>>> JSON data structure in C++.
>>>
>>> Great, so what I do is "trivial" and "maybe an hour's worth of=20
>>> coding". You enjoy judging and disregarding other people's efforts?
>>
>> Processing JSON from an arbitrary source to convert it to a
>> pretty-printed string, *without an intermediary representation*, is
>> useful to... jsonlint. I'll certainly challenge you to name another.
>=20
> Please at least read what we were talking about (you even quoted it above=
).
>=20
> The example was not about taking an input stream and pretty-printing
> it without an intermediate representation, it was about walking a
> JSON-C++ object and stringify/prettify it to a stream.

I think you are successfully making this thread confusing. The earlier
posts were mainly about the benefits and drawbacks of a SAX-like
approach to consuming an unstructured JSON stream=C2=B9 vs. other approache=
s
(e.g. DOM-like, StAX-like). SAX-like only applies to this sort of
processing.

Once you have an in-memory representation, you are not doing SAX-like
processing, you are doing visitation, which is a problem that merits a
more general solution than processing just JSON... and I'm absolutely
unconvinced that a *recursive* visitor is optimal there, for any case
besides outputting.

The question was whether SAX-like processing is a reasonable approach to
either immediate processing of JSON data or getting from a raw
stream/bag of bytes to a user defined in-memory representation (which is
a subset of immediate processing, but the most common case). The
assertion is that it is clunky for anything but direct conversion to
another output stream (i.e. jsonlint) or a generic representation (e.g.
constructing a DOM-like representation). Neither of these are features
useful to *most consumers* of a JSON library, although the latter case
may be a useful means of *implementing* a JSON library.

I have not yet seen an example of where SAX-like parsing of raw JSON
data would be superior approach *for a consumer*. The only plausible
examples I've seen are for library implementations.

(=C2=B9 Meaning, a bag or stream of bytes, presumed to contain valid JSON,
but not yet converted to any in-memory representation, such as from a
raw string, file, network stream, etc.)

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/58BDC86E.3050909%40gmail.com.

.

On Mon, Mar 6, 2017 at 2:37 PM, Matthew Woehlke
<mwoehlke.floss@gmail.com> wrote:
>
> I have not yet seen an example of where SAX-like parsing of raw JSON
> data would be superior approach *for a consumer*. The only plausible
> examples I've seen are for library implementations.

Example, parsing RESTful payload which is a list of
sha1 with rapidjson:

  https://github.com/lichray/cpp-deuceclient/blob/master/src/json_parsers.cc

We have other things parsing/producing msgpack on
the fly as well.

Seriously, all structured, API style JSON should be done
in SAX.  And about your comment:

  "You seem to be focused on making the simplest case,
   which only 0.01% of users will actually use, as fast as
   possible, even though it makes life much harder for
   99.99% of users."

I don't think anybody argued against having a
DOM interface, we are just saying an SAX interface
is necessary, otherwise I won't even bother a bit
-- how do I care a bit when 99.99% of my throughput
are processed with SAX while the coming standard
JSON utility has no such support?

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuBsDfASyGVSYNf-smDZmDMS1LbXenAp39e1pj2O2s0H6g%40mail.gmail.com.

.

On 2017-03-06 16:18, Zhihao Yuan wrote:
> On Mon, Mar 6, 2017 at 2:37 PM, Matthew Woehlke wrote:
>> I have not yet seen an example of where SAX-like parsing of raw JSON
>> data would be superior approach *for a consumer*. The only plausible
>> examples I've seen are for library implementations.
>
> Example, parsing RESTful payload which is a list of
> sha1 with rapidjson:
>
>   https://github.com/lichray/cpp-deuceclient/blob/master/src/json_parsers.cc
>
> Seriously, all structured, API style JSON should be done
> in SAX.

Wow... that's parsing a list of homogeneous values, and *even that* is
ugly? No, thanks.

> I don't think anybody argued against having a DOM interface, we are
> just saying an SAX interface is necessary,

....but *why*? Because DOM-like is too slow/heavy? But if that's the
case, why would you want a horribly clunky SAX-like interface when
StAX-like can also be fast but is MUCH more friendly to use?

Compare your above example to:

  try {
    s.begin_array();
    while (!s.at_end()) {
      handle(s.get_string());
    }
    s.pop();
  } catch (...) { ... }

....and I didn't have to write state management code or a template
conforming to the SAX handler. My StAX-style code is shorter than your
SAX-style code *by an order of magnitude*. If I need to parse
sub-objects, I just pass the parser to a function to handle the
sub-object. With SAX-style parsing, handling sub-objects is ugly and
painful.

See also https://github.com/mwoehlke/odf2txt/blob/master/odf2txt. I
manage to muddle through by having a "base" parser that implements the
SAX API that wraps a second "active" parser that is part of a stack that
allows me to push/pop parsers to handle context, but I would never call
this an "easy" approach. It's an ugly, awkward approach that is *forced
on me* by the SAX design.

State management code should live in *one* place: in the StAX-style
library. This way it only needs to be written once, not recreated by
every user, which leads to better testing and reliability, and less
overall work.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/58BDD8F9.1030806%40gmail.com.

.

On Mon, Mar 6, 2017 at 3:47 PM, Matthew Woehlke
<mwoehlke.floss@gmail.com> wrote:
> ...but *why*? Because DOM-like is too slow/heavy?

Yes.  Also, SAX defines the language, so no
extra Schema validation is needed (you can add it
of course).

> StAX-like can also be fast [...]

Prove it.

>
> Compare your above example to:
>
>   try {
>     s.begin_array();
>     while (!s.at_end()) {
>       handle(s.get_string());
>     }
>     s.pop();
>   } catch (...) { ... }
>

That happens when the next element in the array
is not a string?  Throws exception?  Please don't.
Comparing element type like XMLStreamReader?
Then you can only break out one loop at a time if
you avoid `goto`.  So far I feel more comfortable
with SAX, as you just return `false` from your
handler -- done.

> I manage to muddle through by having a "base" parser that implements the
> SAX API that wraps a second "active" parser that is part of a stack that
> allows me to push/pop parsers to handle context, but I would never call
> this an "easy" approach. It's an ugly, awkward approach that is *forced
> on me* by the SAX design.

PEGTL supports switching parsers by itself, may worth
investigation to allow it when parsing JSON.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuCd_cTvE%3D66Xq1Men85mp3%3DB4PJfo0dX2QVaosaCLOKNw%40mail.gmail.com.

.

Em segunda-feira, 6 de mar=C3=A7o de 2017, =C3=A0s 22:18:11 CET, Zhihao Yua=
n escreveu:
> On Mon, Mar 6, 2017 at 2:37 PM, Matthew Woehlke
>=20
> <mwoehlke.floss@gmail.com> wrote:
> > I have not yet seen an example of where SAX-like parsing of raw JSON
> > data would be superior approach *for a consumer*. The only plausible
> > examples I've seen are for library implementations.
>=20
> Example, parsing RESTful payload which is a list of
> sha1 with rapidjson:
>=20
>   https://github.com/lichray/cpp-deuceclient/blob/master/src/json_parsers=
..cc

And here's the equivalent using TinyCBOR, a StAX parser written in C.

struct SHA1Digest { uint8_t data[20]; };
vector<SHA1Digest> parse(vector<uint8_t> data)
{
    CborParser parser;
    CborValue array;
    cbor_parser_init(data.data(), data.size(), 0, &parser, &array);

    vector<SHA1Digest> v;
    v.resize(data.size() / sizeof(SHA1Digest));

    CborValue it;
    cbor_value_enter_container(&array, &it);
    for (int i =3D 0; !cbor_value_at_end(&it); ++i) {
        SHA1Digest &d =3D v[i];
        size_t len =3D sizeof(d.data);
        cbor_value_copy_byte_string(&it, d.data, &len, &it);
    }

    return v;
}

Let me repeat: this is a C API.

Sure, I ignored errors, because if this were a C++ API, it would either hav=
e=20
thrown or used std::expected. I also used CBOR byte strings instead of Base=
64-
encoded text strings, but that's because the decoding was not the point you=
=20
were trying to make.

> We have other things parsing/producing msgpack on
> the fly as well.
>=20
> Seriously, all structured, API style JSON should be done
> in SAX.  And about your comment:

And you've seen other people disagree with you and think StAX is better. I'=
m=20
one of those.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/12409251.KR0dDIY0ON%40tjmaciei-mobl1.

.

On Mon, Mar 6, 2017 at 5:35 PM, Thiago Macieira <thiago@macieira.org> wrote:
>
>     CborValue array;
>  [...]
>     CborValue it;
>

Quoting:

"You need that one byte and you need to hold a value of different
types (union, std::variant, ...). And always switch on the type in the
consumer. This is unneeded overhead for a lot of use-cases, this is
where you are pessimizing simple use-cases in order to make the harder
use-cases more simple. Write a JSON library using your approach and
benchmark it."

>
> And you've seen other people disagree with you and think StAX is better. I'm
> one of those.

People want unicorns in the standard.  People who
are on the horses named rapidjson and taojson
already raised concerns -- that's the kindest thing
we can do.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuDKWPgEoTk4M%2BDJ%2B7-JJfCT0i-fyXbWqXizXN-zwgjMfw%40mail.gmail.com.

.

--001a1143c7b0314890054a19db76
Content-Type: text/plain; charset=UTF-8

On Mon, Mar 6, 2017 at 2:05 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> The biggest reason to limit the scope of the C++ libraries is that being
> in an ISO standard makes it harder to change things later. Imagine what
> Qt would look like now if it had needed to maintain compatibility with
> the API it had 10+ years ago.
>

Ultimately, do you want this list to decide it shouldn't be in the
standard, or do you want the committee to decide whether or not it should
be in the standard?  If you want the committee to decide, you have to write
a proposal.

I'm certainly interested in seeing a proposal for it, and I've seen that at
least one other committee member on this list mention interest as well.  Of
course, this is just encouragement and not an endorsement, and there is
never any guarantee on what the committee will do.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNs2cJvn4XYwFZghTF%2Bz-nVQi%2B-3DX3jJcS%3DQjs%3DBnjjg%40mail.gmail.com.

--001a1143c7b0314890054a19db76
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On Mon, Mar 6, 2017 at 2:05 PM,=
 Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gma=
il.com" target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;</span> wrote:<br=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=3D":wf" =
class=3D"a3s aXjCH m15aa53a28cc6270a">The biggest reason to limit the scope=
 of the C++ libraries is that being<br>
in an ISO standard makes it harder to change things later. Imagine what<br>
Qt would look like now if it had needed to maintain compatibility with<br>
the API it had 10+ years ago.<br></div></blockquote><div>=C2=A0</div><div>U=
ltimately, do you want this list to decide it shouldn&#39;t be in the stand=
ard, or do you want the committee to decide whether or not it should be in =
the standard?=C2=A0 If you want the committee to decide, you have to write =
a proposal.</div><div><br></div><div>I&#39;m certainly interested in seeing=
 a proposal for it, and I&#39;ve seen that at least one other committee mem=
ber on this list mention interest as well.=C2=A0 Of course, this is just en=
couragement and not an endorsement, and there is never any guarantee on wha=
t the committee will do.</div><div>--=C2=A0<br></div></div><div class=3D"gm=
ail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><di=
v dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a hr=
ef=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.c=
om</a>&gt; =C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNs2cJvn4XYwFZghTF%2Bz-nVQi%2=
B-3DX3jJcS%3DQjs%3DBnjjg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%=
2BNs2cJvn4XYwFZghTF%2Bz-nVQi%2B-3DX3jJcS%3DQjs%3DBnjjg%40mail.gmail.com</a>=
..<br />

--001a1143c7b0314890054a19db76--

.

Em ter=C3=A7a-feira, 7 de mar=C3=A7o de 2017, =C3=A0s 01:27:34 CET, Zhihao =
Yuan escreveu:
> On Mon, Mar 6, 2017 at 5:35 PM, Thiago Macieira <thiago@macieira.org> wro=
te:
> >     CborValue array;
> > =20
> >  [...]
> > =20
> >     CborValue it;
>=20
> Quoting:
>=20
> "You need that one byte and you need to hold a value of different
> types (union, std::variant, ...). And always switch on the type in the
> consumer. This is unneeded overhead for a lot of use-cases, this is
> where you are pessimizing simple use-cases in order to make the harder
> use-cases more simple. Write a JSON library using your approach and
> benchmark it."

First of all, the type information is there anyway. The only difference is=
=20
whether it is exposed to the user in the API or whether it's hidden. In the=
=20
SAX case, because of the push-style API, it's hidden and the parser does th=
e=20
switching for you and calls your function.

Second, you must provide something like an iterator anyway if you want to=
=20
provide some type properties to the visited function. Properties like array=
=20
size, string length, etc. That is required if you want to implement string=
=20
zero-copy.

Third, I have written a library (albeit CBOR one) and it's extremely fast. =
The=20
advantage of using CBOR instead of JSON in this case is the ability to=20
benchmark *only* the library, since there's no malloc required to create=20
indeterminism. I'd like someone to implement a CBOR SAX-parser so we can=20
compare and contrast -- I don't think I am qualified, since I'd write it on=
 top=20
of my StAX parser and an abstraction API can't be faster than the thing it=
=20
abstracts.

Finally, did you see a switch in my code?

> > And you've seen other people disagree with you and think StAX is better=
..
> > I'm one of those.
>=20
> People want unicorns in the standard.  People who
> are on the horses named rapidjson and taojson
> already raised concerns -- that's the kindest thing
> we can do.

Sure.

Anyway, it looks to me that the proposal will need to provide both solution=
s,=20
so everyone is pleased.

Mark my words: the SAX parser will be implemented on top of the StAX one.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1631183.XVlZqFF6GK%40tjmaciei-mobl1.

.

On Tue, Mar 07, 2017 at 07:36:42AM +0100, Thiago Macieira wrote:
> Em ter=C3=A7a-feira, 7 de mar=C3=A7o de 2017, =C3=A0s 01:27:34 CET, Zhiha=
o Yuan escreveu:
> > On Mon, Mar 6, 2017 at 5:35 PM, Thiago Macieira <thiago@macieira.org> w=
rote:
> > >     CborValue array;
> > > =20
>=20
> Anyway, it looks to me that the proposal will need to provide both soluti=
ons,=20
> so everyone is pleased.
>=20
> Mark my words: the SAX parser will be implemented on top of the StAX one.

One common use of JSON is for web services were the usage pattern - as far =
as
I understand it - is that you send an initial state followed by an unbounde=
d
number of updates when some server event occurs. This implies that the data
won't be a complete JSON struct when you start parsing it since that part h=
ave
yet to be sent to you.

How does the StAX parser handle that case?

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20170307084213.GA20737%40noemi.

.

Em ter=C3=A7a-feira, 7 de mar=C3=A7o de 2017, =C3=A0s 09:42:13 CET, Magnus =
Fromreide=20
escreveu:
> One common use of JSON is for web services were the usage pattern - as fa=
r
> as I understand it - is that you send an initial state followed by an
> unbounded number of updates when some server event occurs. This implies
> that the data won't be a complete JSON struct when you start parsing it
> since that part have yet to be sent to you.
>=20
> How does the StAX parser handle that case?

It will just tell you "unexpected EOF" and allow you to supply more data=20
before retrying.

Sure, that means you need to save state to return to where you were. But I=
=20
don't think this is any more difficult than resuming the state in a SAX par=
ser:=20
if I have to exit my function in order to obtain more data, then I need to=
=20
save the parser and its state somewhere.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1529707.QLeGkty8Hg%40tjmaciei-mobl1.

.

On 2017-03-06 18:21, Zhihao Yuan wrote:
> On Mon, Mar 6, 2017 at 3:47 PM, Matthew Woehlke wrote:
>> ...but *why*? Because DOM-like is too slow/heavy?
>
> Yes. Also, SAX defines the language, so no extra Schema validation is
> needed (you can add it of course).

I'm not sure what you mean by "defines the language". (And you can do
DOM without schema validation also.)

>> StAX-like can also be fast [...]
>
> Prove it.

Prove it isn't. Trying to compare SAX to StAX is going to be heavily
dependent on the quality of implementation of either, so I'm not sure
how you'd set up a fair comparison.

Compared to DOM, however, it should be obvious that both are faster:
they are both streaming processors with limited memory overhead
(compared to DOM which parses an entire document at once and holds the
whole thing in memory). SAX still needs *some* state (internal to the
library, that is), unless it pushes the problem of grammar validation to
the consumer (yuck). StAX doesn't need much more. (Both need at least a
minimal stack.)

I could also implement StAX on top of SAX without much overhead, though
this almost certainly is not the most efficient implementation.

>> Compare your above example to:
>>
>>   try {
>>     s.begin_array();
>>     while (!s.at_end()) {
>>       handle(s.get_string());
>>     }
>>     s.pop();
>>   } catch (...) { ... }
>
> That happens when the next element in the array
> is not a string?  Throws exception?  Please don't.

That depends on the implementation. Probably you just ignore stuff that
isn't as expected (that's how I envision the above working, anyway), but
you can have implementations that throw, or do speculative reads, or...

p.s. I liked this answer [edited for grammar] from
http://stackoverflow.com/questions/7521803:

"I guess the only time I think of preferring SAX over StAX is in cases
when you don't need to handle/process XML content; e.g. the only thing
you want to do is check for well-formedness of incoming XML and just
want to handle errors if it has. [...] basically StAX is definitely the
preferable choice in scenarios where you want to handle content because
SAX content handlers are too difficult to code..."

....which essentially is exactly what I said earlier; SAX is fine when
you don't care about the structure of the data (beyond maybe indentation
level), but StAX is much easier to use otherwise.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/58C09B7A.70307%40gmail.com.

.

On 2017-03-07 01:36, Thiago Macieira wrote:
> Em ter=C3=A7a-feira, 7 de mar=C3=A7o de 2017, =C3=A0s 01:27:34 CET, Zhiha=
o Yuan escreveu:
>> People want unicorns in the standard. People who are on the horses
>> named rapidjson and taojson already raised concerns -- that's the
>> kindest thing we can do.

People want something that is easy to use. SAX may be slightly faster,
but it is much, MUCH harder to use in most cases.

SAX is like a stock F1 car: crazy fast, but the controls are complicated
and esoteric (12-step start procedure, anyone?). StAX is like an F1 car
modified for use by normal people; maybe you lose a little (not a lot)
in the performance, but you get familiar controls and amenities.

> Mark my words: the SAX parser will be implemented on top of the StAX one.

I wouldn't put money on that ;-), although I believe it's a plausible
implementation.

The "good" (note the quotes) thing about SAX is that it is very close to
a likely parser implementation.

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/58C09BBF.2000503%40gmail.com.

.

On Wed, Mar 8, 2017 at 6:02 PM, Matthew Woehlke
<mwoehlke.floss@gmail.com> wrote:
>
>> Yes. Also, SAX defines the language, so no extra Schema validation is
>> needed (you can add it of course).
>
> I'm not sure what you mean by "defines the language". (And you can do
> DOM without schema validation also.)

"Language" as a term in theory of computation, every
instance of an SAX parser defines a language that is
a subset of JSON, a JSON input that is not a member
of this language can't even be parsed; parsing can
terminate early without schema validation.  In contrast,
if no schema validation is performed before using DOM
parser, since every valid JSON representation has a
valid corresponding DOM, your service can waste lots
of resource building DOMs that are logically illegal to
your API.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuDog46VNEc17q6vhvGerwKj15sbiBi8n0PNmiCzNZPCkA%40mail.gmail.com.

.

------=_Part_479_292698760.1489048251872
Content-Type: multipart/alternative;
 boundary="----=_Part_480_1164114247.1489048251872"

------=_Part_480_1164114247.1489048251872
Content-Type: text/plain; charset=UTF-8

Have plain sequential code - use stream API (StAX).
Have async non-blocking code where you from time to time lose the control
(inversion of control) and process a chunk at once - use event-based API
(SAX).
Need random access and have no schema - tree API (DOM).

There is no one-size-fits-all solution here. We need all three.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/aa079e3a-d027-4e59-adce-9ec2f38c0f0a%40isocpp.org.

------=_Part_480_1164114247.1489048251872
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Have plain sequential code - use stream API (StAX).<br>Hav=
e async non-blocking code where you from time to time lose the control (inv=
ersion of control) and process a chunk at once - use event-based API (SAX).=
<br>Need random access and have no schema - tree API (DOM).<br><br>There is=
 no one-size-fits-all solution here. We need all three.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/aa079e3a-d027-4e59-adce-9ec2f38c0f0a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/aa079e3a-d027-4e59-adce-9ec2f38c0f0a=
%40isocpp.org</a>.<br />

------=_Part_480_1164114247.1489048251872--

------=_Part_479_292698760.1489048251872--

.

On 2017-03-08 19:38, Zhihao Yuan wrote:
> On Wed, Mar 8, 2017 at 6:02 PM, Matthew Woehlke wrote:
>> On 2017-03-06 18:21, Zhihao Yuan wrote:
>>> Yes. Also, SAX defines the language, so no extra Schema validation is
>>> needed (you can add it of course).
>>
>> I'm not sure what you mean by "defines the language". (And you can do
>> DOM without schema validation also.)
>
> "Language" as a term in theory of computation, every instance of an
> SAX parser defines a language that is a subset of JSON, a JSON input
> that is not a member of this language can't even be parsed; parsing
> can terminate early without schema validation.  In contrast, if no
> schema validation is performed before using DOM parser, since every
> valid JSON representation has a valid corresponding DOM, your service
> can waste lots of resource building DOMs that are logically illegal
> to your API.

Ah, so it isn't "SAX", it's "a particular implementation of a particular
parser *using* SAX". Anyway, this is equally true of StAX...

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/58C175AF.1070001%40gmail.com.

.

On 2017-03-09 03:30, Victor Dyachenko wrote:
> Have async non-blocking code where you from time to time lose the control
> (inversion of control) and process a chunk at once - use event-based API
> (SAX).

....or co-routines, or a blocking StAX API that can be fed from another
thread.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/58C17782.9010609%40gmail.com.

.

------=_Part_844_1280983559.1489074466065
Content-Type: multipart/alternative;
 boundary="----=_Part_845_1761841849.1489074466066"

------=_Part_845_1761841849.1489074466066
Content-Type: text/plain; charset=UTF-8

On Thursday, March 9, 2017 at 6:40:54 PM UTC+3, Matthew Woehlke wrote:
>
> On 2017-03-09 03:30, Victor Dyachenko wrote:
> > Have async non-blocking code where you from time to time lose the
> control
> > (inversion of control) and process a chunk at once - use event-based API
> > (SAX).
>
> ...or co-routines, or a blocking StAX API that can be fed from another
> thread.
>

Sure.  But I hope you don't mean "SAX is unnecessary". SAX still can be
simpler solution - it doesn't require own stack which threads or
co-routines or fibers allot us.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f352304d-3fca-4b6f-98ee-1fe2c79d0627%40isocpp.org.

------=_Part_845_1761841849.1489074466066
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 9, 2017 at 6:40:54 PM UTC+3, Matthew Wo=
ehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-03-09 03:3=
0, Victor Dyachenko wrote:
<br>&gt; Have async non-blocking code where you from time to time lose the =
control=20
<br>&gt; (inversion of control) and process a chunk at once - use event-bas=
ed API=20
<br>&gt; (SAX).
<br>
<br>...or co-routines, or a blocking StAX API that can be fed from another
<br>thread.
<br></blockquote><div><br>Sure.=C2=A0 But I hope you don&#39;t mean &quot;S=
AX is unnecessary&quot;. SAX still can be simpler solution - it doesn&#39;t=
 require own stack which threads or co-routines or fibers allot us.<br></di=
v></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f352304d-3fca-4b6f-98ee-1fe2c79d0627%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f352304d-3fca-4b6f-98ee-1fe2c79d0627=
%40isocpp.org</a>.<br />

------=_Part_845_1761841849.1489074466066--

------=_Part_844_1280983559.1489074466065--

.

On quinta-feira, 9 de mar=C3=A7o de 2017 16:47:45 CET Victor Dyachenko wrot=
e:
> Sure.  But I hope you don't mean "SAX is unnecessary". SAX still can be
> simpler solution - it doesn't require own stack which threads or
> co-routines or fibers allot us.

It requires memory allocation to keep the state while you unwind the parser=
=20
back to the function that can obtain more data.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1669599.BMfjZpDzSO%40tjmaciei-mobl1.

.

On 2017-03-04 07:23, Bjorn Reese wrote:
> Your suggestion is going to introduce many concepts. The bulk of your
> suggestion is to introduce a dynamic variable (given your emphasis on
> JSON, I assume that you want to model the JavaScript dynamic variable.)
>=20
> Dynamic variables introduces data structures such as heterogenous
> arrays, heterogenous maps, and hierarchical containers (nested
> heteregenous arrays/maps.)
>=20
> The heterogenous nature of dynamic variables means that illegal
> operations (e.g. appending a string to a bool) have to be handled at
> run-time instead of at compile-time. Should traversal be done with
> iterators or visitors? How does it integrate with std algorithms?

I implemented a (DOM-style) JSON library for Qt4. It had the following
type aliases:

  JsonValue -> QVariant
  JsonObject -> QVariantMap -> QMap<QString, QVariant>
  JsonArray -> QVariantArray -> QList<QVariant>

The STL equivalent would be:

  JsonValue -> variant<JsonObject, JsonArray, ...=C2=B9>
  JsonObject -> map<string, JsonValue>
  JsonArray -> vector<JsonValue>

Qt5 used "strong" types, but the function remains essentially the same.
(Personally, I am in favor of sticking to the basic container types
rather than implementing 'new' types with the same API, but either way
works...)

The only illegal operations handled at run-time are bad casts. If you
want to "add" two values, you write casts of the values to concrete
types that can be "added" (either mathematical addition or
concatenation, depending if they are numbers or strings), and the
application of the operator is still type safe (but the casts will fail
at run-time if the values aren't the expected type(s)). Traversal and
such is solved the same as for the generic types (map/vector/variant).

(=C2=B9 I believe the rest of the list is <string, double, bool, nullptr_t>=
,
but one can make an argument for additional numeric types. One of the
niceties of QVariant is it also supports conversion between numeric
types; you can store a value as whichever of double/int64_t/uint64_t
best preserves the input, and get it back, possibly via a lossy
conversion, as any numeric type. For this and other reasons=C2=B2, a
json_value class that is a true class and not just a variant<...> might
make sense.)

(=C2=B2 In particular, it makes a good place to hang I/O operations; the DO=
M
API can pretty well be just member functions on json_value.)

> The hierarchical nature of dynamic variables means that they can act
> as trees, which immediately raises the question why we have no tree
> structures in C++ despite proposals like N3700?

I doubt you want a "true" tree structure, because you can freely mix
numbers/strings, objects and arrays, which makes for a strange looking
"tree". I think the above approach that recursively references a 'value'
which may be an object or array makes more sense.

> In summary, I believe that your suggestion is going to be larger than
> you may anticipate now, so I recommend that it should be split into two:
>=20
>   1. A proposal for dynamic variables, which should be completely
>      independent on JSON (albeit JSON is going to figure prominently in
>      the motivation section.)

Please explain why you can't just use `variant`.

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/58C1B85F.2040502%40gmail.com.

.

------=_Part_2109_1968770729.1495369174344
Content-Type: multipart/alternative;
 boundary="----=_Part_2110_2072108305.1495369174344"

------=_Part_2110_2072108305.1495369174344
Content-Type: text/plain; charset="UTF-8"

It seems that this discussion has stalled, after diving into technical
details...

Question for Niels Lohmann and Daniel Frey: what's your opinion after all
these comments, are you yet interested in producing proposal for standard
C++ JSON library?


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2c9e360b-83a2-4dd6-adfa-e396a8b9fb57%40isocpp.org.

------=_Part_2110_2072108305.1495369174344
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It seems that this discussion has stalled, after diving in=
to technical details...<br><br>Question for Niels Lohmann and Daniel Frey: =
what&#39;s your opinion after all these comments, are you yet interested in=
 producing proposal for standard C++ JSON library?<br><br><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2c9e360b-83a2-4dd6-adfa-e396a8b9fb57%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2c9e360b-83a2-4dd6-adfa-e396a8b9fb57=
%40isocpp.org</a>.<br />

------=_Part_2110_2072108305.1495369174344--

------=_Part_2109_1968770729.1495369174344--

.

--Apple-Mail=_F53D4899-9E19-46A7-ADE4-1C28043CD18A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Hi there,

> It seems that this discussion has stalled, after diving into technical de=
tails...
>=20
> Question for Niels Lohmann and Daniel Frey: what's your opinion after all=
 these comments, are you yet interested in producing proposal for standard =
C++ JSON library?

there is a repository for this now: https://github.com/nlohmann/std_json. I=
 haven=E2=80=99t had time to spend much time on this so far, but I hope thi=
s will change. :-)

All the best,
Niels

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9D1A93F8-601B-44BD-8573-78B2A18C6765%40nlohmann.=
me.

--Apple-Mail=_F53D4899-9E19-46A7-ADE4-1C28043CD18A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename=signature.asc
Content-Type: application/pgp-signature;
 name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEeXFnrkHAptkjLkhFfzzqY64lG2kFAlkhj38ACgkQfzzqY64l
G2l9HA//WjO71ZqlgA/BVbegaH7UOKVWMLGR34XsVZbWoEaCsJZ6uISloxmayisb
2griNaUDb27+qgmGUdUSNtssgXGF9hbOHiqIV77HA2fUBlq4kIGopw4tL8AmtxKv
kmoMPePnSuusKwLuRLB+CJz3WE+lGsnKxVgYHtn7WlPQIDkyrYc/tN58ntBzs/Qf
PDeScMiPu8P74fzKybjbEdoGXSqPa9RoM57a8P1qIcJr1S3N5zAAMWrzZqgKOBeh
HcNh7Dh8v90Uf8ZAkYMxTEqPeZo4Es/lHyvLvBcucfi57maGGkWaqNtGNJXoPuIP
xg85XOjSEYnxFZvwCa7LBjaoNI9VwMo0Giiy8QU5XqZuMw5KwG+/KJWsawwYu34z
3aeDro6fqozrwJW+NqRZZHMVKBisO09JRsGk0u9xgqZnmkyQk8+5cDcqwi72WjWg
yh3SS5gBZHRiBy3zOaHu7ELCeTDM/cSbRdGVzMx0xelCwOHBY1aGqc/tLC7w69bG
GObiNklwOMyOyYbibepmS8dig72K1TJWknxWv4guP8GKol9mBoCabhC3b0GecpFP
G9yoybHYhXnaVFRwploheNZqjP4VPCUI1HKa1+Wvj8mYkDbmxiLoG5iWFBpyVt/9
zT0ezlQkhflTOHDmsZXis1vS6ueUOMD4PcI8gCxIZ/RE4L4srGI=
=biOW
-----END PGP SIGNATURE-----

--Apple-Mail=_F53D4899-9E19-46A7-ADE4-1C28043CD18A--

.

------=_Part_2252_343381057.1499140638505
Content-Type: multipart/alternative;
 boundary="----=_Part_2253_431367265.1499140638505"

------=_Part_2253_431367265.1499140638505
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello.

I want to work in the same way. I think you know about Boost.Property_tree.=
=20
It's universal library for working with json, xml, ini and other formats.=
=20
And i want see smth like this in the C++. What do you think about the idea?


Reason: Property_tree is universal represenation for data. And it's=20
universal structure for creating parsers for JSON, XML, INI, etc. I am not=
=20
sure, that si unviersal thing can work perfectly with each format (but why=
=20
not?). And if we will add to Standard something really general with parsers=
=20
for the most usable formats, it will be great!


Best regards,

Alexander Zaitsev

=D1=87=D0=B5=D1=82=D0=B2=D0=B5=D1=80=D0=B3, 2 =D0=BC=D0=B0=D1=80=D1=82=D0=
=B0 2017 =D0=B3., 0:25:33 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=
=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Niels Lohmann =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0=D0=BB:
>
> Hi there,=20
>
> I am wondering whether JSON [RFC7159] support would be a helpful extensio=
n=20
> to the C++ standard library (pure library extension), including, but not=
=20
> limited to, the following aspects:=20
>
> 1. A variant-like container type (for this mail, let's call it=20
> "std::json") that combines C++ types for the JSON value types [RFC7159,=
=20
> chapter 3]:=20
>   - string (e.g. std::string),=20
>   - number (e.g., double or int64_t),=20
>   - boolean (e.g., bool),=20
>   - array (e.g., std::vector), and=20
>   - object (e.g., std::map).=20
>
> This type should have an intuitive API (i.e., all expected container=20
> methods), but also use as much syntactic sugar as possible (e.g., using=
=20
> initializer lists to express arrays like "std::json my_array =3D {"a stri=
ng",=20
> 17, 42.12};".=20
>
> 2. A serialization function to create a textual representation (called=20
> "JSON text" in [RFC7159]) from a std::json value that conforms to the JSO=
N=20
> grammar [RFC7159, chapter 2-7].=20
>
> 3. A deserialization function (i.e., a parser) [RFC7159, chapter 9] to=20
> create a std::json value from a JSON text.=20
>
> There are currently dozens of libraries [json.org] written in C or C++=20
> solving these aspects. However, it would be of great convenience to have=
=20
> JSON be part of the C++ standard library. In particular, the wide use of=
=20
> JSON as exchange format for structured data as well as to express simple=
=20
> configuration data would could solve a lot of use cases within the C++=20
> standard library.=20
>
> I would be willing to draft a proposal based on the experience I made wit=
h=20
> my C++ JSON library [nlohmann/json]. Of course, I would be interested in=
=20
> your thoughts on this.=20
>
> All the best,=20
> Niels=20
>
> References=20
>
> [RFC7159] https://tools.ietf.org/html/rfc7159.html=20
> [json.org] http://json.org=20
> [nlohmann/json] https://github.com/nlohmann/json=20
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b13ce6ca-3a92-4159-aa4a-7b1913df90a9%40isocpp.or=
g.

------=_Part_2253_431367265.1499140638505
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello.<div><br></div><div><p style=3D"box-sizing: border-b=
ox; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont,=
 &quot;Segoe UI&quot;, Helvetica, Arial, sans-serif, &quot;Apple Color Emoj=
i&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;; font-size=
: 14px;">I want to work in the same way. I think you know about Boost.Prope=
rty_tree. It&#39;s universal library for working with json, xml, ini and ot=
her formats. And i want see smth like this in the C++. What do you think ab=
out the idea?</p><p style=3D"box-sizing: border-box; color: rgb(36, 41, 46)=
; font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Hel=
vetica, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Em=
oji&quot;, &quot;Segoe UI Symbol&quot;; font-size: 14px;"><br></p><p style=
=3D"box-sizing: border-box; color: rgb(36, 41, 46); font-family: -apple-sys=
tem, BlinkMacSystemFont, &quot;Segoe UI&quot;, Helvetica, Arial, sans-serif=
, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI=
 Symbol&quot;; font-size: 14px;">Reason: Property_tree is universal represe=
nation for data. And it&#39;s universal structure for creating parsers for =
JSON, XML, INI, etc. I am not sure, that si unviersal thing can work perfec=
tly with each format (but why not?). And if we will add to Standard somethi=
ng really general with parsers for the most usable formats, it will be grea=
t!</p><p style=3D"box-sizing: border-box; color: rgb(36, 41, 46); font-fami=
ly: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Helvetica, Ari=
al, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, =
&quot;Segoe UI Symbol&quot;; font-size: 14px;"><br></p><p style=3D"box-sizi=
ng: border-box; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMa=
cSystemFont, &quot;Segoe UI&quot;, Helvetica, Arial, sans-serif, &quot;Appl=
e Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot=
;; font-size: 14px;">Best regards,</p><p style=3D"box-sizing: border-box; c=
olor: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, &quo=
t;Segoe UI&quot;, Helvetica, Arial, sans-serif, &quot;Apple Color Emoji&quo=
t;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;; font-size: 14p=
x;">Alexander Zaitsev</p><br>=D1=87=D0=B5=D1=82=D0=B2=D0=B5=D1=80=D0=B3, 2 =
=D0=BC=D0=B0=D1=80=D1=82=D0=B0 2017 =D0=B3., 0:25:33 UTC+3 =D0=BF=D0=BE=D0=
=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Niels Lohmann =D0=
=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">Hi there,
<br>
<br>I am wondering whether JSON [RFC7159] support would be a helpful extens=
ion to the C++ standard library (pure library extension), including, but no=
t limited to, the following aspects:
<br>
<br>1. A variant-like container type (for this mail, let&#39;s call it &quo=
t;std::json&quot;) that combines C++ types for the JSON value types [RFC715=
9, chapter 3]:
<br>=C2=A0 - string (e.g. std::string),
<br>=C2=A0 - number (e.g., double or int64_t),
<br>=C2=A0 - boolean (e.g., bool),
<br>=C2=A0 - array (e.g., std::vector), and
<br>=C2=A0 - object (e.g., std::map).
<br>
<br>This type should have an intuitive API (i.e., all expected container me=
thods), but also use as much syntactic sugar as possible (e.g., using initi=
alizer lists to express arrays like &quot;std::json my_array =3D {&quot;a s=
tring&quot;, 17, 42.12};&quot;.
<br>
<br>2. A serialization function to create a textual representation (called =
&quot;JSON text&quot; in [RFC7159]) from a std::json value that conforms to=
 the JSON grammar [RFC7159, chapter 2-7].
<br>
<br>3. A deserialization function (i.e., a parser) [RFC7159, chapter 9] to =
create a std::json value from a JSON text.
<br>
<br>There are currently dozens of libraries [<a href=3D"http://json.org" ta=
rget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www=
..google.com/url?q\x3dhttp%3A%2F%2Fjson.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNH6GHLj2q4_Ao1l2Xd4-wR9sDnARA&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fjson.org\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNH6GHLj2q4_Ao1l2Xd4-wR9sDnARA&#39;;return true;">=
json.org</a>] written in C or C++ solving these aspects. However, it would =
be of great convenience to have JSON be part of the C++ standard library. I=
n particular, the wide use of JSON as exchange format for structured data a=
s well as to express simple configuration data would could solve a lot of u=
se cases within the C++ standard library.
<br>
<br>I would be willing to draft a proposal based on the experience I made w=
ith my C++ JSON library [nlohmann/json]. Of course, I would be interested i=
n your thoughts on this.
<br>
<br>All the best,
<br>Niels
<br>
<br>References
<br>
<br>[RFC7159] <a href=3D"https://tools.ietf.org/html/rfc7159.html" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.go=
ogle.com/url?q\x3dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7159.html\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFlGKieKcotlL2TKtkWvdQBMD3cjA&#39;;return =
true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A=
%2F%2Ftools.ietf.org%2Fhtml%2Frfc7159.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNFlGKieKcotlL2TKtkWvdQBMD3cjA&#39;;return true;">https://tools.ietf.=
org/html/<wbr>rfc7159.html</a>
<br>[<a href=3D"http://json.org" target=3D"_blank" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fjson.o=
rg\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH6GHLj2q4_Ao1l2Xd4-wR9sDnARA&#39=
;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3d=
http%3A%2F%2Fjson.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH6GHLj2q4_Ao1=
l2Xd4-wR9sDnARA&#39;;return true;">json.org</a>] <a href=3D"http://json.org=
" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fjson.org\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNH6GHLj2q4_Ao1l2Xd4-wR9sDnARA&#39;;return true;" onclick=3D"this=
..href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fjson.org\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNH6GHLj2q4_Ao1l2Xd4-wR9sDnARA&#39;;return tru=
e;">http://json.org</a>
<br>[nlohmann/json] <a href=3D"https://github.com/nlohmann/json" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google=
..com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fnlohmann%2Fjson\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNGH08Z3JGxD7Z5SLL_JKT5KhkfH6A&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub=
..com%2Fnlohmann%2Fjson\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGH08Z3JGxD7Z=
5SLL_JKT5KhkfH6A&#39;;return true;">https://github.com/nlohmann/<wbr>json</=
a>
<br></blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b13ce6ca-3a92-4159-aa4a-7b1913df90a9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b13ce6ca-3a92-4159-aa4a-7b1913df90a9=
%40isocpp.org</a>.<br />

------=_Part_2253_431367265.1499140638505--

------=_Part_2252_343381057.1499140638505--

.

--001a114ac0a4c9a02405537a3a86
Content-Type: text/plain; charset="UTF-8"

2017-07-04 5:57 GMT+02:00 <zamazan4ik@gmail.com>:

> Hello.
>
> I want to work in the same way. I think you know about
> Boost.Property_tree. It's universal library for working with json, xml, ini
> and other formats. And i want see smth like this in the C++. What do you
> think about the idea?
>
>
> Reason: Property_tree is universal represenation for data. And it's
> universal structure for creating parsers for JSON, XML, INI, etc. I am not
> sure, that si unviersal thing can work perfectly with each format (but why
> not?). And if we will add to Standard something really general with parsers
> for the most usable formats, it will be great!
>
In that case I'd expect something like std::tree (or boost graph library?
never used it but it sounds like something that would be useful for
traversing the structure) to be standardized and I'm guessing that there's
a reason it hasn't been done since std::filesystem was accepted and even
though filesystem is a tree structure (could be viewed as XML DOM or Json
hierarchy) and std::filesystem::path could be viewed as similar to XPath in
XML we still don't have something like std::tree or tree iterators.

Regards,
Domen

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BLL_Sz5hWRQ%2BZDgFT51E3tmsvmouCs8qW0vsq6twmHZzg%40mail.gmail.com.

--001a114ac0a4c9a02405537a3a86
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">2017-07-04 5:57 GMT+02:00  <span dir=3D"ltr">&lt;<a href=
=3D"mailto:zamazan4ik@gmail.com" target=3D"_blank">zamazan4ik@gmail.com</a>=
&gt;</span>:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hello.<div><b=
r></div><div><p style=3D"box-sizing:border-box;color:rgb(36,41,46);font-fam=
ily:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,Helvetica,Arial,s=
ans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,&quot;Se=
goe UI Symbol&quot;;font-size:14px">I want to work in the same way. I think=
 you know about Boost.Property_tree. It&#39;s universal library for working=
 with json, xml, ini and other formats. And i want see smth like this in th=
e C++. What do you think about the idea?</p><p style=3D"box-sizing:border-b=
ox;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,&quot;S=
egoe UI&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quo=
t;Segoe UI Emoji&quot;,&quot;Segoe UI Symbol&quot;;font-size:14px"><br></p>=
<p style=3D"box-sizing:border-box;color:rgb(36,41,46);font-family:-apple-sy=
stem,BlinkMacSystemFont,&quot;Segoe UI&quot;,Helvetica,Arial,sans-serif,&qu=
ot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,&quot;Segoe UI Symbol=
&quot;;font-size:14px">Reason: Property_tree is universal represenation for=
 data. And it&#39;s universal structure for creating parsers for JSON, XML,=
 INI, etc. I am not sure, that si unviersal thing can work perfectly with e=
ach format (but why not?). And if we will add to Standard something really =
general with parsers for the most usable formats, it will be great!</p></di=
v></div></blockquote>In that case I&#39;d expect something like std::tree (=
or boost graph library? never used it but it sounds like something that wou=
ld be useful for traversing the structure) to be standardized and I&#39;m g=
uessing that there&#39;s a reason it hasn&#39;t been done since std::filesy=
stem was accepted and even though filesystem is a tree structure (could be =
viewed as XML DOM or Json hierarchy) and std::filesystem::path could be vie=
wed as similar to XPath in XML we still don&#39;t have something like std::=
tree or tree iterators.<br><br></div><div class=3D"gmail_quote">Regards,<br=
></div><div class=3D"gmail_quote">Domen<br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKgx6BLL_Sz5hWRQ%2BZDgFT51E3tmsvmouC=
s8qW0vsq6twmHZzg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BLL_Sz5hW=
RQ%2BZDgFT51E3tmsvmouCs8qW0vsq6twmHZzg%40mail.gmail.com</a>.<br />

--001a114ac0a4c9a02405537a3a86--

.

------=_Part_2402_1278557388.1499177077030
Content-Type: multipart/alternative;
 boundary="----=_Part_2403_611586201.1499177077030"

------=_Part_2403_611586201.1499177077030
Content-Type: text/plain; charset="UTF-8"



On Monday, July 3, 2017 at 11:57:18 PM UTC-4, Alexander Zaitsev wrote:
>
> Hello.
>
> I want to work in the same way. I think you know about
> Boost.Property_tree. It's universal library for working with json, xml, ini
> and other formats.
>

NO! No, it isn't!

Property Trees are for working with *property trees*. It is not some
"universal library" for handling JSON, XML and such. Its JSON and XML
reading abilities are tailored specifically to JSON and XML that it wrote
itself.

That library is not meant to consume arbitrary JSON or XML.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b27db942-3e8b-4251-891f-36244789d399%40isocpp.org.

------=_Part_2403_611586201.1499177077030
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, July 3, 2017 at 11:57:18 PM UTC-4, Alex=
ander Zaitsev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Hello.<div><br></div><div><p style=3D"color:rgb(36,41,46);font-fam=
ily:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,Helvetica,Arial,s=
ans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,&quot;Se=
goe UI Symbol&quot;;font-size:14px">I want to work in the same way. I think=
 you know about Boost.Property_tree. It&#39;s universal library for working=
 with json, xml, ini and other formats.</p></div></div></blockquote><div><b=
r>NO! No, it isn&#39;t!<br><br>Property Trees are for working with <i>prope=
rty trees</i>. It is not some &quot;universal library&quot; for handling JS=
ON, XML and such. Its JSON and XML reading abilities are tailored specifica=
lly to JSON and XML that it wrote itself.<br><br>That library is not meant =
to consume arbitrary JSON or XML.</div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b27db942-3e8b-4251-891f-36244789d399%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b27db942-3e8b-4251-891f-36244789d399=
%40isocpp.org</a>.<br />

------=_Part_2403_611586201.1499177077030--

------=_Part_2402_1278557388.1499177077030--

.

------=_Part_950_497585493.1500242233242
Content-Type: multipart/alternative;
 boundary="----=_Part_951_1470028621.1500242233242"

------=_Part_951_1470028621.1500242233242
Content-Type: text/plain; charset="UTF-8"

My wishlist:

https://github.com/nlohmann/std_json/issues/5

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/07b4ac02-d448-4ed3-9960-3f9d342b4f3a%40isocpp.org.

------=_Part_951_1470028621.1500242233242
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>My wishlist:</div><div><br></div><div>https://github.=
com/nlohmann/std_json/issues/5=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/07b4ac02-d448-4ed3-9960-3f9d342b4f3a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/07b4ac02-d448-4ed3-9960-3f9d342b4f3a=
%40isocpp.org</a>.<br />

------=_Part_951_1470028621.1500242233242--

------=_Part_950_497585493.1500242233242--

.

--0000000000008647a7056f786fc0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Niels,

I=E2=80=99ve been looking into your library on github that is in response t=
o this
discussion.  JSON handling is something I feel we desperately need to move
forward in the next C++ revisions.  Have you started the proposal process
with your libraries yet?  I could not find any papers in the isocpp
mailings.

Im just getting back to being involved with the committee after a few years
off.

-Neal Meyer


On Wed, Mar 1, 2017 at 1:25 PM Niels Lohmann <mail@nlohmann.me> wrote:

> Hi there,
>
> I am wondering whether JSON [RFC7159] support would be a helpful extensio=
n
> to the C++ standard library (pure library extension), including, but not
> limited to, the following aspects:
>
> 1. A variant-like container type (for this mail, let's call it
> "std::json") that combines C++ types for the JSON value types [RFC7159,
> chapter 3]:
>   - string (e.g. std::string),
>   - number (e.g., double or int64_t),
>   - boolean (e.g., bool),
>   - array (e.g., std::vector), and
>   - object (e.g., std::map).
>
> This type should have an intuitive API (i.e., all expected container
> methods), but also use as much syntactic sugar as possible (e.g., using
> initializer lists to express arrays like "std::json my_array =3D {"a stri=
ng",
> 17, 42.12};".
>
> 2. A serialization function to create a textual representation (called
> "JSON text" in [RFC7159]) from a std::json value that conforms to the JSO=
N
> grammar [RFC7159, chapter 2-7].
>
> 3. A deserialization function (i.e., a parser) [RFC7159, chapter 9] to
> create a std::json value from a JSON text.
>
> There are currently dozens of libraries [json.org] written in C or C++
> solving these aspects. However, it would be of great convenience to have
> JSON be part of the C++ standard library. In particular, the wide use of
> JSON as exchange format for structured data as well as to express simple
> configuration data would could solve a lot of use cases within the C++
> standard library.
>
> I would be willing to draft a proposal based on the experience I made wit=
h
> my C++ JSON library [nlohmann/json]. Of course, I would be interested in
> your thoughts on this.
>
> All the best,
> Niels
>
> References
>
> [RFC7159] https://tools.ietf.org/html/rfc7159.html
> [json.org] http://json.org
> [nlohmann/json] https://github.com/nlohmann/json
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3DF8137F-C90=
E-4D25-96AB-FF8B766418DF%40nlohmann.me
> .
>
--=20
-Neal

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAC2GhWVHd%3DrmQVenWZYihR7%2Bfz56NUmdNNx%3DiAr%3=
DQTcKFhuCzw%40mail.gmail.com.

--0000000000008647a7056f786fc0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><div dir=3D"auto">Niels,</div></div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">I=E2=80=99ve been looking into your library on github that is i=
n response to this discussion.=C2=A0 JSON handling is something I feel we d=
esperately need to move forward in the next C++ revisions.=C2=A0 Have you s=
tarted the proposal process with your libraries yet?=C2=A0 I could not find=
 any papers in the isocpp mailings. =C2=A0</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">Im just getting back to being involved with the committe=
e after a few years off.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">-Neal Meyer</div><div dir=3D"auto"><br></div><div><br><div class=3D"=
gmail_quote"><div dir=3D"ltr">On Wed, Mar 1, 2017 at 1:25 PM Niels Lohmann =
&lt;<a href=3D"mailto:mail@nlohmann.me">mail@nlohmann.me</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">Hi there,<br>
<br>
I am wondering whether JSON [RFC7159] support would be a helpful extension =
to the C++ standard library (pure library extension), including, but not li=
mited to, the following aspects:<br>
<br>
1. A variant-like container type (for this mail, let&#39;s call it &quot;st=
d::json&quot;) that combines C++ types for the JSON value types [RFC7159, c=
hapter 3]:<br>
=C2=A0 - string (e.g. std::string),<br>
=C2=A0 - number (e.g., double or int64_t),<br>
=C2=A0 - boolean (e.g., bool),<br>
=C2=A0 - array (e.g., std::vector), and<br>
=C2=A0 - object (e.g., std::map).<br>
<br>
This type should have an intuitive API (i.e., all expected container method=
s), but also use as much syntactic sugar as possible (e.g., using initializ=
er lists to express arrays like &quot;std::json my_array =3D {&quot;a strin=
g&quot;, 17, 42.12};&quot;.<br>
<br>
2. A serialization function to create a textual representation (called &quo=
t;JSON text&quot; in [RFC7159]) from a std::json value that conforms to the=
 JSON grammar [RFC7159, chapter 2-7].<br>
<br>
3. A deserialization function (i.e., a parser) [RFC7159, chapter 9] to crea=
te a std::json value from a JSON text.<br>
<br>
There are currently dozens of libraries [<a href=3D"http://json.org" rel=3D=
"noreferrer" target=3D"_blank">json.org</a>] written in C or C++ solving th=
ese aspects. However, it would be of great convenience to have JSON be part=
 of the C++ standard library. In particular, the wide use of JSON as exchan=
ge format for structured data as well as to express simple configuration da=
ta would could solve a lot of use cases within the C++ standard library.<br=
>
<br>
I would be willing to draft a proposal based on the experience I made with =
my C++ JSON library [nlohmann/json]. Of course, I would be interested in yo=
ur thoughts on this.<br>
<br>
All the best,<br>
Niels<br>
<br>
References<br>
<br>
[RFC7159] <a href=3D"https://tools.ietf.org/html/rfc7159.html" rel=3D"noref=
errer" target=3D"_blank">https://tools.ietf.org/html/rfc7159.html</a><br>
[<a href=3D"http://json.org" rel=3D"noreferrer" target=3D"_blank">json.org<=
/a>] <a href=3D"http://json.org" rel=3D"noreferrer" target=3D"_blank">http:=
//json.org</a><br>
[nlohmann/json] <a href=3D"https://github.com/nlohmann/json" rel=3D"norefer=
rer" target=3D"_blank">https://github.com/nlohmann/json</a><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3DF8137F-C90E-4D25-96AB-FF8B766418DF%=
40nlohmann.me" rel=3D"noreferrer" target=3D"_blank">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3DF8137F-C90E-4D25-96AB-FF8B766418DF%=
40nlohmann.me</a>.<br>
</blockquote></div></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" =
data-smartmail=3D"gmail_signature">-Neal</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC2GhWVHd%3DrmQVenWZYihR7%2Bfz56NUmd=
NNx%3DiAr%3DQTcKFhuCzw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC2GhWVH=
d%3DrmQVenWZYihR7%2Bfz56NUmdNNx%3DiAr%3DQTcKFhuCzw%40mail.gmail.com</a>.<br=
 />

--0000000000008647a7056f786fc0--

.

--000000000000659730056f792bf8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I have been using this library for quite some time now, as part of a server
application that communicates in JSON with client processes. It works
beautifully.

In terms of bringing it into the standard, I do have one reservation: due
to the nature of the task at hand - mainly that the scope of "what do
people want to use JSON for" is rather wide - it is under continuous
improvement. It's averaging more than a commit per day over the last month.
I can't see it as a project that will happily fit in with the much slower
and more granular update process that it would be under if brought into the
STL. I expect that many users will be using a more up to date version of
the library from GitHub rather than stick to the version standardised e.g.
3 years prior.

If Niels thinks otherwise, then I withdraw that reservation; he knows what
he plans to do with the project better than anyone.

I'm also not sure why standardizing it is desperately needed, unless there
are plans to incorporate it into future library components.

On Mon, 25 Jun 2018, 15:45 Neal Meyer, <neal.meyer@gmail.com> wrote:

> Niels,
>
> I=E2=80=99ve been looking into your library on github that is in response=
 to this
> discussion.  JSON handling is something I feel we desperately need to mov=
e
> forward in the next C++ revisions.  Have you started the proposal process
> with your libraries yet?  I could not find any papers in the isocpp
> mailings.
>
> Im just getting back to being involved with the committee after a few
> years off.
>
> -Neal Meyer
>
>
> On Wed, Mar 1, 2017 at 1:25 PM Niels Lohmann <mail@nlohmann.me> wrote:
>
>> Hi there,
>>
>> I am wondering whether JSON [RFC7159] support would be a helpful
>> extension to the C++ standard library (pure library extension), includin=
g,
>> but not limited to, the following aspects:
>>
>> 1. A variant-like container type (for this mail, let's call it
>> "std::json") that combines C++ types for the JSON value types [RFC7159,
>> chapter 3]:
>>   - string (e.g. std::string),
>>   - number (e.g., double or int64_t),
>>   - boolean (e.g., bool),
>>   - array (e.g., std::vector), and
>>   - object (e.g., std::map).
>>
>> This type should have an intuitive API (i.e., all expected container
>> methods), but also use as much syntactic sugar as possible (e.g., using
>> initializer lists to express arrays like "std::json my_array =3D {"a str=
ing",
>> 17, 42.12};".
>>
>> 2. A serialization function to create a textual representation (called
>> "JSON text" in [RFC7159]) from a std::json value that conforms to the JS=
ON
>> grammar [RFC7159, chapter 2-7].
>>
>> 3. A deserialization function (i.e., a parser) [RFC7159, chapter 9] to
>> create a std::json value from a JSON text.
>>
>> There are currently dozens of libraries [json.org] written in C or C++
>> solving these aspects. However, it would be of great convenience to have
>> JSON be part of the C++ standard library. In particular, the wide use of
>> JSON as exchange format for structured data as well as to express simple
>> configuration data would could solve a lot of use cases within the C++
>> standard library.
>>
>> I would be willing to draft a proposal based on the experience I made
>> with my C++ JSON library [nlohmann/json]. Of course, I would be interest=
ed
>> in your thoughts on this.
>>
>> All the best,
>> Niels
>>
>> References
>>
>> [RFC7159] https://tools.ietf.org/html/rfc7159.html
>> [json.org] http://json.org
>> [nlohmann/json] https://github.com/nlohmann/json
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3DF8137F-C9=
0E-4D25-96AB-FF8B766418DF%40nlohmann.me
>> .
>>
> --
> -Neal
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC2GhWVHd%3=
DrmQVenWZYihR7%2Bfz56NUmdNNx%3DiAr%3DQTcKFhuCzw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC2GhWVHd%=
3DrmQVenWZYihR7%2Bfz56NUmdNNx%3DiAr%3DQTcKFhuCzw%40mail.gmail.com?utm_mediu=
m=3Demail&utm_source=3Dfooter>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAC%2B0CCMfrW3aJCCL-gYo8RfiaT6ckOr3yG11maaUNjbS6=
DH3pg%40mail.gmail.com.

--000000000000659730056f792bf8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>I have been using this library for quite some time n=
ow, as part of a server application that communicates in JSON with client p=
rocesses. It works beautifully.<div dir=3D"auto"><br></div><div dir=3D"auto=
">In terms of bringing it into the standard, I do have one reservation: due=
 to the nature of the task at hand - mainly that the scope of &quot;what do=
 people want to use JSON for&quot; is rather wide - it is under continuous =
improvement. It&#39;s averaging more than a commit per day over the last mo=
nth. I can&#39;t see it as a project that will happily fit in with the much=
 slower and more granular update process that it would be under if brought =
into the STL. I expect that many users will be using a more up to date vers=
ion of the library from GitHub rather than stick to the version standardise=
d e.g. 3 years prior.</div><div dir=3D"auto"><br></div>If Niels thinks othe=
rwise, then I withdraw that reservation; he knows what he plans to do with =
the project better than anyone.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">I&#39;m also not sure why standardizing it is desperately needed,=
 unless there are plans to incorporate it into future library components.<b=
r><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">On Mon, 25 J=
un 2018, 15:45 Neal Meyer, &lt;<a href=3D"mailto:neal.meyer@gmail.com">neal=
..meyer@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v><div dir=3D"auto">Niels,</div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">I=E2=80=99ve been looking into your library on github that is in =
response to this discussion.=C2=A0 JSON handling is something I feel we des=
perately need to move forward in the next C++ revisions.=C2=A0 Have you sta=
rted the proposal process with your libraries yet?=C2=A0 I could not find a=
ny papers in the isocpp mailings. =C2=A0</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Im just getting back to being involved with the committee =
after a few years off.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">-Neal Meyer</div><div dir=3D"auto"><br></div><div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr">On Wed, Mar 1, 2017 at 1:25 PM Niels Lohmann &l=
t;<a href=3D"mailto:mail@nlohmann.me" target=3D"_blank" rel=3D"noreferrer">=
mail@nlohmann.me</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi =
there,<br>
<br>
I am wondering whether JSON [RFC7159] support would be a helpful extension =
to the C++ standard library (pure library extension), including, but not li=
mited to, the following aspects:<br>
<br>
1. A variant-like container type (for this mail, let&#39;s call it &quot;st=
d::json&quot;) that combines C++ types for the JSON value types [RFC7159, c=
hapter 3]:<br>
=C2=A0 - string (e.g. std::string),<br>
=C2=A0 - number (e.g., double or int64_t),<br>
=C2=A0 - boolean (e.g., bool),<br>
=C2=A0 - array (e.g., std::vector), and<br>
=C2=A0 - object (e.g., std::map).<br>
<br>
This type should have an intuitive API (i.e., all expected container method=
s), but also use as much syntactic sugar as possible (e.g., using initializ=
er lists to express arrays like &quot;std::json my_array =3D {&quot;a strin=
g&quot;, 17, 42.12};&quot;.<br>
<br>
2. A serialization function to create a textual representation (called &quo=
t;JSON text&quot; in [RFC7159]) from a std::json value that conforms to the=
 JSON grammar [RFC7159, chapter 2-7].<br>
<br>
3. A deserialization function (i.e., a parser) [RFC7159, chapter 9] to crea=
te a std::json value from a JSON text.<br>
<br>
There are currently dozens of libraries [<a href=3D"http://json.org" rel=3D=
"noreferrer noreferrer" target=3D"_blank">json.org</a>] written in C or C++=
 solving these aspects. However, it would be of great convenience to have J=
SON be part of the C++ standard library. In particular, the wide use of JSO=
N as exchange format for structured data as well as to express simple confi=
guration data would could solve a lot of use cases within the C++ standard =
library.<br>
<br>
I would be willing to draft a proposal based on the experience I made with =
my C++ JSON library [nlohmann/json]. Of course, I would be interested in yo=
ur thoughts on this.<br>
<br>
All the best,<br>
Niels<br>
<br>
References<br>
<br>
[RFC7159] <a href=3D"https://tools.ietf.org/html/rfc7159.html" rel=3D"noref=
errer noreferrer" target=3D"_blank">https://tools.ietf.org/html/rfc7159.htm=
l</a><br>
[<a href=3D"http://json.org" rel=3D"noreferrer noreferrer" target=3D"_blank=
">json.org</a>] <a href=3D"http://json.org" rel=3D"noreferrer noreferrer" t=
arget=3D"_blank">http://json.org</a><br>
[nlohmann/json] <a href=3D"https://github.com/nlohmann/json" rel=3D"norefer=
rer noreferrer" target=3D"_blank">https://github.com/nlohmann/json</a><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3DF8137F-C90E-4D25-96AB-FF8B766418DF%=
40nlohmann.me" rel=3D"noreferrer noreferrer" target=3D"_blank">https://grou=
ps.google.com/a/isocpp.org/d/msgid/std-proposals/3DF8137F-C90E-4D25-96AB-FF=
8B766418DF%40nlohmann.me</a>.<br>
</blockquote></div></div>-- <br><div dir=3D"ltr" class=3D"m_-63567127843483=
91286gmail_signature" data-smartmail=3D"gmail_signature">-Neal</div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC2GhWVHd%3DrmQVenWZYihR7%2Bfz56NUmd=
NNx%3DiAr%3DQTcKFhuCzw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=
=3Dfooter" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a=
/isocpp.org/d/msgid/std-proposals/CAC2GhWVHd%3DrmQVenWZYihR7%2Bfz56NUmdNNx%=
3DiAr%3DQTcKFhuCzw%40mail.gmail.com</a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMfrW3aJCCL-gYo8RfiaT6ckOr3yG=
11maaUNjbS6DH3pg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMfrW3a=
JCCL-gYo8RfiaT6ckOr3yG11maaUNjbS6DH3pg%40mail.gmail.com</a>.<br />

--000000000000659730056f792bf8--

.

--000000000000154a21056f79309f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'd like to add that keeping a "requirements" list is a necessary thing for
this process, because I'd like to throw in some requirements:

- allocator aware
- need to specify concepts as well as the concrete library

The reason for the concepts is that I can totally see a json-overlay type
implementation that uses string_view to access an in-memory version on the
actual memory that's been read.



On Mon, Jun 25, 2018 at 3:45 PM, Neal Meyer <neal.meyer@gmail.com> wrote:

> Niels,
>
> I=E2=80=99ve been looking into your library on github that is in response=
 to this
> discussion.  JSON handling is something I feel we desperately need to mov=
e
> forward in the next C++ revisions.  Have you started the proposal process
> with your libraries yet?  I could not find any papers in the isocpp
> mailings.
>
> Im just getting back to being involved with the committee after a few
> years off.
>
> -Neal Meyer
>
>
> On Wed, Mar 1, 2017 at 1:25 PM Niels Lohmann <mail@nlohmann.me> wrote:
>
>> Hi there,
>>
>> I am wondering whether JSON [RFC7159] support would be a helpful
>> extension to the C++ standard library (pure library extension), includin=
g,
>> but not limited to, the following aspects:
>>
>> 1. A variant-like container type (for this mail, let's call it
>> "std::json") that combines C++ types for the JSON value types [RFC7159,
>> chapter 3]:
>>   - string (e.g. std::string),
>>   - number (e.g., double or int64_t),
>>   - boolean (e.g., bool),
>>   - array (e.g., std::vector), and
>>   - object (e.g., std::map).
>>
>> This type should have an intuitive API (i.e., all expected container
>> methods), but also use as much syntactic sugar as possible (e.g., using
>> initializer lists to express arrays like "std::json my_array =3D {"a str=
ing",
>> 17, 42.12};".
>>
>> 2. A serialization function to create a textual representation (called
>> "JSON text" in [RFC7159]) from a std::json value that conforms to the JS=
ON
>> grammar [RFC7159, chapter 2-7].
>>
>> 3. A deserialization function (i.e., a parser) [RFC7159, chapter 9] to
>> create a std::json value from a JSON text.
>>
>> There are currently dozens of libraries [json.org] written in C or C++
>> solving these aspects. However, it would be of great convenience to have
>> JSON be part of the C++ standard library. In particular, the wide use of
>> JSON as exchange format for structured data as well as to express simple
>> configuration data would could solve a lot of use cases within the C++
>> standard library.
>>
>> I would be willing to draft a proposal based on the experience I made
>> with my C++ JSON library [nlohmann/json]. Of course, I would be interest=
ed
>> in your thoughts on this.
>>
>> All the best,
>> Niels
>>
>> References
>>
>> [RFC7159] https://tools.ietf.org/html/rfc7159.html
>> [json.org] http://json.org
>> [nlohmann/json] https://github.com/nlohmann/json
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/
>> isocpp.org/d/msgid/std-proposals/3DF8137F-C90E-4D25-
>> 96AB-FF8B766418DF%40nlohmann.me.
>>
> --
> -Neal
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAC2GhWVHd%3DrmQVenWZYihR7%2Bfz56NUmdNNx=
%
> 3DiAr%3DQTcKFhuCzw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC2GhWVHd%=
3DrmQVenWZYihR7%2Bfz56NUmdNNx%3DiAr%3DQTcKFhuCzw%40mail.gmail.com?utm_mediu=
m=3Demail&utm_source=3Dfooter>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAANG%3DkXRi52xK4gNW-TJ8JzPoSxguyvUQnKrLgpRL1dtL=
8Ou%2BA%40mail.gmail.com.

--000000000000154a21056f79309f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;d like to add that keeping a &quot;requirements&quot=
; list is a necessary thing for this process, because I&#39;d like to throw=
 in some requirements:<div><br></div><div>- allocator aware</div><div>- nee=
d to specify concepts as well as the concrete library</div><div><br></div><=
div>The reason for the concepts is that I can totally see a json-overlay ty=
pe implementation that uses string_view to access an in-memory version on t=
he actual memory that&#39;s been read.</div><div><br></div><div><br></div><=
/div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Jun =
25, 2018 at 3:45 PM, Neal Meyer <span dir=3D"ltr">&lt;<a href=3D"mailto:nea=
l.meyer@gmail.com" target=3D"_blank">neal.meyer@gmail.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div><div dir=3D"auto">Niels,</div><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">I=E2=80=99ve been lookin=
g into your library on github that is in response to this discussion.=C2=A0=
 JSON handling is something I feel we desperately need to move forward in t=
he next C++ revisions.=C2=A0 Have you started the proposal process with you=
r libraries yet?=C2=A0 I could not find any papers in the isocpp mailings. =
=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Im just getting b=
ack to being involved with the committee after a few years off.=C2=A0</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">-Neal Meyer</div><div dir=3D"=
auto"><br></div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed=
, Mar 1, 2017 at 1:25 PM Niels Lohmann &lt;<a href=3D"mailto:mail@nlohmann.=
me" target=3D"_blank">mail@nlohmann.me</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">Hi there,<br>
<br>
I am wondering whether JSON [RFC7159] support would be a helpful extension =
to the C++ standard library (pure library extension), including, but not li=
mited to, the following aspects:<br>
<br>
1. A variant-like container type (for this mail, let&#39;s call it &quot;st=
d::json&quot;) that combines C++ types for the JSON value types [RFC7159, c=
hapter 3]:<br>
=C2=A0 - string (e.g. std::string),<br>
=C2=A0 - number (e.g., double or int64_t),<br>
=C2=A0 - boolean (e.g., bool),<br>
=C2=A0 - array (e.g., std::vector), and<br>
=C2=A0 - object (e.g., std::map).<br>
<br>
This type should have an intuitive API (i.e., all expected container method=
s), but also use as much syntactic sugar as possible (e.g., using initializ=
er lists to express arrays like &quot;std::json my_array =3D {&quot;a strin=
g&quot;, 17, 42.12};&quot;.<br>
<br>
2. A serialization function to create a textual representation (called &quo=
t;JSON text&quot; in [RFC7159]) from a std::json value that conforms to the=
 JSON grammar [RFC7159, chapter 2-7].<br>
<br>
3. A deserialization function (i.e., a parser) [RFC7159, chapter 9] to crea=
te a std::json value from a JSON text.<br>
<br>
There are currently dozens of libraries [<a href=3D"http://json.org" rel=3D=
"noreferrer" target=3D"_blank">json.org</a>] written in C or C++ solving th=
ese aspects. However, it would be of great convenience to have JSON be part=
 of the C++ standard library. In particular, the wide use of JSON as exchan=
ge format for structured data as well as to express simple configuration da=
ta would could solve a lot of use cases within the C++ standard library.<br=
>
<br>
I would be willing to draft a proposal based on the experience I made with =
my C++ JSON library [nlohmann/json]. Of course, I would be interested in yo=
ur thoughts on this.<br>
<br>
All the best,<br>
Niels<br>
<br>
References<br>
<br>
[RFC7159] <a href=3D"https://tools.ietf.org/html/rfc7159.html" rel=3D"noref=
errer" target=3D"_blank">https://tools.ietf.org/html/<wbr>rfc7159.html</a><=
br>
[<a href=3D"http://json.org" rel=3D"noreferrer" target=3D"_blank">json.org<=
/a>] <a href=3D"http://json.org" rel=3D"noreferrer" target=3D"_blank">http:=
//json.org</a><br>
[nlohmann/json] <a href=3D"https://github.com/nlohmann/json" rel=3D"norefer=
rer" target=3D"_blank">https://github.com/nlohmann/<wbr>json</a><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3DF8137F-C90E-4D25-96AB-FF8B766418DF%=
40nlohmann.me" rel=3D"noreferrer" target=3D"_blank">https://groups.google.c=
om/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/3DF8137F-C90E-4D25-<wbr>96A=
B-FF8B766418DF%40nlohmann.<wbr>me</a>.<span class=3D"HOEnZb"><font color=3D=
"#888888"><br>
</font></span></blockquote></div></div><span class=3D"HOEnZb"><font color=
=3D"#888888">-- <br><div dir=3D"ltr" class=3D"m_941165209559399959gmail_sig=
nature" data-smartmail=3D"gmail_signature">-Neal</div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC2GhWVHd%3DrmQVenWZYihR7%2Bfz56NUmd=
NNx%3DiAr%3DQTcKFhuCzw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/=
msgid/std-<wbr>proposals/CAC2GhWVHd%<wbr>3DrmQVenWZYihR7%2Bfz56NUmdNNx%<wbr=
>3DiAr%3DQTcKFhuCzw%40mail.<wbr>gmail.com</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkXRi52xK4gNW-TJ8JzPoSxguyvUQn=
KrLgpRL1dtL8Ou%2BA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkXRi5=
2xK4gNW-TJ8JzPoSxguyvUQnKrLgpRL1dtL8Ou%2BA%40mail.gmail.com</a>.<br />

--000000000000154a21056f79309f--

.

------=_Part_35350_2146183533.1529942285995
Content-Type: multipart/alternative;
 boundary="----=_Part_35351_482049600.1529942285995"

------=_Part_35351_482049600.1529942285995
Content-Type: text/plain; charset="UTF-8"

On Monday, June 25, 2018 at 11:38:15 AM UTC-4, Jake Arkinstall wrote:
>
> I have been using this library for quite some time now, as part of a
> server application that communicates in JSON with client processes. It
> works beautifully.
>
> In terms of bringing it into the standard, I do have one reservation: due
> to the nature of the task at hand - mainly that the scope of "what do
> people want to use JSON for" is rather wide - it is under continuous
> improvement. It's averaging more than a commit per day over the last month.
> I can't see it as a project that will happily fit in with the much slower
> and more granular update process that it would be under if brought into the
> STL. I expect that many users will be using a more up to date version of
> the library from GitHub rather than stick to the version standardised e.g.
> 3 years prior.
>

JSON itself is quite stable. Are the daily updates to this library actually
meaningful to its interface? And if so, why is the interface undergoing
daily revisions?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2e137fca-4bae-4911-b983-02f14da90e67%40isocpp.org.

------=_Part_35351_482049600.1529942285995
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, June 25, 2018 at 11:38:15 AM UTC-4, Jake Arkins=
tall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><=
div>I have been using this library for quite some time now, as part of a se=
rver application that communicates in JSON with client processes. It works =
beautifully.<div dir=3D"auto"><br></div><div dir=3D"auto">In terms of bring=
ing it into the standard, I do have one reservation: due to the nature of t=
he task at hand - mainly that the scope of &quot;what do people want to use=
 JSON for&quot; is rather wide - it is under continuous improvement. It&#39=
;s averaging more than a commit per day over the last month. I can&#39;t se=
e it as a project that will happily fit in with the much slower and more gr=
anular update process that it would be under if brought into the STL. I exp=
ect that many users will be using a more up to date version of the library =
from GitHub rather than stick to the version standardised e.g. 3 years prio=
r.</div></div></div></blockquote><div><br></div><div>JSON itself is quite s=
table. Are the daily updates to this library actually meaningful to its int=
erface? And if so, why is the interface undergoing daily revisions?</div><b=
r></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2e137fca-4bae-4911-b983-02f14da90e67%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2e137fca-4bae-4911-b983-02f14da90e67=
%40isocpp.org</a>.<br />

------=_Part_35351_482049600.1529942285995--

------=_Part_35350_2146183533.1529942285995--

.

--000000000000de2e3b056f79e464
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 25, 2018 at 4:38 PM, Jake Arkinstall <jake.arkinstall@gmail.com=
>
wrote:

> I have been using this library for quite some time now, as part of a
> server application that communicates in JSON with client processes. It
> works beautifully.
>

Have you compared it to competing json libraries such as rapidjson?


> In terms of bringing it into the standard, I do have one reservation: due
> to the nature of the task at hand - mainly that the scope of "what do
> people want to use JSON for" is rather wide - it is under continuous
> improvement. It's averaging more than a commit per day over the last mont=
h.
> I can't see it as a project that will happily fit in with the much slower
> and more granular update process that it would be under if brought into t=
he
> STL. I expect that many users will be using a more up to date version of
> the library from GitHub rather than stick to the version standardised e.g=
..
> 3 years prior.
>
> If Niels thinks otherwise, then I withdraw that reservation; he knows wha=
t
> he plans to do with the project better than anyone.
>
> I'm also not sure why standardizing it is desperately needed, unless ther=
e
> are plans to incorporate it into future library components.
>
>
> On Mon, 25 Jun 2018, 15:45 Neal Meyer, <neal.meyer@gmail.com> wrote:
>
>> Niels,
>>
>> I=E2=80=99ve been looking into your library on github that is in respons=
e to this
>> discussion.  JSON handling is something I feel we desperately need to mo=
ve
>> forward in the next C++ revisions.  Have you started the proposal proces=
s
>> with your libraries yet?  I could not find any papers in the isocpp
>> mailings.
>>
>> Im just getting back to being involved with the committee after a few
>> years off.
>>
>> -Neal Meyer
>>
>>
>> On Wed, Mar 1, 2017 at 1:25 PM Niels Lohmann <mail@nlohmann.me> wrote:
>>
>>> Hi there,
>>>
>>> I am wondering whether JSON [RFC7159] support would be a helpful
>>> extension to the C++ standard library (pure library extension), includi=
ng,
>>> but not limited to, the following aspects:
>>>
>>> 1. A variant-like container type (for this mail, let's call it
>>> "std::json") that combines C++ types for the JSON value types [RFC7159,
>>> chapter 3]:
>>>   - string (e.g. std::string),
>>>   - number (e.g., double or int64_t),
>>>   - boolean (e.g., bool),
>>>   - array (e.g., std::vector), and
>>>   - object (e.g., std::map).
>>>
>>> This type should have an intuitive API (i.e., all expected container
>>> methods), but also use as much syntactic sugar as possible (e.g., using
>>> initializer lists to express arrays like "std::json my_array =3D {"a st=
ring",
>>> 17, 42.12};".
>>>
>>> 2. A serialization function to create a textual representation (called
>>> "JSON text" in [RFC7159]) from a std::json value that conforms to the J=
SON
>>> grammar [RFC7159, chapter 2-7].
>>>
>>> 3. A deserialization function (i.e., a parser) [RFC7159, chapter 9] to
>>> create a std::json value from a JSON text.
>>>
>>> There are currently dozens of libraries [json.org] written in C or C++
>>> solving these aspects. However, it would be of great convenience to hav=
e
>>> JSON be part of the C++ standard library. In particular, the wide use o=
f
>>> JSON as exchange format for structured data as well as to express simpl=
e
>>> configuration data would could solve a lot of use cases within the C++
>>> standard library.
>>>
>>> I would be willing to draft a proposal based on the experience I made
>>> with my C++ JSON library [nlohmann/json]. Of course, I would be interes=
ted
>>> in your thoughts on this.
>>>
>>> All the best,
>>> Niels
>>>
>>> References
>>>
>>> [RFC7159] https://tools.ietf.org/html/rfc7159.html
>>> [json.org] http://json.org
>>> [nlohmann/json] https://github.com/nlohmann/json
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/
>>> isocpp.org/d/msgid/std-proposals/3DF8137F-C90E-4D25-
>>> 96AB-FF8B766418DF%40nlohmann.me.
>>>
>> --
>> -Neal
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/
>> isocpp.org/d/msgid/std-proposals/CAC2GhWVHd%
>> 3DrmQVenWZYihR7%2Bfz56NUmdNNx%3DiAr%3DQTcKFhuCzw%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC2GhWVHd=
%3DrmQVenWZYihR7%2Bfz56NUmdNNx%3DiAr%3DQTcKFhuCzw%40mail.gmail.com?utm_medi=
um=3Demail&utm_source=3Dfooter>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAC%2B0CCMfrW3aJCCL-
> gYo8RfiaT6ckOr3yG11maaUNjbS6DH3pg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMf=
rW3aJCCL-gYo8RfiaT6ckOr3yG11maaUNjbS6DH3pg%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFQaeCBAb8s%3D4FetPC_XkqLv_1%2B5FMS%3DiH3Dswo61=
whpThZzpA%40mail.gmail.com.

--000000000000de2e3b056f79e464
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Jun 25, 2018 at 4:38 PM, Jake Arkinstall <span dir=3D"ltr">&lt;=
<a href=3D"mailto:jake.arkinstall@gmail.com" target=3D"_blank">jake.arkinst=
all@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"auto"><div>I have been using this library for quite some time now, a=
s part of a server application that communicates in JSON with client proces=
ses. It works beautifully.<br></div></div></blockquote><div><br></div><div>=
Have you compared it to competing json libraries such as rapidjson?=C2=A0</=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>=
<div dir=3D"auto">In terms of bringing it into the standard, I do have one =
reservation: due to the nature of the task at hand - mainly that the scope =
of &quot;what do people want to use JSON for&quot; is rather wide - it is u=
nder continuous improvement. It&#39;s averaging more than a commit per day =
over the last month. I can&#39;t see it as a project that will happily fit =
in with the much slower and more granular update process that it would be u=
nder if brought into the STL. I expect that many users will be using a more=
 up to date version of the library from GitHub rather than stick to the ver=
sion standardised e.g. 3 years prior.</div><div dir=3D"auto"><br></div>If N=
iels thinks otherwise, then I withdraw that reservation; he knows what he p=
lans to do with the project better than anyone.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">I&#39;m also not sure why standardizing it is despe=
rately needed, unless there are plans to incorporate it into future library=
 components.<div><div class=3D"h5"><br><br><div class=3D"gmail_quote" dir=
=3D"auto"><div dir=3D"ltr">On Mon, 25 Jun 2018, 15:45 Neal Meyer, &lt;<a hr=
ef=3D"mailto:neal.meyer@gmail.com" target=3D"_blank">neal.meyer@gmail.com</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir=3D"auto=
">Niels,</div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I=E2=80=
=99ve been looking into your library on github that is in response to this =
discussion.=C2=A0 JSON handling is something I feel we desperately need to =
move forward in the next C++ revisions.=C2=A0 Have you started the proposal=
 process with your libraries yet?=C2=A0 I could not find any papers in the =
isocpp mailings. =C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
Im just getting back to being involved with the committee after a few years=
 off.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">-Neal Meyer<=
/div><div dir=3D"auto"><br></div><div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr">On Wed, Mar 1, 2017 at 1:25 PM Niels Lohmann &lt;<a href=3D"mail=
to:mail@nlohmann.me" target=3D"_blank" rel=3D"noreferrer">mail@nlohmann.me<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi there,<br>
<br>
I am wondering whether JSON [RFC7159] support would be a helpful extension =
to the C++ standard library (pure library extension), including, but not li=
mited to, the following aspects:<br>
<br>
1. A variant-like container type (for this mail, let&#39;s call it &quot;st=
d::json&quot;) that combines C++ types for the JSON value types [RFC7159, c=
hapter 3]:<br>
=C2=A0 - string (e.g. std::string),<br>
=C2=A0 - number (e.g., double or int64_t),<br>
=C2=A0 - boolean (e.g., bool),<br>
=C2=A0 - array (e.g., std::vector), and<br>
=C2=A0 - object (e.g., std::map).<br>
<br>
This type should have an intuitive API (i.e., all expected container method=
s), but also use as much syntactic sugar as possible (e.g., using initializ=
er lists to express arrays like &quot;std::json my_array =3D {&quot;a strin=
g&quot;, 17, 42.12};&quot;.<br>
<br>
2. A serialization function to create a textual representation (called &quo=
t;JSON text&quot; in [RFC7159]) from a std::json value that conforms to the=
 JSON grammar [RFC7159, chapter 2-7].<br>
<br>
3. A deserialization function (i.e., a parser) [RFC7159, chapter 9] to crea=
te a std::json value from a JSON text.<br>
<br>
There are currently dozens of libraries [<a href=3D"http://json.org" target=
=3D"_blank" rel=3D"noreferrer noreferrer">json.org</a>] written in C or C++=
 solving these aspects. However, it would be of great convenience to have J=
SON be part of the C++ standard library. In particular, the wide use of JSO=
N as exchange format for structured data as well as to express simple confi=
guration data would could solve a lot of use cases within the C++ standard =
library.<br>
<br>
I would be willing to draft a proposal based on the experience I made with =
my C++ JSON library [nlohmann/json]. Of course, I would be interested in yo=
ur thoughts on this.<br>
<br>
All the best,<br>
Niels<br>
<br>
References<br>
<br>
[RFC7159] <a href=3D"https://tools.ietf.org/html/rfc7159.html" target=3D"_b=
lank" rel=3D"noreferrer noreferrer">https://tools.ietf.org/html/<wbr>rfc715=
9.html</a><br>
[<a href=3D"http://json.org" target=3D"_blank" rel=3D"noreferrer noreferrer=
">json.org</a>] <a href=3D"http://json.org" target=3D"_blank" rel=3D"norefe=
rrer noreferrer">http://json.org</a><br>
[nlohmann/json] <a href=3D"https://github.com/nlohmann/json" target=3D"_bla=
nk" rel=3D"noreferrer noreferrer">https://github.com/nlohmann/<wbr>json</a>=
<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank" rel=3D"noreferrer">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<=
br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3DF8137F-C90E-4D25-96AB-FF8B766418DF%=
40nlohmann.me" target=3D"_blank" rel=3D"noreferrer noreferrer">https://grou=
ps.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/3DF8137F-C90E-4D=
25-<wbr>96AB-FF8B766418DF%40nlohmann.<wbr>me</a>.<br>
</blockquote></div></div>-- <br><div class=3D"m_-6766059666559304957m_-6356=
712784348391286gmail_signature" dir=3D"ltr" data-smartmail=3D"gmail_signatu=
re">-Neal</div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br=
>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC2GhWVHd%3DrmQVenWZYihR7%2Bfz56NUmd=
NNx%3DiAr%3DQTcKFhuCzw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=
=3Dfooter" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a=
/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CAC2GhWVHd%<wbr>3DrmQVenWZYihR7=
%2Bfz56NUmdNNx%<wbr>3DiAr%3DQTcKFhuCzw%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div></div></div></div></div><div><div class=3D"h5">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMfrW3aJCCL-gYo8RfiaT6ckOr3yG=
11maaUNjbS6DH3pg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CAC%2B0CCMfrW3aJCCL-<wbr>gYo8RfiaT6ckOr3yG11maaUNjbS6DH<wb=
r>3pg%40mail.gmail.com</a>.<br>
</blockquote></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFQaeCBAb8s%3D4FetPC_XkqLv_1%2B5FMS%=
3DiH3Dswo61whpThZzpA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCBAb8=
s%3D4FetPC_XkqLv_1%2B5FMS%3DiH3Dswo61whpThZzpA%40mail.gmail.com</a>.<br />

--000000000000de2e3b056f79e464--

.

--000000000000aea7c8056f7b3153
Content-Type: text/plain; charset="UTF-8"

On Mon, 25 Jun 2018, 16:58 Nicol Bolas, <jmckesson@gmail.com> wrote:

JSON itself is quite stable. Are the daily updates to this library actually
meaningful to its interface? And if so, why is the interface undergoing
daily revisions?


It does appear that the majority of changes are more to do with the
accessories, such as build configs.

However, every now and then there are upgrades that would not have been so
easy to make if subject to the proposal process (such as removal of
stringstreams, accessing keys as const references rather than copying
values, all the way up to the introduction of a SAX parser a few months
ago).

These kinds of changes are important for the development of the framework,
but demonstrate that it is well suited to its current development process.
Maybe a formal committee process will get everything ironed out in one fell
swoop, but Im not convinced that this is the ideal approach. I'd also love
to see how the source would change with proposals for C++20 implemented; it
is currently written assuming C++11 as far as I'm aware, and I can't
imagine this will be the situation if standardised.

There is also an ongoing discussion about casting (
https://github.com/nlohmann/json/issues/958 ) which needs resolving, and
I'm under the impression that edge cases sometimes arise when people want
to make the library work with their custom types (I have seen various
discussions on this, but for the life of me I can't find any that I had in
mind when I wrote that the nature of the project lends itself to continual
changes. Perhaps I am imagining things.)



On Mon, 25 Jun 2018, 17:30 j c, <james.a.cooper@gmail.com> wrote:

> On Mon, Jun 25, 2018 at 4:38 PM, Jake Arkinstall <
> jake.arkinstall@gmail.com> wrote:
>
>> I have been using this library for quite some time now, as part of a
>> server application that communicates in JSON with client processes. It
>> works beautifully.
>>
>
> Have you compared it to competing json libraries such as rapidjson?
>

I tried out quite a few, But nlohmann::json definitely stood out as the
most comfortable to use, most familiar (i.e. it wouldn't feel out of place
in the STL), and very flexible - in particular it works great with custom
types. It fit my needs perfectly.

There are implementations that are faster (RapidJSON claimed to when I
tried it out - it wasn't pretty to write with, though. It's so far removed
from STL styles and approaches that it feels more like writing pre-generics
Java). There are some that are lighter in memory. There are some that
compile faster, and there are some that have smaller file sizes. I think
it'd be quite hard to decide on a single implementation to suit the
everyday user.

>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMSV9-oSood7iCU6d%3DBAJLHsfSBXUJAoCwpnRX69fj%3DuA%40mail.gmail.com.

--000000000000aea7c8056f7b3153
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">=
<div dir=3D"ltr" style=3D"font-family:sans-serif">On Mon, 25 Jun 2018, 16:5=
8 Nicol Bolas, &lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank"=
 rel=3D"noreferrer">jmckesson@gmail.com</a>&gt; wrote:<br></div><blockquote=
 style=3D"font-family:sans-serif;margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>JSON itself i=
s quite stable. Are the daily updates to this library actually meaningful t=
o its interface? And if so, why is the interface undergoing daily revisions=
?<br></div></div></blockquote></div></div><div dir=3D"auto"><br></div><div =
dir=3D"auto">It does appear that the majority of changes are more to do wit=
h the accessories, such as build configs.</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">However, every now and then there are upgrades that would=
 not have been so easy to make if subject to the proposal process (such as =
removal of stringstreams, accessing keys as const references rather than co=
pying values, all the way up to the introduction of a SAX parser a few mont=
hs ago).</div><div dir=3D"auto"><br></div><div dir=3D"auto">These kinds of =
changes are important for the development of the framework, but demonstrate=
 that it is well suited to its current development process. Maybe a formal =
committee process will get everything ironed out in one fell swoop, but Im =
not convinced that this is the ideal approach. I&#39;d also love to see how=
 the source would change with proposals for C++20 implemented; it is curren=
tly written assuming C++11 as far as I&#39;m aware, and I can&#39;t imagine=
 this will be the situation if standardised.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">There is also an ongoing discussion about casting (=C2=
=A0<a href=3D"https://github.com/nlohmann/json/issues/958" target=3D"_blank=
" rel=3D"noreferrer">https://github.com/nlohmann/json/issues/958</a> ) whic=
h needs resolving, and I&#39;m under the impression that edge cases sometim=
es arise when people want to make the library work with their custom types =
(I have seen various discussions on this, but for the life of me I can&#39;=
t find any that I had in mind when I wrote that the nature of the project l=
ends itself to continual changes. Perhaps I am imagining things.)</div><div=
 class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr"><blockquote style=3D"f=
ont-family:sans-serif;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div></div></div></blockquote=
><br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">On Mon, 25 Jun 2018,=
 17:30 j c, &lt;<a href=3D"mailto:james.a.cooper@gmail.com" rel=3D"noreferr=
er noreferrer noreferrer" target=3D"_blank">james.a.cooper@gmail.com</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote">On Mon, Jun 25, 2018 at 4:38 P=
M, Jake Arkinstall <span dir=3D"ltr">&lt;<a href=3D"mailto:jake.arkinstall@=
gmail.com" rel=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_b=
lank">jake.arkinstall@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"auto"><div>I have been using this library for qui=
te some time now, as part of a server application that communicates in JSON=
 with client processes. It works beautifully.<br></div></div></blockquote><=
div><br></div><div>Have you compared it to competing json libraries such as=
 rapidjson?=C2=A0</div></div></div></div></blockquote></div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">I tried out quite a few, But nlohmann::json =
definitely stood out as the most comfortable to use, most familiar (i.e. it=
 wouldn&#39;t feel out of place in the STL), and very flexible - in particu=
lar it works great with custom types. It fit my needs perfectly.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">There are implementations that are=
 faster (RapidJSON claimed to when I tried it out - it wasn&#39;t pretty to=
 write with, though. It&#39;s so far removed from STL styles and approaches=
 that it feels more like writing pre-generics Java). There are some that ar=
e lighter in memory. There are some that compile faster, and there are some=
 that have smaller file sizes. I think it&#39;d be quite hard to decide on =
a single implementation to suit the everyday user.</div><div class=3D"gmail=
_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMSV9-oSood7iCU6d%3DBAJLHsfSB=
XUJAoCwpnRX69fj%3DuA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMS=
V9-oSood7iCU6d%3DBAJLHsfSBXUJAoCwpnRX69fj%3DuA%40mail.gmail.com</a>.<br />

--000000000000aea7c8056f7b3153--

.

--0000000000001b4d99056f887bf9
Content-Type: text/plain; charset="UTF-8"

Why not also: XML, INI, csv, ASN.1, ... ?
std::string::replace(s.find("JSON"), sizeof("XML")-1, "XML");

On Mon, Jun 25, 2018 at 8:02 PM, Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:

> On Mon, 25 Jun 2018, 16:58 Nicol Bolas, <jmckesson@gmail.com> wrote:
>
> JSON itself is quite stable. Are the daily updates to this library
> actually meaningful to its interface? And if so, why is the interface
> undergoing daily revisions?
>
>
> It does appear that the majority of changes are more to do with the
> accessories, such as build configs.
>
> However, every now and then there are upgrades that would not have been so
> easy to make if subject to the proposal process (such as removal of
> stringstreams, accessing keys as const references rather than copying
> values, all the way up to the introduction of a SAX parser a few months
> ago).
>
> These kinds of changes are important for the development of the framework,
> but demonstrate that it is well suited to its current development process.
> Maybe a formal committee process will get everything ironed out in one fell
> swoop, but Im not convinced that this is the ideal approach. I'd also love
> to see how the source would change with proposals for C++20 implemented; it
> is currently written assuming C++11 as far as I'm aware, and I can't
> imagine this will be the situation if standardised.
>
> There is also an ongoing discussion about casting (
> https://github.com/nlohmann/json/issues/958 ) which needs resolving, and
> I'm under the impression that edge cases sometimes arise when people want
> to make the library work with their custom types (I have seen various
> discussions on this, but for the life of me I can't find any that I had in
> mind when I wrote that the nature of the project lends itself to continual
> changes. Perhaps I am imagining things.)
>
>
>
> On Mon, 25 Jun 2018, 17:30 j c, <james.a.cooper@gmail.com> wrote:
>
>> On Mon, Jun 25, 2018 at 4:38 PM, Jake Arkinstall <
>> jake.arkinstall@gmail.com> wrote:
>>
>>> I have been using this library for quite some time now, as part of a
>>> server application that communicates in JSON with client processes. It
>>> works beautifully.
>>>
>>
>> Have you compared it to competing json libraries such as rapidjson?
>>
>
> I tried out quite a few, But nlohmann::json definitely stood out as the
> most comfortable to use, most familiar (i.e. it wouldn't feel out of place
> in the STL), and very flexible - in particular it works great with custom
> types. It fit my needs perfectly.
>
> There are implementations that are faster (RapidJSON claimed to when I
> tried it out - it wasn't pretty to write with, though. It's so far removed
> from STL styles and approaches that it feels more like writing pre-generics
> Java). There are some that are lighter in memory. There are some that
> compile faster, and there are some that have smaller file sizes. I think
> it'd be quite hard to decide on a single implementation to suit the
> everyday user.
>
>> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAC%2B0CCMSV9-oSood7iCU6d%
> 3DBAJLHsfSBXUJAoCwpnRX69fj%3DuA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMSV9-oSood7iCU6d%3DBAJLHsfSBXUJAoCwpnRX69fj%3DuA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmwMH6s7t4aoGkpV9AnDZkDhWWgHhCF5W2qdrr8W2LoVQQ%40mail.gmail.com.

--0000000000001b4d99056f887bf9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Why not also: XML, INI, csv, ASN.1, ... ?</div><div><=
span class=3D"gmail-pln">std::string::</span><span class=3D"gmail-pln">repl=
ace</span><span class=3D"gmail-pun">(</span><span class=3D"gmail-pln">s</sp=
an><span class=3D"gmail-pun">.</span><span class=3D"gmail-pln">find</span><=
span class=3D"gmail-pun">(</span><span class=3D"gmail-str">&quot;JSON&quot;=
</span><span class=3D"gmail-pun">),</span><span class=3D"gmail-pln"> </span=
><span class=3D"gmail-kwd">sizeof</span><span class=3D"gmail-pun">(</span><=
span class=3D"gmail-str">&quot;XML&quot;</span><span class=3D"gmail-pun">)-=
</span><span class=3D"gmail-lit">1</span><span class=3D"gmail-pun">,</span>=
<span class=3D"gmail-pln"> </span><span class=3D"gmail-str">&quot;XML&quot;=
</span><span class=3D"gmail-pun">);</span></div></div><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On Mon, Jun 25, 2018 at 8:02 PM, Jake =
Arkinstall <span dir=3D"ltr">&lt;<a href=3D"mailto:jake.arkinstall@gmail.co=
m" target=3D"_blank">jake.arkinstall@gmail.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"auto"><span><div class=3D"gmail_quo=
te" dir=3D"auto"><div dir=3D"ltr"><div style=3D"font-family:sans-serif" dir=
=3D"ltr">On Mon, 25 Jun 2018, 16:58 Nicol Bolas, &lt;<a href=3D"mailto:jmck=
esson@gmail.com" target=3D"_blank" rel=3D"noreferrer">jmckesson@gmail.com</=
a>&gt; wrote:<br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;paddin=
g-left:1ex;font-family:sans-serif;border-left-color:rgb(204,204,204);border=
-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>JSON itself =
is quite stable. Are the daily updates to this library actually meaningful =
to its interface? And if so, why is the interface undergoing daily revision=
s?<br></div></div></blockquote></div></div><div dir=3D"auto"><br></div></sp=
an><div dir=3D"auto">It does appear that the majority of changes are more t=
o do with the accessories, such as build configs.</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">However, every now and then there are upgrades th=
at would not have been so easy to make if subject to the proposal process (=
such as removal of stringstreams, accessing keys as const references rather=
 than copying values, all the way up to the introduction of a SAX parser a =
few months ago).</div><div dir=3D"auto"><br></div><div dir=3D"auto">These k=
inds of changes are important for the development of the framework, but dem=
onstrate that it is well suited to its current development process. Maybe a=
 formal committee process will get everything ironed out in one fell swoop,=
 but Im not convinced that this is the ideal approach. I&#39;d also love to=
 see how the source would change with proposals for C++20 implemented; it i=
s currently written assuming C++11 as far as I&#39;m aware, and I can&#39;t=
 imagine this will be the situation if standardised.</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">There is also an ongoing discussion about cast=
ing (=C2=A0<a href=3D"https://github.com/nlohmann/json/issues/958" target=
=3D"_blank" rel=3D"noreferrer">https://github.com/nlohmann/<wbr>json/issues=
/958</a> ) which needs resolving, and I&#39;m under the impression that edg=
e cases sometimes arise when people want to make the library work with thei=
r custom types (I have seen various discussions on this, but for the life o=
f me I can&#39;t find any that I had in mind when I wrote that the nature o=
f the project lends itself to continual changes. Perhaps I am imagining thi=
ngs.)</div><span><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr"><=
blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;font-family:s=
ans-serif;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><div></div></div></blockquote><br></div><=
div dir=3D"ltr"><br></div><div dir=3D"ltr">On Mon, 25 Jun 2018, 17:30 j c, =
&lt;<a href=3D"mailto:james.a.cooper@gmail.com" target=3D"_blank" rel=3D"no=
referrer noreferrer noreferrer">james.a.cooper@gmail.com</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;p=
adding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bo=
rder-left-style:solid"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote">On Mon, Jun 25, 2018 at 4:38 PM, Jake Arkinstall <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:jake.arkinstall@gmail.com" target=3D"_blan=
k" rel=3D"noreferrer noreferrer noreferrer noreferrer">jake.arkinstall@gmai=
l.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204)=
;border-left-width:1px;border-left-style:solid"><div dir=3D"auto"><div>I ha=
ve been using this library for quite some time now, as part of a server app=
lication that communicates in JSON with client processes. It works beautifu=
lly.<br></div></div></blockquote><div><br></div><div>Have you compared it t=
o competing json libraries such as rapidjson?=C2=A0</div></div></div></div>=
</blockquote></div><div dir=3D"auto"><br></div></span><div dir=3D"auto">I t=
ried out quite a few, But nlohmann::json definitely stood out as the most c=
omfortable to use, most familiar (i.e. it wouldn&#39;t feel out of place in=
 the STL), and very flexible - in particular it works great with custom typ=
es. It fit my needs perfectly.</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">There are implementations that are faster (RapidJSON claimed to when=
 I tried it out - it wasn&#39;t pretty to write with, though. It&#39;s so f=
ar removed from STL styles and approaches that it feels more like writing p=
re-generics Java). There are some that are lighter in memory. There are som=
e that compile faster, and there are some that have smaller file sizes. I t=
hink it&#39;d be quite hard to decide on a single implementation to suit th=
e everyday user.</div><div class=3D"gmail_quote" dir=3D"auto"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;bor=
der-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:sol=
id">
</blockquote></div></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMSV9-oSood7iCU6d%3DBAJLHsfSB=
XUJAoCwpnRX69fj%3DuA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgi=
d/std-<wbr>proposals/CAC%2B0CCMSV9-<wbr>oSood7iCU6d%<wbr>3DBAJLHsfSBXUJAoCw=
pnRX69fj%<wbr>3DuA%40mail.gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEfefmwMH6s7t4aoGkpV9AnDZkDhWWgHhCF5=
W2qdrr8W2LoVQQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmwMH6s7t4ao=
GkpV9AnDZkDhWWgHhCF5W2qdrr8W2LoVQQ%40mail.gmail.com</a>.<br />

--0000000000001b4d99056f887bf9--

.

--000000000000c3e95d056f8883e3
Content-Type: text/plain; charset="UTF-8"

AFAIK those have been on the wishlist for a long time, but nobody's yet
offered to spec them.

XML is hard because of the whole schema thing.

CSV is hard because it does not have a spec (even the python library is a
mess).

All of the above get easier once we have actual unicode support, also.

On Tue, Jun 26, 2018 at 10:54 AM, Dejan Milosavljevic <dmilos@gmail.com>
wrote:

> Why not also: XML, INI, csv, ASN.1, ... ?
> std::string::replace(s.find("JSON"), sizeof("XML")-1, "XML");
>
> On Mon, Jun 25, 2018 at 8:02 PM, Jake Arkinstall <
> jake.arkinstall@gmail.com> wrote:
>
>> On Mon, 25 Jun 2018, 16:58 Nicol Bolas, <jmckesson@gmail.com> wrote:
>>
>> JSON itself is quite stable. Are the daily updates to this library
>> actually meaningful to its interface? And if so, why is the interface
>> undergoing daily revisions?
>>
>>
>> It does appear that the majority of changes are more to do with the
>> accessories, such as build configs.
>>
>> However, every now and then there are upgrades that would not have been
>> so easy to make if subject to the proposal process (such as removal of
>> stringstreams, accessing keys as const references rather than copying
>> values, all the way up to the introduction of a SAX parser a few months
>> ago).
>>
>> These kinds of changes are important for the development of the
>> framework, but demonstrate that it is well suited to its current
>> development process. Maybe a formal committee process will get everything
>> ironed out in one fell swoop, but Im not convinced that this is the ideal
>> approach. I'd also love to see how the source would change with proposals
>> for C++20 implemented; it is currently written assuming C++11 as far as I'm
>> aware, and I can't imagine this will be the situation if standardised.
>>
>> There is also an ongoing discussion about casting (
>> https://github.com/nlohmann/json/issues/958 ) which needs resolving, and
>> I'm under the impression that edge cases sometimes arise when people want
>> to make the library work with their custom types (I have seen various
>> discussions on this, but for the life of me I can't find any that I had in
>> mind when I wrote that the nature of the project lends itself to continual
>> changes. Perhaps I am imagining things.)
>>
>>
>>
>> On Mon, 25 Jun 2018, 17:30 j c, <james.a.cooper@gmail.com> wrote:
>>
>>> On Mon, Jun 25, 2018 at 4:38 PM, Jake Arkinstall <
>>> jake.arkinstall@gmail.com> wrote:
>>>
>>>> I have been using this library for quite some time now, as part of a
>>>> server application that communicates in JSON with client processes. It
>>>> works beautifully.
>>>>
>>>
>>> Have you compared it to competing json libraries such as rapidjson?
>>>
>>
>> I tried out quite a few, But nlohmann::json definitely stood out as the
>> most comfortable to use, most familiar (i.e. it wouldn't feel out of place
>> in the STL), and very flexible - in particular it works great with custom
>> types. It fit my needs perfectly.
>>
>> There are implementations that are faster (RapidJSON claimed to when I
>> tried it out - it wasn't pretty to write with, though. It's so far removed
>> from STL styles and approaches that it feels more like writing pre-generics
>> Java). There are some that are lighter in memory. There are some that
>> compile faster, and there are some that have smaller file sizes. I think
>> it'd be quite hard to decide on a single implementation to suit the
>> everyday user.
>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/CAC%2B0CCMSV9-oSood7iCU6d%3DB
>> AJLHsfSBXUJAoCwpnRX69fj%3DuA%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMSV9-oSood7iCU6d%3DBAJLHsfSBXUJAoCwpnRX69fj%3DuA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAEfefmwMH6s7t4aoGkpV9AnDZkDhW
> WgHhCF5W2qdrr8W2LoVQQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmwMH6s7t4aoGkpV9AnDZkDhWWgHhCF5W2qdrr8W2LoVQQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkVq100%3DaL%3DY%2BSb%3D6%2BROCRGFNKK2UhgCy2abeU6Qn5Dp3g%40mail.gmail.com.

--000000000000c3e95d056f8883e3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">AFAIK those have been on the wishlist for a long time, but=
 nobody&#39;s yet offered to spec them.<div><br></div><div>XML is hard beca=
use of the whole schema thing.</div><div><br></div><div>CSV is hard because=
 it does not have a spec (even the python library is a mess).</div><div><br=
></div><div>All of the above get easier once we have actual unicode support=
, also.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On Tue, Jun 26, 2018 at 10:54 AM, Dejan Milosavljevic <span dir=3D"ltr">&=
lt;<a href=3D"mailto:dmilos@gmail.com" target=3D"_blank">dmilos@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v>Why not also: XML, INI, csv, ASN.1, ... ?</div><div><span class=3D"m_-323=
6368428495065509gmail-pln">std::string::</span><span class=3D"m_-3236368428=
495065509gmail-pln">replace</span><span class=3D"m_-3236368428495065509gmai=
l-pun">(</span><span class=3D"m_-3236368428495065509gmail-pln">s</span><spa=
n class=3D"m_-3236368428495065509gmail-pun">.</span><span class=3D"m_-32363=
68428495065509gmail-pln">find</span><span class=3D"m_-3236368428495065509gm=
ail-pun">(</span><span class=3D"m_-3236368428495065509gmail-str">&quot;<wbr=
>JSON&quot;</span><span class=3D"m_-3236368428495065509gmail-pun">),</span>=
<span class=3D"m_-3236368428495065509gmail-pln"> </span><span class=3D"m_-3=
236368428495065509gmail-kwd">sizeof</span><span class=3D"m_-323636842849506=
5509gmail-pun">(</span><span class=3D"m_-3236368428495065509gmail-str">&quo=
t;XML&quot;</span><span class=3D"m_-3236368428495065509gmail-pun">)-</span>=
<span class=3D"m_-3236368428495065509gmail-lit">1</span><span class=3D"m_-3=
236368428495065509gmail-pun">,</span><span class=3D"m_-3236368428495065509g=
mail-pln"> </span><span class=3D"m_-3236368428495065509gmail-str">&quot;XML=
&quot;</span><span class=3D"m_-3236368428495065509gmail-pun">);</span></div=
></div><div><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On Mon, Jun 25, 2018 at 8:02 PM, Jake Arkinstall <span dir=3D"=
ltr">&lt;<a href=3D"mailto:jake.arkinstall@gmail.com" target=3D"_blank">jak=
e.arkinstall@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"auto"><span><div class=3D"gmail_quote" dir=3D"auto"><div di=
r=3D"ltr"><div style=3D"font-family:sans-serif" dir=3D"ltr">On Mon, 25 Jun =
2018, 16:58 Nicol Bolas, &lt;<a href=3D"mailto:jmckesson@gmail.com" rel=3D"=
noreferrer" target=3D"_blank">jmckesson@gmail.com</a>&gt; wrote:<br></div><=
blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;font-family:s=
ans-serif;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><div>JSON itself is quite stable. Are the=
 daily updates to this library actually meaningful to its interface? And if=
 so, why is the interface undergoing daily revisions?<br></div></div></bloc=
kquote></div></div><div dir=3D"auto"><br></div></span><div dir=3D"auto">It =
does appear that the majority of changes are more to do with the accessorie=
s, such as build configs.</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">However, every now and then there are upgrades that would not have been s=
o easy to make if subject to the proposal process (such as removal of strin=
gstreams, accessing keys as const references rather than copying values, al=
l the way up to the introduction of a SAX parser a few months ago).</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">These kinds of changes are impo=
rtant for the development of the framework, but demonstrate that it is well=
 suited to its current development process. Maybe a formal committee proces=
s will get everything ironed out in one fell swoop, but Im not convinced th=
at this is the ideal approach. I&#39;d also love to see how the source woul=
d change with proposals for C++20 implemented; it is currently written assu=
ming C++11 as far as I&#39;m aware, and I can&#39;t imagine this will be th=
e situation if standardised.</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">There is also an ongoing discussion about casting (=C2=A0<a href=3D"ht=
tps://github.com/nlohmann/json/issues/958" rel=3D"noreferrer" target=3D"_bl=
ank">https://github.com/nlohmann/<wbr>json/issues/958</a> ) which needs res=
olving, and I&#39;m under the impression that edge cases sometimes arise wh=
en people want to make the library work with their custom types (I have see=
n various discussions on this, but for the life of me I can&#39;t find any =
that I had in mind when I wrote that the nature of the project lends itself=
 to continual changes. Perhaps I am imagining things.)</div><span><div clas=
s=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr"><blockquote style=3D"margin=
:0px 0px 0px 0.8ex;padding-left:1ex;font-family:sans-serif;border-left-colo=
r:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=
=3D"ltr"><div></div></div></blockquote><br></div><div dir=3D"ltr"><br></div=
><div dir=3D"ltr">On Mon, 25 Jun 2018, 17:30 j c, &lt;<a href=3D"mailto:jam=
es.a.cooper@gmail.com" rel=3D"noreferrer noreferrer noreferrer" target=3D"_=
blank">james.a.cooper@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-=
left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jun 25, 2018 at 4:38 PM, Jake Arkinstall <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jake.arkinstall@gmail.com" rel=3D"noreferrer noreferrer noreferr=
er noreferrer" target=3D"_blank">jake.arkinstall@gmail.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px=
;border-left-style:solid"><div dir=3D"auto"><div>I have been using this lib=
rary for quite some time now, as part of a server application that communic=
ates in JSON with client processes. It works beautifully.<br></div></div></=
blockquote><div><br></div><div>Have you compared it to competing json libra=
ries such as rapidjson?=C2=A0</div></div></div></div></blockquote></div><di=
v dir=3D"auto"><br></div></span><div dir=3D"auto">I tried out quite a few, =
But nlohmann::json definitely stood out as the most comfortable to use, mos=
t familiar (i.e. it wouldn&#39;t feel out of place in the STL), and very fl=
exible - in particular it works great with custom types. It fit my needs pe=
rfectly.</div><div dir=3D"auto"><br></div><div dir=3D"auto">There are imple=
mentations that are faster (RapidJSON claimed to when I tried it out - it w=
asn&#39;t pretty to write with, though. It&#39;s so far removed from STL st=
yles and approaches that it feels more like writing pre-generics Java). The=
re are some that are lighter in memory. There are some that compile faster,=
 and there are some that have smaller file sizes. I think it&#39;d be quite=
 hard to decide on a single implementation to suit the everyday user.</div>=
<div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204=
,204,204);border-left-width:1px;border-left-style:solid">
</blockquote></div></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMSV9-oSood7iCU6d%3DBAJLHsfSB=
XUJAoCwpnRX69fj%3DuA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgi=
d/std-proposals<wbr>/CAC%2B0CCMSV9-oSood7iCU6d%3DB<wbr>AJLHsfSBXUJAoCwpnRX6=
9fj%3DuA%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEfefmwMH6s7t4aoGkpV9AnDZkDhWWgHhCF5=
W2qdrr8W2LoVQQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CAEfefmwMH6s7t4aoGkpV9AnDZkDhW<wbr>WgHhCF5W2qdrr8W2LoVQ=
Q%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkVq100%3DaL%3DY%2BSb%3D6%2BRO=
CRGFNKK2UhgCy2abeU6Qn5Dp3g%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA=
NG%3DkVq100%3DaL%3DY%2BSb%3D6%2BROCRGFNKK2UhgCy2abeU6Qn5Dp3g%40mail.gmail.c=
om</a>.<br />

--000000000000c3e95d056f8883e3--

.

--0000000000008e1212056f898216
Content-Type: text/plain; charset="UTF-8"

> Why not also: XML, INI, csv, ASN.1, ... ?

XML - because we'll soon be celebrating its death and dancing on its grave.

INI - good idea, it's useful in in all popular OSs, and really easy to read
and use. It has a long future.

CSV - another great idea!

ASN.1 - a little more esoteric, but nonetheless useful.


On Tue, 26 Jun 2018 at 11:54, Dejan Milosavljevic <dmilos@gmail.com> wrote:

> Why not also: XML, INI, csv, ASN.1, ... ?
> std::string::replace(s.find("JSON"), sizeof("XML")-1, "XML");
>
> On Mon, Jun 25, 2018 at 8:02 PM, Jake Arkinstall <
> jake.arkinstall@gmail.com> wrote:
>
>> On Mon, 25 Jun 2018, 16:58 Nicol Bolas, <jmckesson@gmail.com> wrote:
>>
>> JSON itself is quite stable. Are the daily updates to this library
>> actually meaningful to its interface? And if so, why is the interface
>> undergoing daily revisions?
>>
>>
>> It does appear that the majority of changes are more to do with the
>> accessories, such as build configs.
>>
>> However, every now and then there are upgrades that would not have been
>> so easy to make if subject to the proposal process (such as removal of
>> stringstreams, accessing keys as const references rather than copying
>> values, all the way up to the introduction of a SAX parser a few months
>> ago).
>>
>> These kinds of changes are important for the development of the
>> framework, but demonstrate that it is well suited to its current
>> development process. Maybe a formal committee process will get everything
>> ironed out in one fell swoop, but Im not convinced that this is the ideal
>> approach. I'd also love to see how the source would change with proposals
>> for C++20 implemented; it is currently written assuming C++11 as far as I'm
>> aware, and I can't imagine this will be the situation if standardised.
>>
>> There is also an ongoing discussion about casting (
>> https://github.com/nlohmann/json/issues/958 ) which needs resolving, and
>> I'm under the impression that edge cases sometimes arise when people want
>> to make the library work with their custom types (I have seen various
>> discussions on this, but for the life of me I can't find any that I had in
>> mind when I wrote that the nature of the project lends itself to continual
>> changes. Perhaps I am imagining things.)
>>
>>
>>
>> On Mon, 25 Jun 2018, 17:30 j c, <james.a.cooper@gmail.com> wrote:
>>
>>> On Mon, Jun 25, 2018 at 4:38 PM, Jake Arkinstall <
>>> jake.arkinstall@gmail.com> wrote:
>>>
>>>> I have been using this library for quite some time now, as part of a
>>>> server application that communicates in JSON with client processes. It
>>>> works beautifully.
>>>>
>>>
>>> Have you compared it to competing json libraries such as rapidjson?
>>>
>>
>> I tried out quite a few, But nlohmann::json definitely stood out as the
>> most comfortable to use, most familiar (i.e. it wouldn't feel out of place
>> in the STL), and very flexible - in particular it works great with custom
>> types. It fit my needs perfectly.
>>
>> There are implementations that are faster (RapidJSON claimed to when I
>> tried it out - it wasn't pretty to write with, though. It's so far removed
>> from STL styles and approaches that it feels more like writing pre-generics
>> Java). There are some that are lighter in memory. There are some that
>> compile faster, and there are some that have smaller file sizes. I think
>> it'd be quite hard to decide on a single implementation to suit the
>> everyday user.
>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMSV9-oSood7iCU6d%3DBAJLHsfSBXUJAoCwpnRX69fj%3DuA%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMSV9-oSood7iCU6d%3DBAJLHsfSBXUJAoCwpnRX69fj%3DuA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmwMH6s7t4aoGkpV9AnDZkDhWWgHhCF5W2qdrr8W2LoVQQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmwMH6s7t4aoGkpV9AnDZkDhWWgHhCF5W2qdrr8W2LoVQQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hb2w%2BiUvM5HhimJ-z10FrXm-Q-ZJwEBub88Y-Q4e7-DVA%40mail.gmail.com.

--0000000000008e1212056f898216
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; Why not also: XML, INI, csv, ASN.1, ... ?<div><br></d=
iv><div>XML - because we&#39;ll soon be celebrating its death and dancing o=
n its grave.</div><div><br></div><div>INI - good idea, it&#39;s useful in i=
n all popular OSs, and really easy to read and use. It has a long future.</=
div><div><br></div><div>CSV - another great idea!</div><div><br></div><div>=
ASN.1 - a little more esoteric, but nonetheless useful.</div><div><br><br><=
div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, 26 Jun 2018 at 11:54, De=
jan Milosavljevic &lt;<a href=3D"mailto:dmilos@gmail.com">dmilos@gmail.com<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v>Why not also: XML, INI, csv, ASN.1, ... ?</div><div><span class=3D"m_-534=
2201787478049977gmail-pln">std::string::</span><span class=3D"m_-5342201787=
478049977gmail-pln">replace</span><span class=3D"m_-5342201787478049977gmai=
l-pun">(</span><span class=3D"m_-5342201787478049977gmail-pln">s</span><spa=
n class=3D"m_-5342201787478049977gmail-pun">.</span><span class=3D"m_-53422=
01787478049977gmail-pln">find</span><span class=3D"m_-5342201787478049977gm=
ail-pun">(</span><span class=3D"m_-5342201787478049977gmail-str">&quot;JSON=
&quot;</span><span class=3D"m_-5342201787478049977gmail-pun">),</span><span=
 class=3D"m_-5342201787478049977gmail-pln"> </span><span class=3D"m_-534220=
1787478049977gmail-kwd">sizeof</span><span class=3D"m_-5342201787478049977g=
mail-pun">(</span><span class=3D"m_-5342201787478049977gmail-str">&quot;XML=
&quot;</span><span class=3D"m_-5342201787478049977gmail-pun">)-</span><span=
 class=3D"m_-5342201787478049977gmail-lit">1</span><span class=3D"m_-534220=
1787478049977gmail-pun">,</span><span class=3D"m_-5342201787478049977gmail-=
pln"> </span><span class=3D"m_-5342201787478049977gmail-str">&quot;XML&quot=
;</span><span class=3D"m_-5342201787478049977gmail-pun">);</span></div></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Jun 25,=
 2018 at 8:02 PM, Jake Arkinstall <span dir=3D"ltr">&lt;<a href=3D"mailto:j=
ake.arkinstall@gmail.com" target=3D"_blank">jake.arkinstall@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><span>=
<div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr"><div style=3D"font=
-family:sans-serif" dir=3D"ltr">On Mon, 25 Jun 2018, 16:58 Nicol Bolas, &lt=
;<a href=3D"mailto:jmckesson@gmail.com" rel=3D"noreferrer" target=3D"_blank=
">jmckesson@gmail.com</a>&gt; wrote:<br></div><blockquote style=3D"margin:0=
px 0px 0px 0.8ex;padding-left:1ex;font-family:sans-serif;border-left-color:=
rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=3D=
"ltr"><div>JSON itself is quite stable. Are the daily updates to this libra=
ry actually meaningful to its interface? And if so, why is the interface un=
dergoing daily revisions?<br></div></div></blockquote></div></div><div dir=
=3D"auto"><br></div></span><div dir=3D"auto">It does appear that the majori=
ty of changes are more to do with the accessories, such as build configs.</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">However, every now and th=
en there are upgrades that would not have been so easy to make if subject t=
o the proposal process (such as removal of stringstreams, accessing keys as=
 const references rather than copying values, all the way up to the introdu=
ction of a SAX parser a few months ago).</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">These kinds of changes are important for the development o=
f the framework, but demonstrate that it is well suited to its current deve=
lopment process. Maybe a formal committee process will get everything irone=
d out in one fell swoop, but Im not convinced that this is the ideal approa=
ch. I&#39;d also love to see how the source would change with proposals for=
 C++20 implemented; it is currently written assuming C++11 as far as I&#39;=
m aware, and I can&#39;t imagine this will be the situation if standardised=
..</div><div dir=3D"auto"><br></div><div dir=3D"auto">There is also an ongoi=
ng discussion about casting (=C2=A0<a href=3D"https://github.com/nlohmann/j=
son/issues/958" rel=3D"noreferrer" target=3D"_blank">https://github.com/nlo=
hmann/json/issues/958</a> ) which needs resolving, and I&#39;m under the im=
pression that edge cases sometimes arise when people want to make the libra=
ry work with their custom types (I have seen various discussions on this, b=
ut for the life of me I can&#39;t find any that I had in mind when I wrote =
that the nature of the project lends itself to continual changes. Perhaps I=
 am imagining things.)</div><span><div class=3D"gmail_quote" dir=3D"auto"><=
div dir=3D"ltr"><blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:=
1ex;font-family:sans-serif;border-left-color:rgb(204,204,204);border-left-w=
idth:1px;border-left-style:solid"><div dir=3D"ltr"><div></div></div></block=
quote><br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">On Mon, 25 Jun =
2018, 17:30 j c, &lt;<a href=3D"mailto:james.a.cooper@gmail.com" rel=3D"nor=
eferrer noreferrer noreferrer" target=3D"_blank">james.a.cooper@gmail.com</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-=
left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote">On Mon, Jun 25, 2018 at 4:38 PM, Jake A=
rkinstall <span dir=3D"ltr">&lt;<a href=3D"mailto:jake.arkinstall@gmail.com=
" rel=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">jak=
e.arkinstall@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color=
:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=
=3D"auto"><div>I have been using this library for quite some time now, as p=
art of a server application that communicates in JSON with client processes=
.. It works beautifully.<br></div></div></blockquote><div><br></div><div>Hav=
e you compared it to competing json libraries such as rapidjson?=C2=A0</div=
></div></div></div></blockquote></div><div dir=3D"auto"><br></div></span><d=
iv dir=3D"auto">I tried out quite a few, But nlohmann::json definitely stoo=
d out as the most comfortable to use, most familiar (i.e. it wouldn&#39;t f=
eel out of place in the STL), and very flexible - in particular it works gr=
eat with custom types. It fit my needs perfectly.</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">There are implementations that are faster (RapidJ=
SON claimed to when I tried it out - it wasn&#39;t pretty to write with, th=
ough. It&#39;s so far removed from STL styles and approaches that it feels =
more like writing pre-generics Java). There are some that are lighter in me=
mory. There are some that compile faster, and there are some that have smal=
ler file sizes. I think it&#39;d be quite hard to decide on a single implem=
entation to suit the everyday user.</div><div class=3D"gmail_quote" dir=3D"=
auto"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;p=
adding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bo=
rder-left-style:solid">
</blockquote></div></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMSV9-oSood7iCU6d%3DBAJLHsfSB=
XUJAoCwpnRX69fj%3DuA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAC%2B0CCMSV9-oSood7iCU6d%3DBAJLHsfSBXUJAoCwpnRX69fj%3DuA%40mail=
..gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEfefmwMH6s7t4aoGkpV9AnDZkDhWWgHhCF5=
W2qdrr8W2LoVQQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAEfefmwMH6s7t4aoGkpV9AnDZkDhWWgHhCF5W2qdrr8W2LoVQQ%40mail.gmail.com</=
a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hb2w%2BiUvM5HhimJ-z10FrXm-Q-ZJw=
EBub88Y-Q4e7-DVA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hb2w%2BiU=
vM5HhimJ-z10FrXm-Q-ZJwEBub88Y-Q4e7-DVA%40mail.gmail.com</a>.<br />

--0000000000008e1212056f898216--

.

On 2018-06-26 05:54, Dejan Milosavljevic wrote:
> Why not also: XML, INI, csv, ASN.1, ... ?

XML might be a reasonable candidate, though it has even more problems
than JSON (e.g. DOM or SAX?). As for INI and CSV, neither is a well
specified format; every application tends to parse these a little bit
differently.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6863e9aa-4a82-f032-677b-252f39c57f30%40gmail.com.

.

--0000000000005bdad7056f8c46a0
Content-Type: text/plain; charset="UTF-8"

> As for INI and CSV, neither is a well specified format; every application
tends to parse these a little bit differently.

This is also an issue that affects std::regex, but is has been overcome (to
a degree) with parameterisation at the point of compilation of the regex.

A file parser's idiosyncrasies could be configured with a traits type.



On Tue, 26 Jun 2018 at 16:02, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2018-06-26 05:54, Dejan Milosavljevic wrote:
> > Why not also: XML, INI, csv, ASN.1, ... ?
>
> XML might be a reasonable candidate, though it has even more problems
> than JSON (e.g. DOM or SAX?). As for INI and CSV, neither is a well
> specified format; every application tends to parse these a little bit
> differently.
>
> --
> Matthew
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6863e9aa-4a82-f032-677b-252f39c57f30%40gmail.com
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZYt5DQ1GU5b5fkoEbvZMUCSMgaZRaGqiGAe6F57RSHOA%40mail.gmail.com.

--0000000000005bdad7056f8c46a0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"text-decoration-style:initial;tex=
t-decoration-color:initial;float:none;display:inline">As for INI and CSV, n=
either is a well=C2=A0</span><span style=3D"text-decoration-style:initial;t=
ext-decoration-color:initial;float:none;display:inline">specified format; e=
very application tends to parse these a little bit=C2=A0</span><span style=
=3D"text-decoration-style:initial;text-decoration-color:initial;float:none;=
display:inline">differently.</span><div><br></div><div>This is also an issu=
e that affects std::regex, but is has been overcome (to a degree) with para=
meterisation at the point of compilation of the regex.</div><div><br></div>=
<div>A file parser&#39;s idiosyncrasies could be configured with a traits t=
ype.</div><div><br></div><div><br><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Tue, 26 Jun 2018 at 16:02, Matthew Woehlke &lt;<a href=3D"mailt=
o:mwoehlke.floss@gmail.com">mwoehlke.floss@gmail.com</a>&gt; wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">On 2018-06-26 05:54, Dejan Milosavljevic w=
rote:<br>
&gt; Why not also: XML, INI, csv, ASN.1, ... ?<br>
<br>
XML might be a reasonable candidate, though it has even more problems<br>
than JSON (e.g. DOM or SAX?). As for INI and CSV, neither is a well<br>
specified format; every application tends to parse these a little bit<br>
differently.<br>
<br>
-- <br>
Matthew<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6863e9aa-4a82-f032-677b-252f39c57f30%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/6863e9aa-4a82-f032-677b-252f39c57f30%40=
gmail.com</a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZYt5DQ1GU5b5fkoEbvZMUCSMgaZRaG=
qiGAe6F57RSHOA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZYt5DQ1GU5=
b5fkoEbvZMUCSMgaZRaGqiGAe6F57RSHOA%40mail.gmail.com</a>.<br />

--0000000000005bdad7056f8c46a0--

.

On Tuesday, 26 June 2018 04:07:43 PDT Richard Hodges wrote:
> INI - good idea, it's useful in in all popular OSs, and really easy to read
> and use. It has a long future.

Except for having a plethora of slightly incompatible extension formats when
it comes to more than one grouping level.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2276745.VRMxdG4x5t%40tjmaciei-mobl1.

.

On Tuesday, 26 June 2018 07:25:38 PDT Richard Hodges wrote:
> A file parser's idiosyncrasies could be configured with a traits type.

That is not a good idea, as that would imply the parser for a complex file
format is entirely inline. No, if there's anything configurable, it ought to
be at runtime.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9595960.Ih0uOeaTLg%40tjmaciei-mobl1.

.

--000000000000f0219e056f8cb0c0
Content-Type: text/plain; charset="UTF-8"

On Tue, 26 Jun 2018 at 16:46, Thiago Macieira <thiago@macieira.org> wrote:

> On Tuesday, 26 June 2018 07:25:38 PDT Richard Hodges wrote:
> > A file parser's idiosyncrasies could be configured with a traits type.
>
> That is not a good idea, as that would imply the parser for a complex file
> format is entirely inline. No, if there's anything configurable, it ought
> to
> be at runtime.
>

That's one way. Another might be that the parser is actually a 'view'
attached to a stream, range, polymorphic (possibly even coroutine-enabled)
character source.
I think that this would allow customisation without being limited by
enums/existing traits etc.



>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9595960.Ih0uOeaTLg%40tjmaciei-mobl1
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZCA-0yTsUKDe2%3Du6KC_4LHLdcYVotQtDO-H8VGCq-f3w%40mail.gmail.com.

--000000000000f0219e056f8cb0c0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue=
, 26 Jun 2018 at 16:46, Thiago Macieira &lt;<a href=3D"mailto:thiago@maciei=
ra.org">thiago@macieira.org</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">On Tuesday, 26 June 2018 07:25:38 PDT Richard Hodges wrote:<br>
&gt; A file parser&#39;s idiosyncrasies could be configured with a traits t=
ype.<br>
<br>
That is not a good idea, as that would imply the parser for a complex file =
<br>
format is entirely inline. No, if there&#39;s anything configurable, it oug=
ht to <br>
be at runtime.<br></blockquote><div><br></div><div>That&#39;s one way. Anot=
her might be that the parser is actually a &#39;view&#39; attached to a str=
eam, range, polymorphic (possibly even coroutine-enabled) character source.=
</div><div>I think that this would allow customisation without being limite=
d by enums/existing traits etc.</div><div><br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex">
<br>
-- <br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9595960.Ih0uOeaTLg%40tjmaciei-mobl1" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org=
/d/msgid/std-proposals/9595960.Ih0uOeaTLg%40tjmaciei-mobl1</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZCA-0yTsUKDe2%3Du6KC_4LHLdcYVo=
tQtDO-H8VGCq-f3w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZCA-0yTs=
UKDe2%3Du6KC_4LHLdcYVotQtDO-H8VGCq-f3w%40mail.gmail.com</a>.<br />

--000000000000f0219e056f8cb0c0--

.

------=_Part_47558_220183271.1530079719956
Content-Type: multipart/alternative;
 boundary="----=_Part_47559_108962029.1530079719956"

------=_Part_47559_108962029.1530079719956
Content-Type: text/plain; charset="UTF-8"

On Tuesday, June 26, 2018 at 5:02:52 PM UTC+3, Matthew Woehlke wrote:
>
> On 2018-06-26 05:54, Dejan Milosavljevic wrote:
> > Why not also: XML, INI, csv, ASN.1, ... ?
>
> XML might be a reasonable candidate, though it has even more problems
> than JSON (e.g. DOM or SAX?).
>

Don't we have the same choice for JSON: document-tree vs stream processing?
What is the difference in this respect?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/33074f58-eaa1-4f2c-ada9-11a22ab0bd88%40isocpp.org.

------=_Part_47559_108962029.1530079719956
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, June 26, 2018 at 5:02:52 PM UTC+3, Matthew Woe=
hlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2018-06-26 05:54=
, Dejan Milosavljevic wrote:
<br>&gt; Why not also: XML, INI, csv, ASN.1, ... ?
<br>
<br>XML might be a reasonable candidate, though it has even more problems
<br>than JSON (e.g. DOM or SAX?).<br></blockquote><div><br></div><div>Don&#=
39;t we have the same choice for JSON: document-tree vs stream processing? =
What is the difference in this respect?<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/33074f58-eaa1-4f2c-ada9-11a22ab0bd88%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/33074f58-eaa1-4f2c-ada9-11a22ab0bd88=
%40isocpp.org</a>.<br />

------=_Part_47559_108962029.1530079719956--

------=_Part_47558_220183271.1530079719956--

.

--0000000000001f5031056f9bce92
Content-Type: text/plain; charset="UTF-8"

On Wed, Jun 27, 2018 at 7:08 AM, Victor Dyachenko <
victor.dyachenko@gmail.com> wrote:

> On Tuesday, June 26, 2018 at 5:02:52 PM UTC+3, Matthew Woehlke wrote:
>>
>> On 2018-06-26 05:54, Dejan Milosavljevic wrote:
>> > Why not also: XML, INI, csv, ASN.1, ... ?
>>
>> XML might be a reasonable candidate, though it has even more problems
>> than JSON (e.g. DOM or SAX?).
>>
>
> Don't we have the same choice for JSON: document-tree vs stream
> processing? What is the difference in this respect?
>

There is no choice, any parser would need to support both.
Otherwise people will just revert back to 3rd-party parsers for anything
other than trivial use-cases

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCBhsD5nadvnPFpcHL9t4uc4pwUNmqN4aYi3HV19eW-vUQ%40mail.gmail.com.

--0000000000001f5031056f9bce92
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Jun 27, 2018 at 7:08 AM, Victor Dyachenko <span dir=3D"ltr">&lt=
;<a href=3D"mailto:victor.dyachenko@gmail.com" target=3D"_blank">victor.dya=
chenko@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><span>On Tuesday, June 26, 2018 at 5:02:52 PM UTC+3, Matthew=
 Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-06-26 05:54,=
 Dejan Milosavljevic wrote:
<br>&gt; Why not also: XML, INI, csv, ASN.1, ... ?
<br>
<br>XML might be a reasonable candidate, though it has even more problems
<br>than JSON (e.g. DOM or SAX?).<br></blockquote><div><br></div></span><di=
v>Don&#39;t we have the same choice for JSON: document-tree vs stream proce=
ssing? What is the difference in this respect?<br></div></div></blockquote>=
<div><br></div><div>There is no choice, any parser would need to support bo=
th.</div><div>Otherwise people will just revert back to 3rd-party parsers f=
or anything other than trivial use-cases<br></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFQaeCBhsD5nadvnPFpcHL9t4uc4pwUNmqN4=
aYi3HV19eW-vUQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCBhsD5nadvn=
PFpcHL9t4uc4pwUNmqN4aYi3HV19eW-vUQ%40mail.gmail.com</a>.<br />

--0000000000001f5031056f9bce92--

.

------=_Part_24089_493980898.1530090550442
Content-Type: multipart/alternative;
 boundary="----=_Part_24090_1755337579.1530090550443"

------=_Part_24090_1755337579.1530090550443
Content-Type: text/plain; charset="UTF-8"

On Wednesday, June 27, 2018 at 11:57:33 AM UTC+3, j c wrote:
>
>
>
> On Wed, Jun 27, 2018 at 7:08 AM, Victor Dyachenko <victor.d...@gmail.com
> <javascript:>> wrote:
>
>> On Tuesday, June 26, 2018 at 5:02:52 PM UTC+3, Matthew Woehlke wrote:
>>>
>>> On 2018-06-26 05:54, Dejan Milosavljevic wrote:
>>> > Why not also: XML, INI, csv, ASN.1, ... ?
>>>
>>> XML might be a reasonable candidate, though it has even more problems
>>> than JSON (e.g. DOM or SAX?).
>>>
>>
>> Don't we have the same choice for JSON: document-tree vs stream
>> processing? What is the difference in this respect?
>>
>
> There is no choice, any parser would need to support both.
> Otherwise people will just revert back to 3rd-party parsers for anything
> other than trivial use-cases
>

So don't forget to add:

1) "pull" vs "push" parsing control
2) Destructive (AKA in situ) parsing support
3) JSONPath (???)
4) What else?

I think trying to cover everything is a crazy idea. Any complex task has
more than one solution, so providing std:: facilities can't eliminate
3rd-party solutions.



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3d9f902c-aff9-43fd-9cf4-011e7c17acfc%40isocpp.org.

------=_Part_24090_1755337579.1530090550443
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, June 27, 2018 at 11:57:33 AM UTC+3, j c wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><b=
r><div class=3D"gmail_quote">On Wed, Jun 27, 2018 at 7:08 AM, Victor Dyache=
nko <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"ZACUmVvLCAAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">victor.d...@gmail.com</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><span>On Tuesday, June 26, 2018 =
at 5:02:52 PM UTC+3, Matthew Woehlke wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">On 2018-06-26 05:54, Dejan Milosavljevic wrote:
<br>&gt; Why not also: XML, INI, csv, ASN.1, ... ?
<br>
<br>XML might be a reasonable candidate, though it has even more problems
<br>than JSON (e.g. DOM or SAX?).<br></blockquote><div><br></div></span><di=
v>Don&#39;t we have the same choice for JSON: document-tree vs stream proce=
ssing? What is the difference in this respect?<br></div></div></blockquote>=
<div><br></div><div>There is no choice, any parser would need to support bo=
th.</div><div>Otherwise people will just revert back to 3rd-party parsers f=
or anything other than trivial use-cases<br></div></div></div></div></block=
quote><div><br></div><div><div>So don&#39;t forget to add:</div><div><br></=
div><div>1) &quot;pull&quot; vs &quot;push&quot; parsing control</div><div>=
2) Destructive (AKA in situ) parsing support</div><div>3) JSONPath (???)</d=
iv><div>4) What else?</div><div><br></div><div>I
 think trying to cover everything is a crazy idea. Any complex task has=20
more than one solution, so providing std:: facilities can&#39;t eliminate 3=
rd-party solutions.<br></div><div><br></div>=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3d9f902c-aff9-43fd-9cf4-011e7c17acfc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3d9f902c-aff9-43fd-9cf4-011e7c17acfc=
%40isocpp.org</a>.<br />

------=_Part_24090_1755337579.1530090550443--

------=_Part_24089_493980898.1530090550442--

.

--0000000000004ff6b2056f9c3852
Content-Type: text/plain; charset="UTF-8"

On Wed, Jun 27, 2018 at 10:09 AM, Victor Dyachenko <
victor.dyachenko@gmail.com> wrote:

> On Wednesday, June 27, 2018 at 11:57:33 AM UTC+3, j c wrote:
>>
>>
>>
>> On Wed, Jun 27, 2018 at 7:08 AM, Victor Dyachenko <victor.d...@gmail.com>
>> wrote:
>>
>>> On Tuesday, June 26, 2018 at 5:02:52 PM UTC+3, Matthew Woehlke wrote:
>>>>
>>>> On 2018-06-26 05:54, Dejan Milosavljevic wrote:
>>>> > Why not also: XML, INI, csv, ASN.1, ... ?
>>>>
>>>> XML might be a reasonable candidate, though it has even more problems
>>>> than JSON (e.g. DOM or SAX?).
>>>>
>>>
>>> Don't we have the same choice for JSON: document-tree vs stream
>>> processing? What is the difference in this respect?
>>>
>>
>> There is no choice, any parser would need to support both.
>> Otherwise people will just revert back to 3rd-party parsers for anything
>> other than trivial use-cases
>>
>
> So don't forget to add:
>
> 1) "pull" vs "push" parsing control
> 2) Destructive (AKA in situ) parsing support
> 3) JSONPath (???)
> 4) What else?
>
> I think trying to cover everything is a crazy idea. Any complex task has
> more than one solution, so providing std:: facilities can't eliminate
> 3rd-party solutions.
>
>
Given the popularity of JSON in things HTTP-related it really would need to
support stream processing if C++ is to try break into these domains.
In-situ also if C++ really believes that it's tool for writing
performance-oriented applications.

Is JSONPath part of rfc7159? If not then, there's no pushing need to
support it IMO.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAg9OVnzyAP4ykdLk_2hgJBQpjqt7JsLcVSSXt7xRrCPg%40mail.gmail.com.

--0000000000004ff6b2056f9c3852
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Jun 27, 2018 at 10:09 AM, Victor Dyachenko <span dir=3D"ltr">&l=
t;<a href=3D"mailto:victor.dyachenko@gmail.com" target=3D"_blank">victor.dy=
achenko@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(=
204,204,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr=
">On Wednesday, June 27, 2018 at 11:57:33 AM UTC+3, j c wrote:<span><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1=
ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-sty=
le:solid"><div dir=3D"ltr"><br><div><br><div class=3D"gmail_quote">On Wed, =
Jun 27, 2018 at 7:08 AM, Victor Dyachenko <span dir=3D"ltr">&lt;<a rel=3D"n=
ofollow">victor.d...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-=
left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">=
<div dir=3D"ltr"><span>On Tuesday, June 26, 2018 at 5:02:52 PM UTC+3, Matth=
ew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-w=
idth:1px;border-left-style:solid">On 2018-06-26 05:54, Dejan Milosavljevic =
wrote:
<br>&gt; Why not also: XML, INI, csv, ASN.1, ... ?
<br>
<br>XML might be a reasonable candidate, though it has even more problems
<br>than JSON (e.g. DOM or SAX?).<br></blockquote><div><br></div></span><di=
v>Don&#39;t we have the same choice for JSON: document-tree vs stream proce=
ssing? What is the difference in this respect?<br></div></div></blockquote>=
<div><br></div><div>There is no choice, any parser would need to support bo=
th.</div><div>Otherwise people will just revert back to 3rd-party parsers f=
or anything other than trivial use-cases<br></div></div></div></div></block=
quote><div><br></div></span><div><div>So don&#39;t forget to add:</div><div=
><br></div><div>1) &quot;pull&quot; vs &quot;push&quot; parsing control</di=
v><div>2) Destructive (AKA in situ) parsing support</div><div>3) JSONPath (=
???)</div><div>4) What else?</div><div><br></div><div>I
 think trying to cover everything is a crazy idea. Any complex task has=20
more than one solution, so providing std:: facilities can&#39;t eliminate 3=
rd-party solutions.<br></div><div><br></div></div></div></blockquote><div><=
br></div><div>Given the popularity of JSON in things HTTP-related it really=
 would need to support stream processing if C++ is to try break into these =
domains.</div><div>In-situ also if C++ really believes that it&#39;s tool f=
or writing performance-oriented applications.</div><div><br></div><div>Is J=
SONPath part of=C2=A0rfc7159? If not then, there&#39;s no pushing need to s=
upport it IMO.</div><div><br></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAg9OVnzyAP4ykdLk_2hgJBQpjqt7Js=
LcVSSXt7xRrCPg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAg9OVnzyAP=
4ykdLk_2hgJBQpjqt7JsLcVSSXt7xRrCPg%40mail.gmail.com</a>.<br />

--0000000000004ff6b2056f9c3852--

.