This way or the other

[Daniel]

Suppose we have some classes,

struct A
{
typedef char char_type;
};

struct B
{
typedef wchar_t char_type;
};

and some functions that take instances of these classes along with a
string. Would you be inclined to write those functions like this:

// (*)
template <class T>
void f(const T& t, const std::basic_string<typename T::char_type>& s)
{}

or like this

// (**)
template <class T, class CharT>
typename std::enable_if<std::is_same<typename T::char_type,CharT>::value,void>::type
g(const T& t, const std::basic_string<CharT>& s)
{}

or some other way? Criteria are technical reasons and ease of documentation.

(In this construction, it is ruled out that A and B can be
specializations of a common class templated on CharT.)

Thanks,
Daniel

[Mr Flibble]

On 28/01/2019 18:05, Daniel wrote:
> Suppose we have some classes,
>
> struct A
> {
> typedef char char_type;
> };
>
> struct B
> {
> typedef wchar_t char_type;
> };

Don't use wchar_t as it isn't portable so is next to useless. We have
Unicode now.

/Flibble

--
“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” –
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."

[Daniel]

On Monday, January 28, 2019 at 1:14:08 PM UTC-5, Mr Flibble wrote:
> On 28/01/2019 18:05, Daniel wrote:
> > Suppose we have some classes,
> >
> > struct A
> > {
> > typedef char char_type;
> > };
> >
> > struct B
> > {
> > typedef wchar_t char_type;
> > };
>
> Don't use wchar_t as it isn't portable so is next to useless. We have
> Unicode now.
>

In practice, char everywhere and 16 bit wchar_t on Windows only
are the only character types that currently matter for a library
writer that aspires to having users. You may regret that wchar_t
exists, but there is a substantial amount of code that has it. In
any case, feel free to substitute char16_t or char32_t, or
another type altogether, the question is the same.

Daniel

[Mr Flibble]

In practice, if you know what you are doing, a library writer that aspires
to having users will have as little OS specific (Windows) code in their
libraries as possible. I have removed most of the wchar_t from "neolib"
and only have one instance of wchar_t in "neoGFX" (which is much larger
than "neolib").

[Daniel]

On Monday, January 28, 2019 at 4:27:50 PM UTC-5, Mr Flibble >

> In practice, if you know what you are doing, a library writer that aspires
> to having users will have as little OS specific (Windows) code in their
> libraries as possible. I have removed most of the wchar_t from "neolib"
> and only have one instance of wchar_t in "neoGFX" (which is much larger
> than "neolib").
>

I note that CharT is a template parameter in your
basic_json_value, hopefully everything will work as expected if
someone plugs in a wchar_t, because char and wchar_t are probably
the only things that anybody will plug into it.

I believe RapidJson supports templated encoding, jsoncons has a
CharT parameter, but I don't think any of the other libraries do.
nhlomann doesn't, and its absence certainly hasn't hurt it's
popularity. In jsoncons, the assumption is that char is UTF8,
char16_t is UTF16, char32_t is UTF32, and wchar_t is UTF16 if
sizeof(wchar_t) is 2 chars, and UTF32 if sizeof(wchar_t) is 4
chars. Unicode validation is performed based on those
assumptions. In any case, I wouldn't expect anyone to specialize
with anything other than char and wchar_t.

In retrospect, I think that having a CharT template parameter in
jsoncons may have been a mistake, and an approach more similar to
std::filesystem might have been better. It would, after all, be
relatively straightforward to hold text in the variant as UTF8,
and have templated accessor as<String> to return whatever
encoding the user wants as deduced from String::char_type,
performing the conversion from UTF8 on demand. Similarly with
stream operators.

Daniel

[Mr Flibble]

On 28/01/2019 22:28, Daniel wrote:
> popularity. In jsoncons, the assumption is that char is UTF8,
> char16_t is UTF16, char32_t is UTF32, and wchar_t is UTF16 if
> sizeof(wchar_t) is 2 chars, and UTF32 if sizeof(wchar_t) is 4
> chars.

Is that UTF16BE or UTF16LE? In my JSON lib the whole point of the CharT
template parameter is that is matches the document text format and that
allows string objects to be created without performing an allocation (they
just point to the document text).

[Daniel]

On Monday, January 28, 2019 at 6:00:39 PM UTC-5, Mr Flibble wrote:
> On 28/01/2019 22:28, Daniel wrote:
> > popularity. In jsoncons, the assumption is that char is UTF8,
> > char16_t is UTF16, char32_t is UTF32, and wchar_t is UTF16 if
> > sizeof(wchar_t) is 2 chars, and UTF32 if sizeof(wchar_t) is 4
> > chars.
>
> Is that UTF16BE or UTF16LE?

In memory, it assumes the endiness of the underlying hardware. Reading,
it performs a check to detect the encoding, and should fail if it doesn't
match the assumed encoding. I agree this is not an ideal solution :-) In
practice, almost everybody that's using this software uses char and UTF8, or
else is living in a little endian x64 world.

> In my JSON lib the whole point of the CharT
> template parameter is that is matches the document text format and that
> allows string objects to be created without performing an allocation (they
> just point to the document text).
>

That's one approach that some libraries follow, or support (e.g. RapidJson
with parse_insitu). I'm not that enthusiastic about it myself, as I would
normally read the document text in chunks and not keep it around. But it has
its place.

Daniel