------=_Part_1040_970981230.1411520631756
Content-Type: text/plain; charset=UTF-8

A few times, I have written hand rolled ascii routines as optimized
versions of the routimes in <cctype>.

For example:

namespace std {
namespace ascii {
constexpr int isspace(char c) noexcept { return c == ' ' || c == '\f' || c
== '\n' || c == '\r' || c == '\t' || c == '\v';
} //namespace ascii
} //namespace std

In some cases I found these to be much faster than the <cctype> equivalents
because cctype uses runtime dispatch to handle the global locale setting. I
used these for times when I had a pre-condition that the input string was
ascii. Ascii is still important these days because its very easy to parse.
Many large data sets use ascii separators, such as large csv files exported
from microsoft excel. For very large data files, parsing can take a
significant portion of the entire application run time.

Runtime dispatch is very slow because it limits the compiler and hardware's
opportunities to optimize branching. For ascii, these checks are very
simple. They are inlined which might also allow an optimizer to vectorize
the character checks performed in a loop on a string. Finally, this version
is also constexpr, allowing use in template logic and constexpr string code.

A further direction could be to also support unicode character checks, but
I'm not sure if that even makes sense. To ask what is a digit in an
encoding which covers all possible languages is a sort of ambiguous
question.



--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">A few times, I have written hand rolled ascii routines as =
optimized versions of the routimes in &lt;cctype&gt;.<div><br></div><div>Fo=
r example:<br><div><br></div><div><div class=3D"prettyprint" style=3D"backg=
round-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word=
-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #008;" class=3D"styled-by-prettify">namespace</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> std </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">namespace</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> ascii </span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><font color=3D"#000088"><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">int</span></font><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> isspace</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">char</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> c</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> noexcept </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> c </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #080;" class=3D"styled-by-prettify">' '</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">||</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> c </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">'\f'=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">||</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> c </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" c=
lass=3D"styled-by-prettify">'\n'</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">||</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> c </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #080;" class=3D"styled-by-prettify">'\r'</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">||</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> c </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"s=
tyled-by-prettify">'\t'</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">||</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #080;" class=3D"styled-by-prettify">'\v'</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><font color=3D"#6666=
00"><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></=
font><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">//namespace ascii</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">}</span><font color=3D"#000=
000"><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">//namespace std</span=
></font><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n></div></code></div><div><br></div>In some cases I found these to be much =
faster than the &lt;cctype&gt; equivalents because cctype uses runtime disp=
atch to handle the global locale setting. I used these for times when I had=
 a pre-condition that the input string was ascii. Ascii is still important =
these days because its very easy to parse. Many large data sets use ascii s=
eparators, such as large csv files exported from microsoft excel. For very =
large data files, parsing can take a significant portion of the entire appl=
ication run time.</div><div><br></div><div>Runtime dispatch is very slow be=
cause it limits the compiler and hardware's opportunities to optimize branc=
hing. For ascii, these checks are very simple. They are inlined which might=
 also allow an optimizer to vectorize the character checks performed in a l=
oop on a string. Finally, this version is also constexpr, allowing use in t=
emplate logic and constexpr string code.</div><div><br></div><div>A further=
 direction could be to also support unicode character checks, but I'm not s=
ure if that even makes sense. To ask what is a digit in an encoding which c=
overs all possible languages is a sort of ambiguous question.</div><div><br=
></div><div><br></div><div><br></div></div></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1040_970981230.1411520631756--

.

------=_Part_7241_1294235141.1411651931996
Content-Type: text/plain; charset=UTF-8

I like it :)

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_7241_1294235141.1411651931996
Content-Type: text/html; charset=UTF-8

<div dir="ltr">I like it :)</div>

<p></p>

-- <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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_7241_1294235141.1411651931996--

.

------=_Part_8609_1004182954.1411652159991
Content-Type: text/plain; charset=UTF-8

I've put up a draft proposal and header here:

https://github.com/fmatthew5876/stdcxx-ascii

I'm also trying to research if including isascii() is worthwhile. Part of
that research involves this SO question:

http://stackoverflow.com/questions/26030928/why-is-isascii-deprecated

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">I've put up a draft proposal and header here:<br><br>https=
://github.com/fmatthew5876/stdcxx-ascii<br><br>I'm also trying to research =
if including isascii() is worthwhile. Part of that research involves this S=
O question:<br><br>http://stackoverflow.com/questions/26030928/why-is-isasc=
ii-deprecated<br><br></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_8609_1004182954.1411652159991--

.

------=_Part_30_928789508.1411757632200
Content-Type: text/plain; charset=UTF-8

A final version of the proposal is here:

https://github.com/fmatthew5876/stdcxx-ascii
<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-ascii&sa=D&sntz=1&usg=AFQjCNGPEl1MJgYu6lvpkqLc3VrVMtTsZw>

Does anyone have any feedback or suggestions? Is the lack of response an
indication that this is not a good idea?

Thanks!

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">A final version of the proposal is here:<br><br><a href=3D=
"https://www.google.com/url?q=3Dhttps%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fs=
tdcxx-ascii&amp;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNGPEl1MJgYu6lvpkqLc3VrVM=
tTsZw" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com=
/url?q\75https%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-ascii\46sa\75D\46=
sntz\0751\46usg\75AFQjCNGPEl1MJgYu6lvpkqLc3VrVMtTsZw';return true;" onclick=
=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2F=
fmatthew5876%2Fstdcxx-ascii\46sa\75D\46sntz\0751\46usg\75AFQjCNGPEl1MJgYu6l=
vpkqLc3VrVMtTsZw';return true;">https://github.com/<wbr>fmatthew5876/stdcxx=
-ascii</a><br><br>Does anyone have any feedback or suggestions? Is the lack=
 of response an indication that this is not a good idea?<br><br>Thanks!<br>=
<br></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_30_928789508.1411757632200--

.

On 26 September 2014 21:53, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
> A final version of the proposal is here:
>
> https://github.com/fmatthew5876/stdcxx-ascii
>
> Does anyone have any feedback or suggestions? Is the lack of response an
> indication that this is not a good idea?


Seems quite decent to me. To the LEWG!

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_21_78073639.1411789978107
Content-Type: text/plain; charset=UTF-8

On Friday, September 26, 2014 11:53:52 AM UTC-7, Matthew Fioravante wrote:
>
> A final version of the proposal is here:
>
> https://github.com/fmatthew5876/stdcxx-ascii
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-ascii&sa=D&sntz=1&usg=AFQjCNGPEl1MJgYu6lvpkqLc3VrVMtTsZw>
>
> Does anyone have any feedback or suggestions? Is the lack of response an
> indication that this is not a good idea?
>
> Thanks!
>
>
How should wchar_t, char16_t and char32_t be handled?  int is not
guaranteed to be large enough to hold them.  One way is to have isascii()
be a template function that actually has meaning, returning whether its
parameter is within +00 to +7F (or +7E, if you don't count the +7F
backspace).

How should negative integers be handled?  It has always been very annoying
that calling C's isdigit, etc. requires static_cast<unsigned char>(c) all
the time, otherwise you assert in debug builds when your input is UTF-8,
or, worse, cause undefined behavior--reading a table in la-la land--in
release builds.

What about the fact that many, if not most, C implementations currently
implement these functions as macros?  Calling these functions will be
annoying like it is with numeric_limits: combined with the above, you'll
have to call them like this:

template <typename T>
bool decode_hex_string(const char *string, T &output)
{
    enum : std::ptrdiff_t { NUM_NIBBLES = std::numeric_limits<T>::digits / 4
};
    static_assert(std::is_unsigned<T>::value, "only unsigned types are
allowed");
    static_assert(std::numeric_limits<T>::digits % 4 == 0,
        "the type must have a number of bits that's a multiple of 4");

    T result = 0;

    for (const char *current = string; current - string <= NUM_NIBBLES; ++
current)
    {
        char ch = *current;
        if (ch == '\0')
        {
            if (current == string)
                break;
            output = result;
            return true;
        }

        // The lovely extra parentheses and the static_cast.
        if (!(std::ascii::isxdigit)(static_cast<unsigned char>(ch)))
            return false;
        int nibble = (std::ascii::toxdigit)(static_cast<unsigned char>(ch));

        // Safe even if promotion results in a signed integer type--
        // the Standard allows left-shifting into the sign bit.
        result <<= 4;
        // This, however, is not safe, so protect against mishaps.
        result = static_cast<T>(static_cast<unsigned>(nibble) +
            static_cast<std::make_unsigned_t<decltype(+result)>>(+result));
    }
    return false;
}



--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Friday, September 26, 2014 11:53:52 AM UTC-7, Matthew F=
ioravante 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"lt=
r">A final version of the proposal is here:<br><br><a href=3D"https://www.g=
oogle.com/url?q=3Dhttps%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-ascii&am=
p;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNGPEl1MJgYu6lvpkqLc3VrVMtTsZw" target=
=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75http=
s%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-ascii\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNGPEl1MJgYu6lvpkqLc3VrVMtTsZw';return true;" onclick=3D"this.href=
=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ffmatthew5876%=
2Fstdcxx-ascii\46sa\75D\46sntz\0751\46usg\75AFQjCNGPEl1MJgYu6lvpkqLc3VrVMtT=
sZw';return true;">https://github.com/<wbr>fmatthew5876/stdcxx-ascii</a><br=
><br>Does anyone have any feedback or suggestions? Is the lack of response =
an indication that this is not a good idea?<br><br>Thanks!<br><br></div></b=
lockquote><div><br>How should wchar_t, char16_t and char32_t be handled?&nb=
sp; int is not guaranteed to be large enough to hold them.&nbsp; One way is=
 to have isascii() be a template function that actually has meaning, return=
ing whether its parameter is within +00 to +7F (or +7E, if you don't count =
the +7F backspace).<br><br>How should negative integers be handled?&nbsp; I=
t has always been very annoying that calling C's isdigit, etc. requires sta=
tic_cast&lt;unsigned char&gt;(c) all the time, otherwise you assert in debu=
g builds when your input is UTF-8, or, worse, cause undefined behavior--rea=
ding a table in la-la land--in release builds.<br><br>What about the fact t=
hat many, if not most, C implementations currently implement these function=
s as macros?&nbsp; Calling these functions will be annoying like it is with=
 numeric_limits: combined with the above, you'll have to call them like thi=
s:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 25=
0, 250); border-color: rgb(187, 187, 187); border-style: solid; border-widt=
h: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"s=
ubprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">te=
mplate</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> decode_hex_string</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">char</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
*</span><span style=3D"color: #008;" class=3D"styled-by-prettify">string</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> T </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">output</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">enum</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">ptrdiff_t </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> NUM_NIBBLES </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">numeric_limits</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">digits </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">/</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">4=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">static_assert</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">is_unsigned</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&gt;::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">value</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"only =
unsigned types are allowed"</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">static_assert</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">nume=
ric_limits</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">digits </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">%</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
066;" class=3D"styled-by-prettify">4</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pretti=
fy">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nb=
sp; &nbsp; &nbsp; </span><span style=3D"color: #080;" class=3D"styled-by-pr=
ettify">"the type must have a number of bits that's a multiple of 4"</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; T result </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br><br>&nbsp; &nbsp; </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">for</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">char</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">current </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">string</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> current </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">-</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">string</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> NUM_NIBBL=
ES</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">++</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">current</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">char</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> ch </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">current</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">if</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c=
h </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #080;" class=3D"styled-by-prettify">'\0'</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">if</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">current </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">string</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">break</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; output </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> result</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">true</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br><br>&nbsp; &nbsp; &nbsp; &nbsp;=
 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// The lo=
vely extra parentheses and the static_cast.</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(!(</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">ascii</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">isxdigit</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>)(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">static_=
cast</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">unsigned</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">char</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">ch</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">)))</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">false</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> nibble </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">ascii</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">to=
xdigit</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)(</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">static_cast<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">unsigned</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">char</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">ch</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">));</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// Safe even if promotion re=
sults in a signed integer type--</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// the Standard allows left-=
shifting into the sign bit.</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; result </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #066;" class=3D"styled-by-prettify">4</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"=
color: #800;" class=3D"styled-by-prettify">// This, however, is not safe, s=
o protect against mishaps.</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; result </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">static_cast</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&gt;(</span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">static_cast</span><span style=3D"color: #080;" class=3D"styled-=
by-prettify">&lt;unsigned&gt;</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">nibble</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">+</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">static_cast</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">make_=
unsigned_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">declty=
pe</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(+</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">result</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">)&gt;&gt;(+</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">result</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">));</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">false</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br><br></span></div></code></div><br><br></div></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_21_78073639.1411789978107--

.

On Friday 26 September 2014 20:52:57 Myriachan wrote:
> How should wchar_t, char16_t and char32_t be handled?  int is not

I'm not sure they have to. But we can add the char16_t and char32_t overloads
because ASCII is a strict subset of UTF-16 and UTF-32, so the code is exactly
the same.

> guaranteed to be large enough to hold them.  One way is to have isascii()
> be a template function that actually has meaning, returning whether its
> parameter is within +00 to +7F (or +7E, if you don't count the +7F
> backspace).

I don't see how char16_t or char32_t wouldn't be wide enough to contain ASCII
if, by definition, they contain UTF-16 and UTF-32 codepoints that are a
superset of ASCII.

I don't think this needs to be a template either, but I would think that
char16_t and char32_t make sense.

Let's just drop wchar_t.

> How should negative integers be handled?  It has always been very annoying
> that calling C's isdigit, etc. requires static_cast<unsigned char>(c) all
> the time, otherwise you assert in debug builds when your input is UTF-8,
> or, worse, cause undefined behavior--reading a table in la-la land--in
> release builds.

I'm not sure how this is even a question. Negative numbers aren't ASCII,
therefore they fail any trait test.

> What about the fact that many, if not most, C implementations currently
> implement these functions as macros?  Calling these functions will be
> annoying like it is with numeric_limits: combined with the above, you'll
> have to call them like this:

That is an issue. We'd have to find an identifier that doesn't collide.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Friday, September 26, 2014 11:50:10 PM UTC-7, Thiago Macieira wrote:
>
> On Friday 26 September 2014 20:52:57 Myriachan wrote:=20
> > How should wchar_t, char16_t and char32_t be handled?  int is not=20
>
> I'm not sure they have to. But we can add the char16_t and char32_t=20
> overloads=20
> because ASCII is a strict subset of UTF-16 and UTF-32, so the code is=20
> exactly=20
> the same.=20
>
>
I meant that, for example, on systems with a 16-bit "int", attempting to=20
pass a char32_t to std::ascii::isdigit(int) would be bad.  But yes, with=20
overloads for them, this problem is avoided.

> guaranteed to be large enough to hold them.  One way is to have isascii()=
=20
> > be a template function that actually has meaning, returning whether its=
=20
> > parameter is within +00 to +7F (or +7E, if you don't count the +7F=20
> > backspace).=20
>
> I don't see how char16_t or char32_t wouldn't be wide enough to contain=
=20
> ASCII=20
> if, by definition, they contain UTF-16 and UTF-32 codepoints that are a=
=20
> superset of ASCII.=20
>
>
I meant that "int" can't necessarily hold char16_t and char32_t.
=20

> I don't think this needs to be a template either, but I would think that=
=20
> char16_t and char32_t make sense.=20
>
> Let's just drop wchar_t.=20
>
>
Even when the rest of STL supports it, like std::iswdigit?
=20

> > How should negative integers be handled?  It has always been very=20
> annoying=20
> > that calling C's isdigit, etc. requires static_cast<unsigned char>(c)=
=20
> all=20
> > the time, otherwise you assert in debug builds when your input is UTF-8=
,=20
> > or, worse, cause undefined behavior--reading a table in la-la land--in=
=20
> > release builds.=20
>
> I'm not sure how this is even a question. Negative numbers aren't ASCII,=
=20
> therefore they fail any trait test.=20
>
>
This question is actually quite relevant.  This has been a source of crash=
=20
bugs with the C library functions for decades.  On an implementation where=
=20
"char" is signed, which is most, the following is undefined behavior:

const char *string =3D u8"=E7=8C=AB";
if (!isdigit(*string))
    return false;

This is because isdigit takes a parameter of type int, not char.  The UTF-8=
=20
encoding of the string ends up with negative chars, which get sign-extended=
=20
to negative ints.  Passing negative ints (*) to isdigit, etc. results in=20
undefined behavior.  The proper way to call the isdigit family of functions=
=20
is as follows:

const char *string =3D u8"=E7=8C=AB";
if (!isdigit(static_cast<unsigned char>(*string)))
    return false;

And that's just annoying.  This is probably why=20
std::isdigit<CharType>(CharType, const std::locale &) doesn't take int as a=
=20
parameter =3D)

(*) Often with the exception of -1, because that's usually the=20
implementation's chosen value of EOF.  EOF is a valid value to pass to=20
these functions, and they don't assert or read into bad memory if you call=
=20
them with EOF.
=20

> > What about the fact that many, if not most, C implementations currently=
=20
> > implement these functions as macros?  Calling these functions will be=
=20
> > annoying like it is with numeric_limits: combined with the above, you'l=
l=20
> > have to call them like this:=20
>
> That is an issue. We'd have to find an identifier that doesn't collide.=
=20
>

I just looked and this may actually not be a problem.  I looked at Linux=20
GCC and Visual Studio 2010 and 2013, and the macro versions are #ifndef=20
__cplusplus.  This makes sense, with the std::isdigit versions taking two=
=20
arguments existing.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">On Friday, September 26, 2014 11:50:10 PM UTC-7, Thiago Ma=
cieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Friday 26 Sept=
ember 2014 20:52:57 Myriachan wrote:
<br>&gt; How should wchar_t, char16_t and char32_t be handled? &nbsp;int is=
 not
<br>
<br>I'm not sure they have to. But we can add the char16_t and char32_t ove=
rloads=20
<br>because ASCII is a strict subset of UTF-16 and UTF-32, so the code is e=
xactly=20
<br>the same.
<br>
<br></blockquote><div><br>I meant that, for example, on systems with a 16-b=
it "int", attempting to pass a char32_t to std::ascii::isdigit(int) would b=
e bad.&nbsp; But yes, with overloads for them, this problem is avoided.<br>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; guaranteed to b=
e large enough to hold them. &nbsp;One way is to have isascii()
<br>&gt; be a template function that actually has meaning, returning whethe=
r its
<br>&gt; parameter is within +00 to +7F (or +7E, if you don't count the +7F
<br>&gt; backspace).
<br>
<br>I don't see how char16_t or char32_t wouldn't be wide enough to contain=
 ASCII=20
<br>if, by definition, they contain UTF-16 and UTF-32 codepoints that are a=
=20
<br>superset of ASCII.
<br>
<br></blockquote><div><br>I meant that "int" can't necessarily hold char16_=
t and char32_t.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>I don't think this needs to be a template either, but I would think that=
=20
<br>char16_t and char32_t make sense.
<br>
<br>Let's just drop wchar_t.
<br>
<br></blockquote><div><br>Even when the rest of STL supports it, like std::=
iswdigit?<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; =
How should negative integers be handled? &nbsp;It has always been very anno=
ying
<br>&gt; that calling C's isdigit, etc. requires static_cast&lt;unsigned ch=
ar&gt;(c) all
<br>&gt; the time, otherwise you assert in debug builds when your input is =
UTF-8,
<br>&gt; or, worse, cause undefined behavior--reading a table in la-la land=
--in
<br>&gt; release builds.
<br>
<br>I'm not sure how this is even a question. Negative numbers aren't ASCII=
,=20
<br>therefore they fail any trait test.
<br>
<br></blockquote><div><br>This question is actually quite relevant.&nbsp; T=
his has been a source of crash bugs with the C library functions for decade=
s.&nbsp; On an implementation where "char" is signed, which is most, the fo=
llowing is undefined behavior:<br><br><div class=3D"prettyprint" style=3D"b=
ackground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bord=
er-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"=
prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">char</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">string</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> u8</span><span style=3D"color: =
#080;" class=3D"styled-by-prettify">"=E7=8C=AB"</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">if</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(!</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i=
sdigit</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(*</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">string</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">))</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">false</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></div></code></div><br>This is =
because isdigit takes a parameter of type int, not char.&nbsp; The UTF-8 en=
coding of the string ends up with negative chars, which get sign-extended t=
o negative ints.&nbsp; Passing negative ints (*) to isdigit, etc. results i=
n undefined behavior.&nbsp; The proper way to call the isdigit family of fu=
nctions is as follows:<br><br><div class=3D"prettyprint" style=3D"backgroun=
d-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style=
: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypr=
int"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">char</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">string</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> u8</span><span style=3D"color: #080;" c=
lass=3D"styled-by-prettify">"=E7=8C=AB"</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">if</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(!<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">isdigit</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">static_cast</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">unsigned</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">char</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&gt;(*</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">string</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)))</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">false</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span></div></code></div><br>And that's just annoying.&nbsp; This is pro=
bably why std::isdigit&lt;CharType&gt;(CharType, const std::locale &amp;) d=
oesn't take int as a parameter =3D)<br><br>(*) Often with the exception of =
-1, because that's usually the implementation's chosen value of EOF.&nbsp; =
EOF is a valid value to pass to these functions, and they don't assert or r=
ead into bad memory if you call them with EOF.<br>&nbsp;</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;">&gt; What about the fact that many, if not =
most, C implementations currently
<br>&gt; implement these functions as macros? &nbsp;Calling these functions=
 will be
<br>&gt; annoying like it is with numeric_limits: combined with the above, =
you'll
<br>&gt; have to call them like this:
<br>
<br>That is an issue. We'd have to find an identifier that doesn't collide.
<br>
</blockquote><br>I just looked and this may actually not be a problem.&nbsp=
; I looked at Linux GCC and Visual Studio 2010 and 2013, and the macro vers=
ions are #ifndef __cplusplus.&nbsp; This makes sense, with the std::isdigit=
 versions taking two arguments existing.<br></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_964_1310287530.1411802731118--

.

On 09/27/2014 05:52 AM, Myriachan wrote:

> What about the fact that many, if not most, C implementations currently
> implement these functions as macros?  Calling these functions will be
> annoying like it is with numeric_limits: combined with the above, you'll
> have to call them like this:

If this is still a problem, then it would also apply to the character
classification functions in std::locale.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 09/26/2014 08:53 PM, Matthew Fioravante wrote:
> A final version of the proposal is here:
>
> https://github.com/fmatthew5876/stdcxx-ascii
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-ascii&sa=D&sntz=1&usg=AFQjCNGPEl1MJgYu6lvpkqLc3VrVMtTsZw>
>
> Does anyone have any feedback or suggestions? Is the lack of response an
> indication that this is not a good idea?

I would like to suggest that the comparison is done in a traits class
so we can add other "constexpr-essional" character sets later on; an
obvious example is XML characters.

The following is just to give you an idea. Notice that I use an
underscore in is_space() to distinguish it from the locale-based
counterparts.

// Generic part
template <typename Traits>
struct ctype_traits;

template <typename CharT, typename Traits>
constexpr bool is_space(CharT c)
{
   return ctype_traits<Traits>::is_space(c);
}

// ASCII part
struct ctype_ascii_tag {};

template <>
struct ctype_traits<ctype_ascii_tag>
{
   template <typename CharT>
   static constexpr bool is_space(CharT c)
   {
     return (c == 9 || c == 32);
   }
};

namespace ascii
{
// Convenience functions
template <typename CharT>
constexpr bool is_space(CharT c)
{
   return std::is_space<ctype_ascii_tag>(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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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



On Saturday, September 27, 2014 3:25:31 AM UTC-4, Myriachan wrote:
>
> On Friday, September 26, 2014 11:50:10 PM UTC-7, Thiago Macieira wrote:
>>
>> On Friday 26 September 2014 20:52:57 Myriachan wrote:=20
>> > How should wchar_t, char16_t and char32_t be handled?  int is not=20
>>
>> I'm not sure they have to. But we can add the char16_t and char32_t=20
>> overloads=20
>> because ASCII is a strict subset of UTF-16 and UTF-32, so the code is=20
>> exactly=20
>> the same.=20
>>
>>
> I meant that, for example, on systems with a 16-bit "int", attempting to=
=20
> pass a char32_t to std::ascii::isdigit(int) would be bad.  But yes, with=
=20
> overloads for them, this problem is avoided.
>

I originally went with int to be compatible with C getchar() and EOF. But I=
=20
see your point.

Maybe we should have overloads for char, wchar_t, char16_t, char32_t and=20
int (int for C compatibility when all of the underlying char types are=20
unsigned and EOF is -1).

> =20
>
>> > How should negative integers be handled?  It has always been very=20
>> annoying=20
>> > that calling C's isdigit, etc. requires static_cast<unsigned char>(c)=
=20
>> all=20
>> > the time, otherwise you assert in debug builds when your input is=20
>> UTF-8,=20
>> > or, worse, cause undefined behavior--reading a table in la-la land--in=
=20
>> > release builds.=20
>>
>> I'm not sure how this is even a question. Negative numbers aren't ASCII,=
=20
>> therefore they fail any trait test.=20
>>
>>
> This question is actually quite relevant.  This has been a source of cras=
h=20
> bugs with the C library functions for decades.  On an implementation wher=
e=20
> "char" is signed, which is most, the following is undefined behavior:
>
> const char *string =3D u8"=E7=8C=AB";
> if (!isdigit(*string))
>     return false;
>
>
>
The original cctype functions have this funky rule about how the input has=
=20
to either be in range of an unsigned char or be EOF otherwise the behavior=
=20
is undefined. I'm guessing this restriction was put in place so that the=20
cctype functions could be efficiently implemented using table lookup=20
without a bounds check.

As you've identified, this makes the interface rather painful to use so=20
I've opted to lift this restriction.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br><br>On Saturday, September 27, 2014 3:25:31 AM UTC-4, =
Myriachan 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"lt=
r">On Friday, September 26, 2014 11:50:10 PM UTC-7, Thiago Macieira wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex">On Friday 26 September 2014 20:52:57=
 Myriachan wrote:
<br>&gt; How should wchar_t, char16_t and char32_t be handled? &nbsp;int is=
 not
<br>
<br>I'm not sure they have to. But we can add the char16_t and char32_t ove=
rloads=20
<br>because ASCII is a strict subset of UTF-16 and UTF-32, so the code is e=
xactly=20
<br>the same.
<br>
<br></blockquote><div><br>I meant that, for example, on systems with a 16-b=
it "int", attempting to pass a char32_t to std::ascii::isdigit(int) would b=
e bad.&nbsp; But yes, with overloads for them, this problem is avoided.<br>=
</div></div></blockquote><div><br></div><div>I originally went with int to =
be compatible with C getchar() and EOF. But I see your point.</div><div><br=
></div><div>Maybe we should have overloads for char, wchar_t, char16_t, cha=
r32_t and int (int for C compatibility when all of the underlying char type=
s are unsigned and EOF is -1).</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div>&nbsp;</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex">&gt; How should negative integers be handled? &nbsp;It has always been=
 very annoying
<br>&gt; that calling C's isdigit, etc. requires static_cast&lt;unsigned ch=
ar&gt;(c) all
<br>&gt; the time, otherwise you assert in debug builds when your input is =
UTF-8,
<br>&gt; or, worse, cause undefined behavior--reading a table in la-la land=
--in
<br>&gt; release builds.
<br>
<br>I'm not sure how this is even a question. Negative numbers aren't ASCII=
,=20
<br>therefore they fail any trait test.
<br>
<br></blockquote><div><br>This question is actually quite relevant.&nbsp; T=
his has been a source of crash bugs with the C library functions for decade=
s.&nbsp; On an implementation where "char" is signed, which is most, the fo=
llowing is undefined behavior:<br><br><div style=3D"background-color:rgb(25=
0,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1p=
x;word-wrap:break-word"><code><div><span style=3D"color:#008">const</span><=
span style=3D"color:#000"> </span><span style=3D"color:#008">char</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">*</span><span st=
yle=3D"color:#008">string</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">=3D</span><span style=3D"color:#000"> u8</span><span sty=
le=3D"color:#080">"=E7=8C=AB"</span><span style=3D"color:#660">;</span><spa=
n style=3D"color:#000"><br></span><span style=3D"color:#008">if</span><span=
 style=3D"color:#000"> </span><span style=3D"color:#660">(!</span><span sty=
le=3D"color:#000">isdigit</span><span style=3D"color:#660">(*</span><span s=
tyle=3D"color:#008">string</span><span style=3D"color:#660">))</span><span =
style=3D"color:#000"><br>&nbsp; &nbsp; </span><span style=3D"color:#008">re=
turn</span><span style=3D"color:#000"> </span><span style=3D"color:#008">fa=
lse</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br=
></span></div></code></div><br><br></div></div></blockquote><div><br>The or=
iginal cctype functions have this funky rule about how the input has to eit=
her be in range of an unsigned char or be EOF otherwise the behavior is und=
efined. I'm guessing this restriction was put in place so that the cctype f=
unctions could be efficiently implemented using table lookup without a boun=
ds check.</div><div><br></div><div>As you've identified, this makes the int=
erface rather painful to use so I've opted to lift this restriction.</div><=
/div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_179_1826854380.1411827480878--

.

------=_Part_1511_1407240783.1411827722753
Content-Type: text/plain; charset=UTF-8



On Saturday, September 27, 2014 6:55:56 AM UTC-4, Bjorn Reese wrote:
>
>
> I would like to suggest that the comparison is done in a traits class
> so we can add other "constexpr-essional" character sets later on; an
> obvious example is XML characters.
>
>
I was originally thinking along these lines as well but wasn't sure what
the best interface is for such a thing. Even if such a generic mechanism is
not put into this proposal, it could be added later and the ascii library
could be re-implemented on top of it.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Saturday, September 27, 2014 6:55:56 AM UTC-4, =
Bjorn Reese wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>I would =
like to suggest that the comparison is done in a traits class
<br>so we can add other "constexpr-essional" character sets later on; an
<br>obvious example is XML characters.
<br><br></blockquote><div><br></div><div>I was originally thinking along th=
ese lines as well but wasn't sure what the best interface is for such a thi=
ng. Even if such a generic mechanism is not put into this proposal, it coul=
d be added later and the ascii library could be re-implemented on top of it=
..</div></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1511_1407240783.1411827722753--

.

On Saturday 27 September 2014 00:25:30 Myriachan wrote:
> I meant that, for example, on systems with a 16-bit "int", attempting to
> pass a char32_t to std::ascii::isdigit(int) would be bad.  But yes, with
> overloads for them, this problem is avoided.

> > I don't see how char16_t or char32_t wouldn't be wide enough to contain
> > ASCII
> > if, by definition, they contain UTF-16 and UTF-32 codepoints that are a
> > superset of ASCII.
>
> I meant that "int" can't necessarily hold char16_t and char32_t.

I don't see how "int" got into the discussion.

std::ascii::isxxx should take char, char16_t and char32_t. It stands to reason
that you already know that a given character is ASCII before using the
function. A wchar_t overload can be present only if the implementation knows
at compile time that wchar_t is always a superset of ASCII.

The use of int for ctype.h is an extreme legacy from C's obscure past.

> > I don't think this needs to be a template either, but I would think that
> > char16_t and char32_t make sense.
> >
> > Let's just drop wchar_t.
>
> Even when the rest of STL supports it, like std::iswdigit?

Yes. Let's just drop it because of its C legacy that says its encoding can be
anything. Let's stick to ASCII, UTF-16 and UTF-32.

> > I'm not sure how this is even a question. Negative numbers aren't ASCII,
> > therefore they fail any trait test.
>
> This question is actually quite relevant.
[snip the rest]

Looks like the question is relevant because you were thinking of these
functions taking int as parameters, not char.

If they take char, then the point is moot.

> And that's just annoying.  This is probably why
> std::isdigit<CharType>(CharType, const std::locale &) doesn't take int as a
> parameter =)

q.e.d :-)

> > > What about the fact that many, if not most, C implementations currently
> > > implement these functions as macros?  Calling these functions will be
> > > annoying like it is with numeric_limits: combined with the above, you'll
> >
> > > have to call them like this:
> > That is an issue. We'd have to find an identifier that doesn't collide.
>
> I just looked and this may actually not be a problem.  I looked at Linux
> GCC and Visual Studio 2010 and 2013, and the macro versions are #ifndef
> __cplusplus.  This makes sense, with the std::isdigit versions taking two
> arguments existing.

Better.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Saturday 27 September 2014 07:22:02 Matthew Fioravante wrote:
> On Saturday, September 27, 2014 6:55:56 AM UTC-4, Bjorn Reese wrote:
> > I would like to suggest that the comparison is done in a traits class
> > so we can add other "constexpr-essional" character sets later on; an
> > obvious example is XML characters.
>
> I was originally thinking along these lines as well but wasn't sure what
> the best interface is for such a thing. Even if such a generic mechanism is
> not put into this proposal, it could be added later and the ascii library
> could be re-implemented on top of it.

Note that we will never have a full Unicode tag for this, so long as the
functions are constexpr. For full Unicode, you'll need to drop the constexpr.

So if you want to keep the constexpr, why bother with the tag?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 27/09/2014 10:35 p.m., Thiago Macieira wrote:
>>> I don't think this needs to be a template either, but I would think tha=
t
>>> > >char16_t and char32_t make sense.
>>> > >
>>> > >Let's just drop wchar_t.
>> >
>> >Even when the rest of STL supports it, like std::iswdigit?
> Yes. Let's just drop it because of its C legacy that says its encoding ca=
n be
> anything. Let's stick to ASCII, UTF-16 and UTF-32.

I don't think I understand the rationale. The encoding of all of char,=20
char16_t, char32_t and wchar_t can be anything.

Regards,
--=20
Agust=EDn K-ballo Berg=E9.-
http://talesofcpp.fusionfenix.com

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Saturday 27 September 2014 22:42:09 Agust=EDn K-ballo Berg=E9 wrote:
> On 27/09/2014 10:35 p.m., Thiago Macieira wrote:
> >>> I don't think this needs to be a template either, but I would think t=
hat
> >>>=20
> >>> > >char16_t and char32_t make sense.
> >>> > >
> >>> > >Let's just drop wchar_t.
> >> >
> >> >Even when the rest of STL supports it, like std::iswdigit?
> >=20
> > Yes. Let's just drop it because of its C legacy that says its encoding =
can
> > be anything. Let's stick to ASCII, UTF-16 and UTF-32.
>=20
> I don't think I understand the rationale. The encoding of all of char,
> char16_t, char32_t and wchar_t can be anything.

The encoding of char16_t and char32_t are always UTF-16 and UTF-32,=20
respectively.

The encoding of char in a function with "ascii" in the name is ASCII.

I'm saying that now that we have char16_t and char32_t with a fixed encodin=
g,=20
we should stop adding wchar_t support, since that type can change sizes and=
=20
whose encoding is not fixed.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 27/09/2014 10:57 p.m., Thiago Macieira wrote:
> On Saturday 27 September 2014 22:42:09 Agust=EDn K-ballo Berg=E9 wrote:
>> On 27/09/2014 10:35 p.m., Thiago Macieira wrote:
>>>>> I don't think this needs to be a template either, but I would think t=
hat
>>>>>
>>>>>>> char16_t and char32_t make sense.
>>>>>>>
>>>>>>> Let's just drop wchar_t.
>>>>>
>>>>> Even when the rest of STL supports it, like std::iswdigit?
>>>
>>> Yes. Let's just drop it because of its C legacy that says its encoding =
can
>>> be anything. Let's stick to ASCII, UTF-16 and UTF-32.
>>
>> I don't think I understand the rationale. The encoding of all of char,
>> char16_t, char32_t and wchar_t can be anything.
>
> The encoding of char16_t and char32_t are always UTF-16 and UTF-32,
> respectively.

Character types have no associated encoding, you might be confusing them=20
with character literals.

> The encoding of char in a function with "ascii" in the name is ASCII.

Fair enough.

> I'm saying that now that we have char16_t and char32_t with a fixed encod=
ing,
> we should stop adding wchar_t support, since that type can change sizes a=
nd
> whose encoding is not fixed.

The size of char16_t and char32_t is not fixed either.

If the implementation gives me wide character literals then it's the job=20
of the implementation to provide me enough support for it. Maybe the=20
implementation would be wise to define wide characters to be equivalent=20
to one of the universal characters. If you were to suggest that wchar_t,=20
wide character literals, basic and execution wide character sets, and so=20
on be deprecated, then that'd be a different story.

Regards,
--=20
Agust=EDn K-ballo Berg=E9.-
http://talesofcpp.fusionfenix.com

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Saturday 27 September 2014 23:08:23 Agust=EDn K-ballo Berg=E9 wrote:
> >> I don't think I understand the rationale. The encoding of all of char,
> >> char16_t, char32_t and wchar_t can be anything.
> >=20
> > The encoding of char16_t and char32_t are always UTF-16 and UTF-32,
> > respectively.
>=20
> Character types have no associated encoding, you might be confusing them
> with character literals.

No, I'm just thinking of reasonable people using the character types for th=
e=20
purposes which they were intended.

I know I can store ~0 in a char32_t and that it's not a valid UTF-32=20
codepoint. I would expect totally undefined behaviour when passing char32_t=
(~0)=20
to a function that clearly expects UTF-32.

> > I'm saying that now that we have char16_t and char32_t with a fixed
> > encoding, we should stop adding wchar_t support, since that type can
> > change sizes and whose encoding is not fixed.
>=20
> The size of char16_t and char32_t is not fixed either.

No, but they are defined to be uint_least16_t and uint_least32_t, so that t=
hey=20
can store at least 16- and 32-bit values. That's not so for wchar_t -- for =
all=20
the standard says, it could be as wide as char.

> If the implementation gives me wide character literals then it's the job
> of the implementation to provide me enough support for it. Maybe the
> implementation would be wise to define wide characters to be equivalent
> to one of the universal characters. If you were to suggest that wchar_t,
> wide character literals, basic and execution wide character sets, and so
> on be deprecated, then that'd be a different story.

There's nothing stopping us from deprecating wchar_t in the standard librar=
y=20
or at least shunning it.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_4163_1841650105.1412051118884
Content-Type: text/plain; charset=UTF-8

On Saturday, September 27, 2014 6:35:15 PM UTC-7, Thiago Macieira wrote:
>
> On Saturday 27 September 2014 00:25:30 Myriachan wrote:
> > I meant that "int" can't necessarily hold char16_t and char32_t.
>
> I don't see how "int" got into the discussion.
>
> std::ascii::isxxx should take char, char16_t and char32_t. It stands to
> reason
> that you already know that a given character is ASCII before using the
> function. A wchar_t overload can be present only if the implementation
> knows
> at compile time that wchar_t is always a superset of ASCII.
>
> The use of int for ctype.h is an extreme legacy from C's obscure past.
>
>
His draft used "int"; that's why I mentioned it and pointed out why it's
problematic.
https://github.com/fmatthew5876/stdcxx-ascii/blob/master/proposal/draft.html

> > I don't think this needs to be a template either, but I would think
> that
> > > char16_t and char32_t make sense.
> > >
> > > Let's just drop wchar_t.
> >
> > Even when the rest of STL supports it, like std::iswdigit?
>
> Yes. Let's just drop it because of its C legacy that says its encoding can
> be
> anything. Let's stick to ASCII, UTF-16 and UTF-32.
>
>
On an implementation, the encoding of "char" can be EDCBIC while the
encoding of "wchar_t" can be UTF-32; why would "char" be the one to get
special treatment in that case, when it's wchar_t that would be the
superset of ASCII?  I am not strongly opposed to not having wchar_t; it's
just an irritation is all, since it adds static_casts to char32_t or
char16_t everywhere.  (Most systems with wchar_t define it as UTF-32 or
UTF-16 anyway.)

It would mainly affect Windows programmers, where wchar_t is deeply
ingrained into the environment.  Windows programming suffers a bit from
being the first major OS to jump onto the Unicode bandwagon - Windows NT
came out only 6 months after UTF-8 was released, being in development long
before that of course, and before Unicode realized that 64.0K wasn't enough
for everyone.


> > > I'm not sure how this is even a question. Negative numbers aren't
> ASCII,
> > > therefore they fail any trait test.
> >
> > This question is actually quite relevant.
> [snip the rest]
>
> Looks like the question is relevant because you were thinking of these
> functions taking int as parameters, not char.
>
> If they take char, then the point is moot.
>
>
Mhmm.


> > I just looked and this may actually not be a problem.  I looked at Linux
> > GCC and Visual Studio 2010 and 2013, and the macro versions are #ifndef
> > __cplusplus.  This makes sense, with the std::isdigit versions taking
> two
> > arguments existing.
>
> Better.
>
>
^^^ Yes, sorry about my initial bad assessment about them being macros.
C++ has inline functions, yay.

Melissa

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Saturday, September 27, 2014 6:35:15 PM UTC-7, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Saturday 27 S=
eptember 2014 00:25:30 Myriachan wrote:
<br>&gt; I meant that "int" can't necessarily hold char16_t and char32_t.
<br>
<br>I don't see how "int" got into the discussion.
<br>
<br>std::ascii::isxxx should take char, char16_t and char32_t. It stands to=
 reason=20
<br>that you already know that a given character is ASCII before using the=
=20
<br>function. A wchar_t overload can be present only if the implementation =
knows=20
<br>at compile time that wchar_t is always a superset of ASCII.
<br>
<br>The use of int for ctype.h is an extreme legacy from C's obscure past.
<br>
<br></blockquote><div><br>His draft used "int"; that's why I mentioned it a=
nd pointed out why it's problematic.<br><a href=3D"https://github.com/fmatt=
hew5876/stdcxx-ascii/blob/master/proposal/draft.html">https://github.com/fm=
atthew5876/stdcxx-ascii/blob/master/proposal/draft.html</a><br><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">&gt; &gt; I don't think this nee=
ds to be a template either, but I would think that
<br>&gt; &gt; char16_t and char32_t make sense.
<br>&gt; &gt;=20
<br>&gt; &gt; Let's just drop wchar_t.
<br>&gt;=20
<br>&gt; Even when the rest of STL supports it, like std::iswdigit?
<br>
<br>Yes. Let's just drop it because of its C legacy that says its encoding =
can be=20
<br>anything. Let's stick to ASCII, UTF-16 and UTF-32.
<br>
<br></blockquote><div><br>On an implementation, the encoding of "char" can =
be EDCBIC while the encoding of "wchar_t" can be UTF-32; why would "char" b=
e the one to get special treatment in that case, when it's wchar_t that wou=
ld be the superset of ASCII?&nbsp; I am not strongly opposed to not having =
wchar_t; it's just an irritation is all, since it adds static_casts to char=
32_t or char16_t everywhere.&nbsp; (Most systems with wchar_t define it as =
UTF-32 or UTF-16 anyway.)<br><br>It would mainly affect Windows programmers=
, where wchar_t is deeply ingrained into the environment.&nbsp; Windows pro=
gramming suffers a bit from being the first major OS to jump onto the Unico=
de bandwagon - Windows NT came out only 6 months after UTF-8 was released, =
being in development long before that of course, and before Unicode realize=
d that 64.0K wasn't enough for everyone.<br>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">&gt; &gt; I'm not sure how this is even a quest=
ion. Negative numbers aren't ASCII,
<br>&gt; &gt; therefore they fail any trait test.
<br>&gt;=20
<br>&gt; This question is actually quite relevant. &nbsp;
<br>[snip the rest]
<br>
<br>Looks like the question is relevant because you were thinking of these=
=20
<br>functions taking int as parameters, not char.
<br>
<br>If they take char, then the point is moot.
<br>
<br></blockquote><div><br>Mhmm.<br>&nbsp;<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">&gt; I just looked and this may actually not be a prob=
lem. &nbsp;I looked at Linux
<br>&gt; GCC and Visual Studio 2010 and 2013, and the macro versions are #i=
fndef
<br>&gt; __cplusplus. &nbsp;This makes sense, with the std::isdigit version=
s taking two
<br>&gt; arguments existing.
<br>
<br>Better.
<br>
<br></blockquote><div><br>^^^ Yes, sorry about my initial bad assessment ab=
out them being macros.&nbsp; C++ has inline functions, yay.<br><br>Melissa<=
br></div></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4163_1841650105.1412051118884--

.

------=_Part_5087_1792116971.1412123685062
Content-Type: text/plain; charset=UTF-8



On Tuesday, September 30, 2014 12:25:18 AM UTC-4, Myriachan wrote:
>
> On Saturday, September 27, 2014 6:35:15 PM UTC-7, Thiago Macieira wrote:
>>
>> On Saturday 27 September 2014 00:25:30 Myriachan wrote:
>> > I meant that "int" can't necessarily hold char16_t and char32_t.
>>
>> I don't see how "int" got into the discussion.
>>
>> std::ascii::isxxx should take char, char16_t and char32_t. It stands to
>> reason
>> that you already know that a given character is ASCII before using the
>> function. A wchar_t overload can be present only if the implementation
>> knows
>> at compile time that wchar_t is always a superset of ASCII.
>>
>> The use of int for ctype.h is an extreme legacy from C's obscure past.
>>
>>
> His draft used "int"; that's why I mentioned it and pointed out why it's
> problematic.
>
> https://github.com/fmatthew5876/stdcxx-ascii/blob/master/proposal/draft.html
>
>
I originally proposed int so that the functions would be compatible with C
getchar() and EOF. Looking at it again, perhaps that is not so necessary. I
never use either of those and even if I did I would be doing an EOF check
before passing it on to an ascii function. Setting the type to char also
resolves ambiguities and questions about values that are valid for int but
invalid for char (such as negative values).

I've changed the proposal to accept char, char16_t, char32_t. A new version
of the paper is available:

https://github.com/fmatthew5876/stdcxx-ascii

I'm still on the fence about wchar_t. While it looks like the direction is
for wchar_t to eventually go away there are a lot of people using it.
Windows developers being the prime example.

Is anyone here a windows developer who would find these functions at all
useful with wchar_t? Even if wchar_t is planned to be deprecated, we can
still add overloads now and deprecate them later if and when wchar_t gets
deprecated.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Tuesday, September 30, 2014 12:25:18 AM UTC-4, =
Myriachan 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"lt=
r">On Saturday, September 27, 2014 6:35:15 PM UTC-7, Thiago Macieira wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">On Saturday 27 September 2014 00:25=
:30 Myriachan wrote:
<br>&gt; I meant that "int" can't necessarily hold char16_t and char32_t.
<br>
<br>I don't see how "int" got into the discussion.
<br>
<br>std::ascii::isxxx should take char, char16_t and char32_t. It stands to=
 reason=20
<br>that you already know that a given character is ASCII before using the=
=20
<br>function. A wchar_t overload can be present only if the implementation =
knows=20
<br>at compile time that wchar_t is always a superset of ASCII.
<br>
<br>The use of int for ctype.h is an extreme legacy from C's obscure past.
<br>
<br></blockquote><div><br>His draft used "int"; that's why I mentioned it a=
nd pointed out why it's problematic.<br><a href=3D"https://github.com/fmatt=
hew5876/stdcxx-ascii/blob/master/proposal/draft.html" target=3D"_blank" onm=
ousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithu=
b.com%2Ffmatthew5876%2Fstdcxx-ascii%2Fblob%2Fmaster%2Fproposal%2Fdraft.html=
\46sa\75D\46sntz\0751\46usg\75AFQjCNFDNdPkvqf4tEJaDiBTgspjVZQKOg';return tr=
ue;" onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fg=
ithub.com%2Ffmatthew5876%2Fstdcxx-ascii%2Fblob%2Fmaster%2Fproposal%2Fdraft.=
html\46sa\75D\46sntz\0751\46usg\75AFQjCNFDNdPkvqf4tEJaDiBTgspjVZQKOg';retur=
n true;">https://github.com/<wbr>fmatthew5876/stdcxx-ascii/<wbr>blob/master=
/proposal/draft.<wbr>html</a><br><br></div></div></blockquote><div><br></di=
v><div>I originally proposed int so that the functions would be compatible =
with C getchar() and EOF. Looking at it again, perhaps that is not so neces=
sary. I never use either of those and even if I did I would be doing an EOF=
 check before passing it on to an ascii function. Setting the type to char =
also resolves ambiguities and questions about values that are valid for int=
 but invalid for char (such as negative values).</div><div><br></div><div>I=
've changed the proposal to accept char, char16_t, char32_t. A new version =
of the paper is available:</div><div><br></div><div>https://github.com/fmat=
thew5876/stdcxx-ascii</div><div><br>I'm still on the fence about wchar_t. W=
hile it looks like the direction is for wchar_t to eventually go away there=
 are a lot of people using it. Windows developers being the prime example.<=
/div><div><br></div><div>Is anyone here a windows developer who would find =
these functions at all useful with wchar_t? Even if wchar_t is planned to b=
e deprecated, we can still add overloads now and deprecate them later if an=
d when wchar_t gets deprecated.</div><div><br></div></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5087_1792116971.1412123685062--

.

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--o8UcP0WexXTiaJN0OKR7V2b485TSBgoD0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable

Am 01.10.2014 um 02:34 schrieb Matthew Fioravante:
>=20
> I've changed the proposal to accept char, char16_t, char32_t. A new
> version of the paper is available:
>=20
> Is anyone here a windows developer who would find these functions at al=
l
> useful with wchar_t? Even if wchar_t is planned to be deprecated, we ca=
n
> still add overloads now and deprecate them later if and when wchar_t
> gets deprecated.

I certainly do. As long as wchar_t isn't deprecated it's a first-class
member of the char party, imho.

Ciao
   Dani



--o8UcP0WexXTiaJN0OKR7V2b485TSBgoD0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iF4EAREIAAYFAlQsF/8ACgkQugNWoSxGOMVW2wEAzoreAqUmEzpeAhONnmErI+N6
HItgppj50BWIhy1O4Y8A/jU8sIlwESaX4LdL3SATnzbiCP9Lu/dfPMHA+//Aeeko
=WJut
-----END PGP SIGNATURE-----

--o8UcP0WexXTiaJN0OKR7V2b485TSBgoD0--

.

On Wednesday 01 October 2014 17:04:16 Daniela Engert wrote:
> Am 01.10.2014 um 02:34 schrieb Matthew Fioravante:
> > I've changed the proposal to accept char, char16_t, char32_t. A new
> > version of the paper is available:
> >
> > Is anyone here a windows developer who would find these functions at all
> > useful with wchar_t? Even if wchar_t is planned to be deprecated, we can
> > still add overloads now and deprecate them later if and when wchar_t
> > gets deprecated.
>
> I certainly do. As long as wchar_t isn't deprecated it's a first-class
> member of the char party, imho.

I would say the implementation should provide those if it can be sure that the
wide execution charset at runtime is a superset of ASCII. That's the case on
Windows (wchar_t == char16_t).

If it can't be sure or if the wide char encoding is changeable at runtime,
then those functions should be omitted.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_679_414057758.1412187640494
Content-Type: text/plain; charset=UTF-8



On Wednesday, October 1, 2014 2:04:39 PM UTC-4, Thiago Macieira wrote:
>
>
> I would say the implementation should provide those if it can be sure that
> the
> wide execution charset at runtime is a superset of ASCII. That's the case
> on
> Windows (wchar_t == char16_t).
>
> If it can't be sure or if the wide char encoding is changeable at runtime,
> then those functions should be omitted.
>
>
Why omit? If you call ascii::isspace() on a wchar_t, you are saying "I
don't care what the system encoding is, I am guaranteeing that the
character I am giving you is ascii compatible".

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Wednesday, October 1, 2014 2:04:39 PM UTC-4, Th=
iago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>I woul=
d say the implementation should provide those if it can be sure that the=20
<br>wide execution charset at runtime is a superset of ASCII. That's the ca=
se on=20
<br>Windows (wchar_t =3D=3D char16_t).
<br>
<br>If it can't be sure or if the wide char encoding is changeable at runti=
me,=20
<br>then those functions should be omitted.
<br>
<br></blockquote><div><br>Why omit? If you call ascii::isspace() on a wchar=
_t, you are saying "I don't care what the system encoding is, I am guarante=
eing that the character I am giving you is ascii compatible".<br></div></di=
v>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_679_414057758.1412187640494--

.

On Wednesday 01 October 2014 11:20:40 Matthew Fioravante wrote:
> On Wednesday, October 1, 2014 2:04:39 PM UTC-4, Thiago Macieira wrote:
> > I would say the implementation should provide those if it can be sure that
> > the
> > wide execution charset at runtime is a superset of ASCII. That's the case
> > on
> > Windows (wchar_t == char16_t).
> >
> > If it can't be sure or if the wide char encoding is changeable at runtime,
> > then those functions should be omitted.
>
> Why omit? If you call ascii::isspace() on a wchar_t, you are saying "I
> don't care what the system encoding is, I am guaranteeing that the
> character I am giving you is ascii compatible".

If you know that the character is ASCII, why are you calling the function?

If you know you have UTF-16 or UTF-32, why aren't you using char16_t or
char32_t? If you know your data is a superset of ASCII, you can cast it.

We could have a wchar_t function that asks "does this character from the wide
character execution charset, whichever it is, exist in ASCII". That would make
sense to me.

But once you've got that, the traits like isdigit only make sense in ASCII in
the first place. You should simply convert to ASCII and work on a char.

char16_t and char32_t only get the exemption because the code is exactly the
same.


--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_4783_1016506818.1412207235841
Content-Type: text/plain; charset=UTF-8


If I understand what you're trying to say, I think your point is that
assuming a wchar_t is ascii compatible may not make much sense at all
because all uses of wchar_t come from *platform specific sources* such as
string literals, operating system paths, etc.. In that case we would never
use wchar_t to represent wide text loaded from a *platform agnostic source*
like a file or network socket because we don't know its size. Instead we
would use char16_t and char32_t, in the same way we would use int32_t
instead of int or long for binary data. Therefore, on a system where
wchar_t is defined to be non-ascii compatible these functions would useless
if not even dangerous to use.


*The ascii::isX() functions are designed for text which comes from platform
agnostic sources such as data files where the encoding is known a priori.*

If you have the platform specific knowledge to know your wchar_t is ascii
compatible, then you also have the platform specific knowledge to know
whether it should be a char16_t or char32_t. Someone who for example wants
to parse a windows path using ascii methods could convert the wchar_t's to
char16_t.

Am I understanding your argument correctly?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><div>If I understand what you're trying to say, I thin=
k your point is that assuming a wchar_t is ascii compatible may not make mu=
ch sense at all because all uses of wchar_t come from <b>platform specific =
sources</b> such as string literals, operating system paths, etc..  In that=
 case we would never
 use wchar_t to represent wide text loaded from a <b>platform agnostic=20
source</b> like a file or network socket because we don't know its size. In=
stead we would use char16_t and=20
char32_t, in the same way we would use int32_t instead of int or long for b=
inary data. Therefore, on a system where wchar_t is=20
defined to be non-ascii compatible these functions would useless if not eve=
n dangerous to use.<br><br><br><b>The ascii::isX() functions are designed f=
or text which comes from platform agnostic sources such as data files where=
 the encoding is known a priori.</b><br><br>If you have=20
the platform specific knowledge to know your wchar_t is ascii=20
compatible, then you also have the platform specific knowledge to know=20
whether it should be a char16_t or char32_t. Someone who for example wants =
to parse a windows path using ascii methods could convert the wchar_t's to =
char16_t.<br><br>Am I understanding your argument correctly?<br></div></div=
>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4783_1016506818.1412207235841--

.

On Wednesday 01 October 2014 16:47:15 Matthew Fioravante wrote:
> *The ascii::isX() functions are designed for text which comes from platform
> agnostic sources such as data files where the encoding is known a priori.*
>
> If you have the platform specific knowledge to know your wchar_t is ascii
> compatible, then you also have the platform specific knowledge to know
> whether it should be a char16_t or char32_t. Someone who for example wants
> to parse a windows path using ascii methods could convert the wchar_t's to
> char16_t.
>
> Am I understanding your argument correctly?

Yes.

With the exception that on Windows, wchar_t is always UTF-16, so it is
actually safe. The example is misleading.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_2414_1738190716.1412239432514
Content-Type: text/plain; charset=UTF-8

On Wednesday, October 1, 2014 4:47:15 PM UTC-7, Matthew Fioravante wrote:
>
> *The ascii::isX() functions are designed for text which comes from
> platform agnostic sources such as data files where the encoding is known a
> priori.*
>
> If you have the platform specific knowledge to know your wchar_t is ascii
> compatible, then you also have the platform specific knowledge to know
> whether it should be a char16_t or char32_t. Someone who for example wants
> to parse a windows path using ascii methods could convert the wchar_t's to
> char16_t.
>
> Am I understanding your argument correctly?
>

You could make the same argument to say that there is no reason to support
anything but char32_t.  Everything above applies equally to char as it does
to wchar_t.  If you know beforehand that your char buffer comes from
platform-agnostic sources and contains ASCII text, which is the whole point
of this thread, you can pass each char converted to char32_t and get the
same result.  Every one of these functions returns false or has undefined
behavior for the ranges of characters U+00D800 through U+00DFFF inclusive
and U+100000 through U+10FFFF inclusive, so supporting char16_t serves no
purpose either; just convert all char16_t values to char32_t before calling
the char32_t versions.

The above is meant to just be *reductio ad absurdum*.  I think it's better
to just support them all, since sprinkling static_casts every time we call
these functions is just annoying.

By the way, no love for strtod/wcstod?  I'd love to avoid having to call
nonstandard functions like _strtod_l with a custom-made "C" locale object
in order to make sure that '.' is always the digit separator and not ','.
There are times for locale handling and there are times for consistency.

Melissa

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Wednesday, October 1, 2014 4:47:15 PM UTC-7, Matthew Fi=
oravante 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"ltr=
"><b>The ascii::isX() functions are designed for text which comes from plat=
form agnostic sources such as data files where the encoding is known a prio=
ri.</b><br><div><br>If you have=20
the platform specific knowledge to know your wchar_t is ascii=20
compatible, then you also have the platform specific knowledge to know=20
whether it should be a char16_t or char32_t. Someone who for example wants =
to parse a windows path using ascii methods could convert the wchar_t's to =
char16_t.<br><br>Am I understanding your argument correctly?<br></div></div=
></blockquote><div><br>You could make the same argument to say that there i=
s no reason to support anything but <span style=3D"font-family: courier new=
,monospace;">char32_t</span>.&nbsp; Everything above applies equally to <sp=
an style=3D"font-family: courier new,monospace;">char</span> as it does to =
<span style=3D"font-family: courier new,monospace;">wchar_t</span>.&nbsp; I=
f you know beforehand that your <span style=3D"font-family: courier new,mon=
ospace;">char</span> buffer comes from platform-agnostic sources and contai=
ns ASCII text, which is the whole point of this thread, you can pass each <=
span style=3D"font-family: courier new,monospace;">char</span> converted to=
 <span style=3D"font-family: courier new,monospace;">char32_t</span> and ge=
t the same result.&nbsp; Every one of these functions returns <span style=
=3D"font-family: courier new,monospace;">false</span> or has undefined beha=
vior for the ranges of characters <span style=3D"font-family: courier new,m=
onospace;">U+00D800</span> through <span style=3D"font-family: courier new,=
monospace;">U+00DFFF</span> inclusive and <span style=3D"font-family: couri=
er new,monospace;">U+100000</span> through <span style=3D"font-family: cour=
ier new,monospace;">U+10FFFF</span> inclusive, so supporting <span style=3D=
"font-family: courier new,monospace;">char16_t</span> serves no purpose eit=
her; just convert all <span style=3D"font-family: courier new,monospace;">c=
har16_t</span> values to <span style=3D"font-family: courier new,monospace;=
">char32_t</span> before calling the <span style=3D"font-family: courier ne=
w,monospace;">char32_t</span> versions.<br><br>The above is meant to just b=
e <i>reductio ad absurdum</i>.&nbsp; I think it's better to just support th=
em all, since sprinkling <span style=3D"font-family: courier new,monospace;=
">static_cast</span>s every time we call these functions is just annoying.<=
br><br>By the way, no love for <span style=3D"font-family: courier new,mono=
space;">strtod</span>/<span style=3D"font-family: courier new,monospace;">w=
cstod</span>?&nbsp; I'd love to avoid having to call nonstandard functions =
like <span style=3D"font-family: courier new,monospace;">_strtod_l</span> w=
ith a custom-made "C" locale object in order to make sure that <span style=
=3D"font-family: courier new,monospace;">'.'</span> is always the digit sep=
arator and not <span style=3D"font-family: courier new,monospace;">','</spa=
n>.&nbsp; There are times for locale handling and there are times for consi=
stency.<br><br>Melissa<br></div></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2414_1738190716.1412239432514--

.

------=_Part_4781_1378100485.1412250839548
Content-Type: text/plain; charset=UTF-8



On Thursday, October 2, 2014 4:43:52 AM UTC-4, Myriachan wrote:
>
> On Wednesday, October 1, 2014 4:47:15 PM UTC-7, Matthew Fioravante wrote:
>>
>> *The ascii::isX() functions are designed for text which comes from
>> platform agnostic sources such as data files where the encoding is known a
>> priori.*
>>
>> If you have the platform specific knowledge to know your wchar_t is ascii
>> compatible, then you also have the platform specific knowledge to know
>> whether it should be a char16_t or char32_t. Someone who for example wants
>> to parse a windows path using ascii methods could convert the wchar_t's to
>> char16_t.
>>
>> Am I understanding your argument correctly?
>>
>
> You could make the same argument to say that there is no reason to support
> anything but char32_t.  Everything above applies equally to char as it
> does to wchar_t.
>

The difference here is that char is often used for storing platform
agnostic text as if it were a char8_t, while wchar_t is never used for this
purpose.


> If you know beforehand that your char buffer comes from platform-agnostic
> sources and contains ASCII text, which is the whole point of this thread,
> you can pass each char converted to char32_t and get the same result.
> Every one of these functions returns false or has undefined behavior for
> the ranges of characters U+00D800 through U+00DFFF inclusive and U+100000
> through U+10FFFF inclusive, so supporting char16_t serves no purpose
> either; just convert all char16_t values to char32_t before calling the
> char32_t versions.
>
> The above is meant to just be *reductio ad absurdum*.  I think it's
> better to just support them all, since sprinkling static_casts every time
> we call these functions is just annoying.
>

I think I will add them and also add a paragraph explaining all of these
discussions. I don't really care as I just really want my ascii functions
for char! The committee can make the final decision on wchar_t.

>
> By the way, no love for strtod/wcstod?  I'd love to avoid having to call
> nonstandard functions like _strtod_l with a custom-made "C" locale object
> in order to make sure that '.' is always the digit separator and not ','.
> There are times for locale handling and there are times for consistency.
>

That's more about specifying a static locale and unrelated to ascii. The
only thing an ascii version would give you is the minor optimization that
the calls to isspace() would be inlined called ascii::isspace().

Still I see your point and this may be an idea for a followup proposal (or
for the new set of str to int/float functions in the other thread).

>
> Melissa
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Thursday, October 2, 2014 4:43:52 AM UTC-4, Myr=
iachan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
On Wednesday, October 1, 2014 4:47:15 PM UTC-7, Matthew Fioravante wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><b>The ascii::isX() =
functions are designed for text which comes from platform agnostic sources =
such as data files where the encoding is known a priori.</b><br><div><br>If=
 you have=20
the platform specific knowledge to know your wchar_t is ascii=20
compatible, then you also have the platform specific knowledge to know=20
whether it should be a char16_t or char32_t. Someone who for example wants =
to parse a windows path using ascii methods could convert the wchar_t's to =
char16_t.<br><br>Am I understanding your argument correctly?<br></div></div=
></blockquote><div><br>You could make the same argument to say that there i=
s no reason to support anything but <span style=3D"font-family:courier new,=
monospace">char32_t</span>.&nbsp; Everything above applies equally to <span=
 style=3D"font-family:courier new,monospace">char</span> as it does to <spa=
n style=3D"font-family:courier new,monospace">wchar_t</span>.&nbsp; </div><=
/div></blockquote><div><br></div><div>The difference here is that char is o=
ften used for storing platform agnostic text as if it were a char8_t, while=
 wchar_t is never used for this purpose.</div><div>&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>If you know beforeha=
nd that your <span style=3D"font-family:courier new,monospace">char</span> =
buffer comes from platform-agnostic sources and contains ASCII text, which =
is the whole point of this thread, you can pass each <span style=3D"font-fa=
mily:courier new,monospace">char</span> converted to <span style=3D"font-fa=
mily:courier new,monospace">char32_t</span> and get the same result.&nbsp; =
Every one of these functions returns <span style=3D"font-family:courier new=
,monospace">false</span> or has undefined behavior for the ranges of charac=
ters <span style=3D"font-family:courier new,monospace">U+00D800</span> thro=
ugh <span style=3D"font-family:courier new,monospace">U+00DFFF</span> inclu=
sive and <span style=3D"font-family:courier new,monospace">U+100000</span> =
through <span style=3D"font-family:courier new,monospace">U+10FFFF</span> i=
nclusive, so supporting <span style=3D"font-family:courier new,monospace">c=
har16_t</span> serves no purpose either; just convert all <span style=3D"fo=
nt-family:courier new,monospace">char16_t</span> values to <span style=3D"f=
ont-family:courier new,monospace">char32_t</span> before calling the <span =
style=3D"font-family:courier new,monospace">char32_t</span> versions.<br><b=
r>The above is meant to just be <i>reductio ad absurdum</i>.&nbsp; I think =
it's better to just support them all, since sprinkling <span style=3D"font-=
family:courier new,monospace">static_cast</span>s every time we call these =
functions is just annoying.<br></div></div></blockquote><div><br></div><div=
>I think I will add them and also add a paragraph explaining all of these d=
iscussions. I don't really care as I just really want my ascii functions fo=
r char! The committee can make the final decision on wchar_t.&nbsp;</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>By the=
 way, no love for <span style=3D"font-family:courier new,monospace">strtod<=
/span>/<span style=3D"font-family:courier new,monospace">wcstod</span>?&nbs=
p; I'd love to avoid having to call nonstandard functions like <span style=
=3D"font-family:courier new,monospace">_strtod_l</span> with a custom-made =
"C" locale object in order to make sure that <span style=3D"font-family:cou=
rier new,monospace">'.'</span> is always the digit separator and not <span =
style=3D"font-family:courier new,monospace">','</span>.&nbsp; There are tim=
es for locale handling and there are times for consistency.<br></div></div>=
</blockquote><div><br></div><div>That's more about specifying a static loca=
le and unrelated to ascii. The only thing an ascii version would give you i=
s the minor optimization that the calls to isspace() would be inlined calle=
d ascii::isspace().</div><div><br></div><div>Still I see your point and thi=
s may be an idea for a followup proposal (or for the new set of str to int/=
float functions in the other thread).</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div dir=3D"ltr"><div><br>Melissa<br></div></div></blockquote>=
</div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4781_1378100485.1412250839548--

.

------=_Part_3391_1600979370.1412299118180
Content-Type: text/plain; charset=UTF-8

Candidate for final draft is here:

https://github.com/fmatthew5876/stdcxx-ascii/

If there are no more further objections or suggestions. I will submit this
version.

Thank you everyone for your valuable feedback.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div>Candidate for final draft is here:</div><div><br></di=
v>https://github.com/fmatthew5876/stdcxx-ascii/<div><br></div><div>If there=
 are no more further objections or suggestions. I will submit this version.=
</div><div><br></div><div>Thank you everyone for your valuable feedback.</d=
iv></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3391_1600979370.1412299118180--

.

------=_Part_4101_913963346.1412304628711
Content-Type: text/plain; charset=UTF-8

I might be misunderstanding its function, but the isascii(int) function
might give invalid results as implemented.  It returns false for a null
character and true if any of the first 7 bits are set.  This does not match
the description of the function where it returns true if the value passed
is >= 0 and <= 0x7F.

// This is how you have it now in cctype.hh
constexpr bool isascii(int c) noexcept
{
    return c & 0x7F;
}

// This is how I imagine it should work.
constexpr bool isascii(int c) noexcept
{
    return (c >= 0 && c <= 0x7F);
}



--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">I might be misunderstanding its function, but the isascii(=
int) function might give invalid results as implemented. &nbsp;It returns f=
alse for a null character and true if any of the first 7 bits are set. &nbs=
p;This does not match the description of the function where it returns true=
 if the value passed is &gt;=3D 0 and &lt;=3D 0x7F.<div><br></div><div><pre=
 style=3D"color: rgb(0, 0, 0);"><div class=3D"prettyprint" style=3D"border:=
 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb=
(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: rgb(136, 0, 0);"><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// This is how you have it now in cctype.hh</span><=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> isascii</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> c</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> noexcept<br></span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">return</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> c </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&a=
mp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">0x7F</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br><br></span><span style=3D"color: rgb(136, =
0, 0);"><span style=3D"color: #800;" class=3D"styled-by-prettify">// This i=
s how I imagine it should work.</span></span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> isascii</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">in=
t</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> noexcept<br></span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">c </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&gt;=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">0</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&amp=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;=3D</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">0x7F</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br><br></span></div></code></div><br></pre><br></div></d=
iv>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4101_913963346.1412304628711--

.

------=_Part_7477_1184475112.1412305060464
Content-Type: text/plain; charset=UTF-8



On Thursday, October 2, 2014 10:50:28 PM UTC-4, ron novy wrote:
>
> I might be misunderstanding its function, but the isascii(int) function
> might give invalid results as implemented.  It returns false for a null
> character and true if any of the first 7 bits are set.  This does not match
> the description of the function where it returns true if the value passed
> is >= 0 and <= 0x7F.
>

That's a bug in my example header. Fixed

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Thursday, October 2, 2014 10:50:28 PM UTC-4, ro=
n novy wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
I might be misunderstanding its function, but the isascii(int) function mig=
ht give invalid results as implemented. &nbsp;It returns false for a null c=
haracter and true if any of the first 7 bits are set. &nbsp;This does not m=
atch the description of the function where it returns true if the value pas=
sed is &gt;=3D 0 and &lt;=3D 0x7F.</div></blockquote><div><br></div><div>Th=
at's a bug in my example header. Fixed</div></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_7477_1184475112.1412305060464--

.

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

On Thursday, October 2, 2014 7:57:40 PM UTC-7, Matthew Fioravante wrote:
>
> On Thursday, October 2, 2014 10:50:28 PM UTC-4, ron novy wrote:
>>
>> I might be misunderstanding its function, but the isascii(int) function=
=20
>> might give invalid results as implemented.  It returns false for a null=
=20
>> character and true if any of the first 7 bits are set.  This does not ma=
tch=20
>> the description of the function where it returns true if the value passe=
d=20
>> is >=3D 0 and <=3D 0x7F.
>>
>
> That's a bug in my example header. Fixed
>

Regarding the undefined nature of todigit with bad input characters, do you=
=20
mean that it's acceptable for these functions to crash if you give them a=
=20
bad character, or that they merely give some weird useless result instead? =
=20
The latter would be called "unspecified" instead.

Wasn't there previously a fromdigit?  Also, what you have now as todigit=20
seems more like a fromdigit than a todigit, because it just passed an=20
isdigit check...

General proposal note: "ASCII" is an acronym--American Standard Code for=20
Information Interchange--and, as such, should be written in all caps in the=
=20
proposal.  Note that I'm not saying that this applies to identifier names=
=20
like std::ascii, std::isascii, etc; those should remain lowercase.


No need to mention Microsoft Excel; "any common spreadsheet application"=20
would work, because that is true.  Any common spreadsheet can export .csv=
=20
files.  Heck, my database query tool can export select results as .tsv or=
=20
..csv.


Typo in proposal's prototypes:

constexpr bool std::ascii:isalnum(char16_t c) noexcept;
constexpr bool std::ascii:isalnum(char32_t c) noexcept;

*Return*: std::ascii::isalpha(c) || std::asci::isdigit(c)

Needs two colons before isalnum.  This one is systemic of the Character=20
Checks part.  isalnum specifically has a typo where asci should be ascii.

constexpr int todigit(char c, int m) noexcept;
constexpr int todigit(wchar_t c, int m) noexcept;
constexpr int todigit(char16_t c, int m) noexcept;
constexpr int todigit(char32_t c, int m) noexcept;

*Return*: std::ascii::todigit(c) * m

I think that you intended these to say std::ascii:: before todigit.

*Return*: (c >=3D 33 && c<=3D 126)

Space after second c.


Words that should be in monospace font:

"This proposal adds a set of //constexpr// free functions"


Phrases that need hyphens:

digit-to-int
high-performance
error-prone
ASCII-compatible
char-to-int
platform-agnostic
platform-specific
user-defined
std-proposals (because that's the name of this list)

Typos / misspellings:

Change: ~large data files which use ascii delimeters.
To: ~ASCII delimiters.

Change: ~github.
To: ~GitHub.

Change: We propose 2 additional useful functions todigit, and toxdigit.
To: ~functions: todigit and toxdigit.  (Add colon, remove comma.  Oxford=20
command is awkward with two items.)

Change: 2
To: two    (this is a generic change to make things more readable)

Change: Alternatively, all of these defintions
To: Alternatively, all these definitions   (delete "of', fix spelling of=20
"definitions")

Change: Each function has overloads for type char, wchar_t, char16_t, and=
=20
char32_t.
To: (Delete final comma.  This is stylistic, though, and definitely up to=
=20
you, of course.)

Change:=20
*[note-- All of these~*To: [*Note:* All these~     (If you want to follow=
=20
the Standard's formatting, it's non-italic [ followed by italic *Note:* and=
=20
non-italic note text.  Delete "of".)

Change:=20
*locale settings. --end-note]*To: locale settings. =E2=80=94*end note*] =20
(Similarly, this is an "em-dash" (U+002014), "end note" in italic (no=20
hyphen between "end" and "note") and a non-italic ] )

Change: *Return:*
To: *Returns:*

Change: On systems such as windows
To: On systems such as Windows

Change: where wchar_t happens to be using an ASCII-compatible encoding
To: where wchar_t happens to be using an ASCII-compatible encoding (UTF-16)

Change: presense
To: presence

Change: standard committee
To: Standard Committee

Change: Csv file parsers
To: .csv file parsers  or   CSV file parsers

Change: decide that wchar_t is a bad idea
To: decide that wchar_t support in this proposal is a bad idea

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">On Thursday, October 2, 2014 7:57:40 PM UTC-7, Matthew Fio=
ravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Thursday, October 2, 2014 10:50:28 PM UTC-4, ron novy 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"ltr">I might be misunderstanding i=
ts function, but the isascii(int) function might give invalid results as im=
plemented. &nbsp;It returns false for a null character and true if any of t=
he first 7 bits are set. &nbsp;This does not match the description of the f=
unction where it returns true if the value passed is &gt;=3D 0 and &lt;=3D =
0x7F.</div></blockquote><div><br></div><div>That's a bug in my example head=
er. Fixed</div></div></blockquote><div><br>Regarding the undefined nature o=
f <span style=3D"font-family: courier new,monospace;">todigit</span> with b=
ad input characters, do you mean that it's acceptable for these functions t=
o crash if you give them a bad character, or that they merely give some wei=
rd useless result instead?&nbsp; The latter would be called "unspecified" i=
nstead.<br><br>Wasn't there previously a <span style=3D"font-family: courie=
r new,monospace;">fromdigit</span>?&nbsp; Also, what you have now as <span =
style=3D"font-family: courier new,monospace;">todigit</span> seems more lik=
e a <span style=3D"font-family: courier new,monospace;">fromdigit</span> th=
an a <span style=3D"font-family: courier new,monospace;">todigit</span>, be=
cause it just passed an <span style=3D"font-family: courier new,monospace;"=
>isdigit</span> check...<br><br>General proposal note: "ASCII" is an acrony=
m--American Standard Code for Information Interchange--and, as such, should=
 be written in all caps in the proposal.&nbsp; Note that I'm not saying tha=
t this applies to identifier names like <span style=3D"font-family: courier=
 new,monospace;">std::ascii</span>, <span style=3D"font-family: courier new=
,monospace;">std::isascii</span>, etc; those should remain lowercase.<br><b=
r><br>No need to mention Microsoft Excel; "any common spreadsheet applicati=
on" would work, because that is true.&nbsp; Any common spreadsheet can expo=
rt .csv files.&nbsp; Heck, my database query tool can export select results=
 as .tsv or .csv.<br><br><br>Typo in proposal's prototypes:<br><br><pre><co=
de>constexpr bool std::ascii<span style=3D"color: rgb(255, 0, 0);">:</span>=
isalnum(char16_t c) noexcept;
constexpr bool std::ascii<span style=3D"color: rgb(255, 0, 0);">:</span>isa=
lnum(char32_t c) noexcept;
</code></pre>

<p><strong>Return</strong>: <code>std::ascii::isalpha(c) || std::<span styl=
e=3D"color: rgb(255, 0, 0);">asci</span>::isdigit(c)</code></p><p>Needs two=
 colons before <span style=3D"font-family: courier new,monospace;">isalnum<=
/span>.&nbsp; This one is systemic of the Character Checks part.&nbsp; <spa=
n style=3D"font-family: courier new,monospace;">isalnum</span> specifically=
 has a typo where <span style=3D"font-family: courier new,monospace;">asci<=
/span> should be <span style=3D"font-family: courier new,monospace;">ascii<=
/span>.</p><pre><code>constexpr int todigit(char c, int m) noexcept;
constexpr int todigit(wchar_t c, int m) noexcept;
constexpr int todigit(char16_t c, int m) noexcept;
constexpr int todigit(char32_t c, int m) noexcept;
</code></pre>

<p><strong>Return</strong>: <code>std::ascii::todigit(c) * m</code></p><p>I=
 think that you intended these to say <span style=3D"font-family: courier n=
ew,monospace;">std::ascii::</span> before <span style=3D"font-family: couri=
er new,monospace;">todigit</span>.<br></p><p><strong>Return</strong>: <code=
>(c &gt;=3D 33 &amp;&amp; c<span style=3D"color: rgb(255, 0, 0);">&lt;=3D</=
span> 126)</code></p><p>Space after second <span style=3D"font-family: cour=
ier new,monospace;">c</span>.</p><p><br></p><p>Words that should be in mono=
space font:</p><p>"This proposal adds a set of //constexpr// free functions=
"</p><p><br></p><p>Phrases that need hyphens:</p><p>digit-to-int<br>high-pe=
rformance<br>error-prone<br>ASCII-compatible<br>char-to-int<br>platform-agn=
ostic<br>platform-specific<br>user-defined<br>std-proposals (because that's=
 the name of this list)<br><br></p><p>Typos / misspellings:<br><br>Change: =
~large data files which use ascii delimeters.<br>To: ~ASCII delimiters.</p>=
<p>Change: ~github.<br>To: ~GitHub.</p><p>Change: We propose 2 additional u=
seful functions todigit, and toxdigit.<br>To: ~functions: todigit and toxdi=
git.&nbsp; (Add colon, remove comma.&nbsp; Oxford command is awkward with t=
wo items.)<br></p><p>Change: 2<br>To: two&nbsp;&nbsp;&nbsp; (this is a gene=
ric change to make things more readable)</p><p>Change: Alternatively, all o=
f these defintions<br>To: Alternatively, all these definitions&nbsp;&nbsp; =
(delete "of', fix spelling of "definitions")</p><p>Change: Each function ha=
s overloads for type <code>char</code>, <code>wchar_t</code>, <code>char16_=
t</code>, and <code>char32_t</code>.<br>To: (Delete final comma.&nbsp; This=
 is stylistic, though, and definitely up to you, of course.)</p><p>Change: =
<em>[note-- All of these~<br></em>To: [<i>Note:</i> All these~ &nbsp;&nbsp;=
&nbsp; (If you want to follow the Standard's formatting, it's non-italic [ =
followed by italic <i>Note:</i> and non-italic note text.&nbsp; Delete "of"=
..)</p><p>Change: <em>locale settings. --end-note]<br></em>To: locale settin=
gs. =E2=80=94<i>end note</i>]&nbsp; (Similarly, this is an "em-dash" (U+002=
014), "end note" in italic (no hyphen between "end" and "note") and a non-i=
talic ] )</p><p>Change: <b>Return:</b><br>To: <b>Returns:</b></p><p>Change:=
 On systems such as windows<br>To: On systems such as Windows</p><p>Change:=
 where <span style=3D"font-family: courier new,monospace;">wchar_t</span> h=
appens to be using an ASCII-compatible encoding<br>To: where <span style=3D=
"font-family: courier new,monospace;">wchar_t</span> happens to be using an=
 ASCII-compatible encoding (UTF-16)</p><p>Change: presense<br>To: presence<=
/p><p>Change: standard committee<br>To: Standard Committee</p><p>Change: Cs=
v file parsers<br>To: .csv file parsers&nbsp; or&nbsp;&nbsp; CSV file parse=
rs</p><p>Change: decide that <code>wchar_t</code> is a bad idea<br>To: deci=
de that <code>wchar_t</code> support in this proposal is a bad idea</p></di=
v></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_292_1825509262.1412455283761--

.

------=_Part_3904_532722223.1412646607415
Content-Type: text/plain; charset=UTF-8

Thank you for proof reading the paper. Your suggestions helped a lot.

On Saturday, October 4, 2014 4:41:23 PM UTC-4, Myriachan wrote:
>
>
> Wasn't there previously a fromdigit?  Also, what you have now as todigit
> seems more like a fromdigit than a todigit, because it just passed an
> isdigit check...
>
>
Naming is hard. The idea of todigit(), especially something like todigit(c,
100), is saying convert this character to a integral digit in the 100's
place. Maybe a better name is toint()? I prefer names like toX() because
such a named combined with the character argument reads as char-to-X.
fromdigit() doesn't really tell you what you're converting the source digit
to. maybe digit_to_int()?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Thank you for proof reading the paper. Your suggestions he=
lped a lot.<br><br>On Saturday, October 4, 2014 4:41:23 PM UTC-4, Myriachan=
 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"ltr"><br>Wa=
sn't there previously a <span style=3D"font-family:courier new,monospace">f=
romdigit</span>?&nbsp; Also, what you have now as <span style=3D"font-famil=
y:courier new,monospace">todigit</span> seems more like a <span style=3D"fo=
nt-family:courier new,monospace">fromdigit</span> than a <span style=3D"fon=
t-family:courier new,monospace">todigit</span>, because it just passed an <=
span style=3D"font-family:courier new,monospace">isdigit</span> check...<br=
><br></div></blockquote><div><br></div><div>Naming is hard. The idea of tod=
igit(), especially something like todigit(c, 100), is saying convert this c=
haracter to a integral digit in the 100's place. Maybe a better name is toi=
nt()? I prefer names like toX() because such a named combined with the char=
acter argument reads as char-to-X. fromdigit() doesn't really tell you what=
 you're converting the source digit to. maybe digit_to_int()?</div></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3904_532722223.1412646607415--

.

------=_Part_3076_177935915.1412671872391
Content-Type: text/plain; charset=UTF-8

On Monday, October 6, 2014 6:50:07 PM UTC-7, Matthew Fioravante wrote:
>
> Thank you for proof reading the paper. Your suggestions helped a lot.
>
> On Saturday, October 4, 2014 4:41:23 PM UTC-4, Myriachan wrote:
>>
>>
>> Wasn't there previously a fromdigit?  Also, what you have now as todigit
>> seems more like a fromdigit than a todigit, because it just passed an
>> isdigit check...
>>
>>
> Naming is hard. The idea of todigit(), especially something like
> todigit(c, 100), is saying convert this character to a integral digit in
> the 100's place. Maybe a better name is toint()? I prefer names like toX()
> because such a named combined with the character argument reads as
> char-to-X. fromdigit() doesn't really tell you what you're converting the
> source digit to. maybe digit_to_int()?
>

The first question--about fromdigit--was more about whether there was an
inverse operation: the equivalent of "0123456789abcdef"[x].  This is less
necessary, though, since it's obviously very simple to implement. =)

toint works as a name, I think, but sucks for readability; to_int would be
better for readability, but doesn't fit the pattern of the rest of the
functions' names.  If the function were named toint or similar, the inverse
operation could be named tochar or similar.  I suppose that for tochar,
lowercase would be what is returned for digits 10-15.  A Boolean parameter
to select whether to use uppercase could be possible, or a bool template
parameter, but just wrapping toupper around tochar would work.

I think that this should be changed to <= 127, in order to avoid issues
related to 128 not being a valid char on platforms with an 8-bit signed char
(i.e., most).  I'm sure that readers would have understood what was meant,
so it's really just me being pedantic again:

constexpr bool std::ascii::isascii(char c) noexcept;
> constexpr bool std::ascii::isascii(wchar_t c) noexcept;
> constexpr bool std::ascii::isascii(char16_t c) noexcept;
> constexpr bool std::ascii::isascii(char32_t c) noexcept;
>
> *Returns*: true if c >= 0 && c < 128
>
I love your proposal, though, since at where I work we've had to implement
an equivalent of these functions on who knows how many projects at this
point...

Melissa

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Monday, October 6, 2014 6:50:07 PM UTC-7, Matthew Fiora=
vante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">T=
hank you for proof reading the paper. Your suggestions helped a lot.<br><br=
>On Saturday, October 4, 2014 4:41:23 PM UTC-4, Myriachan 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"ltr"><br>Wasn't there previously a=
 <span style=3D"font-family:courier new,monospace">fromdigit</span>?&nbsp; =
Also, what you have now as <span style=3D"font-family:courier new,monospace=
">todigit</span> seems more like a <span style=3D"font-family:courier new,m=
onospace">fromdigit</span> than a <span style=3D"font-family:courier new,mo=
nospace">todigit</span>, because it just passed an <span style=3D"font-fami=
ly:courier new,monospace">isdigit</span> check...<br><br></div></blockquote=
><div><br></div><div>Naming is hard. The idea of todigit(), especially some=
thing like todigit(c, 100), is saying convert this character to a integral =
digit in the 100's place. Maybe a better name is toint()? I prefer names li=
ke toX() because such a named combined with the character argument reads as=
 char-to-X. fromdigit() doesn't really tell you what you're converting the =
source digit to. maybe digit_to_int()?</div></div></blockquote><div><br>The=
 first question--about <span style=3D"font-family: courier new,monospace;">=
fromdigit</span>--was more about whether there was an inverse operation: th=
e equivalent of <span style=3D"font-family: courier new,monospace;">"012345=
6789abcdef"[x]</span>.&nbsp; This is less necessary, though, since it's obv=
iously very simple to implement. =3D)<br><br><span style=3D"font-family: co=
urier new,monospace;">toint</span> works as a name, I think, but sucks for =
readability; <span style=3D"font-family: courier new,monospace;">to_int</sp=
an> would be better for readability, but doesn't fit the pattern of the res=
t of the functions' names.&nbsp; If the function were named <span style=3D"=
font-family: courier new,monospace;">toint</span> or similar, the inverse o=
peration could be named <span style=3D"font-family: courier new,monospace;"=
>tochar</span> or similar.&nbsp; I suppose that for <span style=3D"font-fam=
ily: courier new,monospace;">tochar</span>, lowercase would be what is retu=
rned for digits 10-15.&nbsp; A Boolean parameter to select whether to use u=
ppercase could be possible, or a <span style=3D"font-family: courier new,mo=
nospace;">bool</span> template parameter, but just wrapping <span style=3D"=
font-family: courier new,monospace;">toupper</span> around <span style=3D"f=
ont-family: courier new,monospace;">tochar</span> would work.<br><br>I thin=
k that this should be changed to <span style=3D"font-family: courier new,mo=
nospace;">&lt;=3D 127</span>, in order to avoid issues related to <span sty=
le=3D"font-family: courier new,monospace;">128</span> not being a valid <sp=
an style=3D"font-family: courier new,monospace;">char</span> on platforms w=
ith an 8-bit signed <span style=3D"font-family: courier new,monospace;">cha=
r</span> (i.e., most).&nbsp; I'm sure that readers would have understood wh=
at was meant, so it's really just me being pedantic again:<br><br><blockquo=
te style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204,=
 204); padding-left: 1ex;" class=3D"gmail_quote"><pre><code><code>constexpr=
 bool std::ascii::isascii(char c) noexcept;
constexpr bool std::ascii::isascii(wchar_t c) noexcept;
constexpr bool std::ascii::isascii(char16_t c) noexcept;<br></code>constexp=
r bool std::ascii::isascii(char32_t c) noexcept;
</code></pre>

<p><strong>Returns</strong>: <code>true</code> if <code>c &gt;=3D 0 &amp;&a=
mp; c &lt; 128</code></p></blockquote><p>I love your proposal, though, sinc=
e at where I work we've had to implement an equivalent of these functions o=
n who knows how many projects at this point...</p><p>Melissa<br></p></div><=
/div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3076_177935915.1412671872391--

.

------=_Part_304_1482579577.1412684391368
Content-Type: text/plain; charset=UTF-8



On Tuesday, October 7, 2014 4:51:12 AM UTC-4, Myriachan wrote:
>
>
> The first question--about fromdigit--was more about whether there was an
> inverse operation: the equivalent of "0123456789abcdef"[x].
>

Good idea, added.


> This is less necessary, though, since it's obviously very simple to
> implement. =)
>

All of these are simple but annoying to implement and test.


>
> toint works as a name, I think, but sucks for readability; to_int would
> be better for readability, but doesn't fit the pattern of the rest of the
> functions' names.  If the function were named toint or similar, the
> inverse operation could be named tochar or similar.  I suppose that for
> tochar, lowercase would be what is returned for digits 10-15.  A Boolean
> parameter to select whether to use uppercase could be possible, or a bool
> template parameter, but just wrapping toupper around tochar would work.
>

I've added fromdigit(int d, int m); fromxdigit(int d, int m, bool upper).

Other options are:
fromxdigit();
fromXdigit(); //This doesn't mirror the toxdigit() functions

Or:
fromxdigit();
toupper(fromxdigit()); //Fully qualified, this is a lot of typing

All of them should inline down to the same thing so it doesn't matter too
much.


>
> I think that this should be changed to <= 127, in order to avoid issues
> related to 128 not being a valid char on platforms with an 8-bit signed
> char (i.e., most).  I'm sure that readers would have understood what was
> meant, so it's really just me being pedantic again:
>

When its time to encode it in standardeze being pedantic matters, so I
fixed this one.


>
> constexpr bool std::ascii::isascii(char c) noexcept;
>> constexpr bool std::ascii::isascii(wchar_t c) noexcept;
>> constexpr bool std::ascii::isascii(char16_t c) noexcept;
>> constexpr bool std::ascii::isascii(char32_t c) noexcept;
>>
>> *Returns*: true if c >= 0 && c < 128
>>
> I love your proposal, though, since at where I work we've had to implement
> an equivalent of these functions on who knows how many projects at this
> point...
>
So have I and I'm tired of doing it. Glad to see there are others out there
who could use this functionality.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Tuesday, October 7, 2014 4:51:12 AM UTC-4, Myri=
achan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><br>The first question--about <span style=3D"font-family:courier new,mo=
nospace">fromdigit</span>--was more about whether there was an inverse oper=
ation: the equivalent of <span style=3D"font-family:courier new,monospace">=
"0123456789abcdef"[x]</span>.&nbsp; </div></div></blockquote><div><br></div=
><div>Good idea, added.</div><div>&nbsp;</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div>This is less necessary, though, since=
 it's obviously very simple to implement. =3D)<br></div></div></blockquote>=
<div><br></div><div>All of these are simple but annoying to implement and t=
est.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><br><span style=3D"font-family:courier new,monospace">to=
int</span> works as a name, I think, but sucks for readability; <span style=
=3D"font-family:courier new,monospace">to_int</span> would be better for re=
adability, but doesn't fit the pattern of the rest of the functions' names.=
&nbsp; If the function were named <span style=3D"font-family:courier new,mo=
nospace">toint</span> or similar, the inverse operation could be named <spa=
n style=3D"font-family:courier new,monospace">tochar</span> or similar.&nbs=
p; I suppose that for <span style=3D"font-family:courier new,monospace">toc=
har</span>, lowercase would be what is returned for digits 10-15.&nbsp; A B=
oolean parameter to select whether to use uppercase could be possible, or a=
 <span style=3D"font-family:courier new,monospace">bool</span> template par=
ameter, but just wrapping <span style=3D"font-family:courier new,monospace"=
>toupper</span> around <span style=3D"font-family:courier new,monospace">to=
char</span> would work.<br></div></div></blockquote><div><br></div><div>I'v=
e added fromdigit(int d, int m); fromxdigit(int d, int m, bool upper).&nbsp=
;</div><div><br></div><div>Other options are:</div><div>fromxdigit();</div>=
<div>fromXdigit(); //This doesn't mirror the toxdigit() functions</div><div=
><br></div><div>Or:</div><div>fromxdigit();</div><div>toupper(fromxdigit())=
; //Fully qualified, this is a lot of typing</div><div><br></div><div>All o=
f them should inline down to the same thing so it doesn't matter too much.<=
/div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><br>I think that this should be changed to <span style=3D"fon=
t-family:courier new,monospace">&lt;=3D 127</span>, in order to avoid issue=
s related to <span style=3D"font-family:courier new,monospace">128</span> n=
ot being a valid <span style=3D"font-family:courier new,monospace">char</sp=
an> on platforms with an 8-bit signed <span style=3D"font-family:courier ne=
w,monospace">char</span> (i.e., most).&nbsp; I'm sure that readers would ha=
ve understood what was meant, so it's really just me being pedantic again:<=
br></div></div></blockquote><div><br></div><div>When its time to encode it =
in standardeze being pedantic matters, so I fixed this one.</div><div>&nbsp=
;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><=
br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(=
204,204,204);padding-left:1ex" class=3D"gmail_quote"><pre><code><code>const=
expr bool std::ascii::isascii(char c) noexcept;
constexpr bool std::ascii::isascii(wchar_t c) noexcept;
constexpr bool std::ascii::isascii(char16_t c) noexcept;<br></code>constexp=
r bool std::ascii::isascii(char32_t c) noexcept;
</code></pre>

<p><strong>Returns</strong>: <code>true</code> if <code>c &gt;=3D 0 &amp;&a=
mp; c &lt; 128</code></p></blockquote><p>I love your proposal, though, sinc=
e at where I work we've had to implement an equivalent of these functions o=
n who knows how many projects at this point...</p></div></div></blockquote>=
<div>So have I and I'm tired of doing it. Glad to see there are others out =
there who could use this functionality.&nbsp;</div></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_304_1482579577.1412684391368--

.

------=_Part_12021_1633496023.1412684442611
Content-Type: text/plain; charset=UTF-8

Let me know if you see anything else. Otherwise I'm going to submit this
paper, strong bitset, and the alignment paper tonight for Urbana.

Thanks!

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_12021_1633496023.1412684442611
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Let me know if you see anything else. Otherwise I'm going to submit this paper, strong bitset, and the alignment paper tonight for Urbana.<br><br><div>Thanks!</div></div>

<p></p>

-- <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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_12021_1633496023.1412684442611--

.