On 14.11.2013, at 12:52, Daryle Walker <darylew@gmail.com>
 wrote:
>=20
> So far, I have two new transformation type-traits, a change to an existin=
g one (adding the built-in character types to std::underlying_type), plus a=
 test type-trait. If you know of other similar transformations in the Stand=
ard, let me know so I can add them.
wrt
> Should bool be added? (There is no mention if it has to shadow another in=
teger type.)
I believe bool won't have an underlying type and should not be added.

wrt char
I believe it might be nice to determine if char is signed or unsigned. but =
couldn't that already be achieved by is_same_t<char, unsigned char>() ?

>=20
> The second proposal does more array extent changing. One type-traits remo=
ves a user-selectable number of extents from an array type. (The current St=
andard has type-traits that do either one or all extents.) The other type-t=
rait adds extents to a given type.

Why can't the example use static_assert instead of assert?

>=20
> Daryle W.
>=20
>=20
> --=20
> =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=
 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-propo=
sals/.

--=20
Prof. Peter Sommerlad

Institut f=FCr Software: Bessere Software - Einfach, Schneller!
HSR Hochschule f=FCr Technik Rapperswil
Oberseestr 10, Postfach 1475, CH-8640 Rapperswil

http://ifs.hsr.ch http://cute-test.com http://linticator.com http://includa=
tor.com
tel:+41 55 222 49 84 =3D=3D mobile:+41 79 432 23 32
fax:+41 55 222 46 29 =3D=3D mailto:peter.sommerlad@hsr.ch





--=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_340_17799915.1384433293218
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, November 14, 2013 1:11:43 PM UTC+1, PeterSommerlad wrote:
>
> On 14.11.2013, at 12:52, Daryle Walker <dar...@gmail.com <javascript:>>
> > Should bool be added? (There is no mention if it has to shadow another
> integer type.)
> I believe bool won't have an underlying type and should not be added.
>

I agree.  bool is quite a special type and should not be considered to have
an underlying type.


> wrt char
> I believe it might be nice to determine if char is signed or unsigned. but
> couldn't that already be achieved by is_same_t<char, unsigned char>() ?
>

No, it could not.  char, signed char and unsigned char are distinct
fundamental types, so is_same<char, unsigned char> is always false and
is_same<char, signed char> is also always false.

Given the restrictions on the relationships between char, signed char and
unsigned char in [basic.fundamental]/1 - it seems reasonable to consider
char to have an underlying type of exactly one of signed char or unsigned
char, so I would be in favor of extending underlying_type to determine this
as Daryl proposes:

A char, a signed char, and an
> unsigned char occupy the same amount of storage and have the same
> alignment requirements (3.11); that is,
> they have the same object representation. For character types, all bits of
> the object representation participate
> in the value representation. For unsigned character types, all possible
> bit patterns of the value representation
> represent numbers. These requirements do not hold for other types. In any
> particular implementation, a
> plain char object can take on either the same values as a signed char or
> an unsigned char; which one is
> implementation-defined.


--

---
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_340_17799915.1384433293218
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, November 14, 2013 1:11:43 PM UTC+1, PeterSomm=
erlad wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 14.11.2013, at =
12:52, Daryle Walker &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"kzVxex4BD-kJ">dar...@gmail.com</a>&gt;
<br>&gt; Should bool be added? (There is no mention if it has to shadow ano=
ther integer type.)
<br>I believe bool won't have an underlying type and should not be added.
<br></blockquote><div><br></div><div>I agree. &nbsp;bool is quite a special=
 type and should not be considered to have an underlying type.</div><div>&n=
bsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">wrt char
<br>I believe it might be nice to determine if char is signed or unsigned. =
but couldn't that already be achieved by is_same_t&lt;char, unsigned char&g=
t;() ?
<br>
</blockquote><div><br></div><div>No, it could not. &nbsp;char, signed char =
and unsigned char are distinct fundamental types, so is_same&lt;char, unsig=
ned char&gt; is always false and is_same&lt;char, signed char&gt; is also a=
lways false.</div><div><br></div><div>Given the restrictions on the relatio=
nships between char, signed char and unsigned char in [basic.fundamental]/1=
 - it seems reasonable to consider char to have an underlying type of exact=
ly one of signed char or unsigned char, so I would be in favor of extending=
 underlying_type to determine this as Daryl proposes:</div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border=
-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style:=
 solid; padding-left: 1ex;">A char, a signed char, and an<br>unsigned char =
occupy the same amount of storage and have the same alignment requirements =
(3.11); that is,<br>they have the same object representation. For character=
 types, all bits of the object representation participate<br>in the value r=
epresentation. For unsigned character types, all possible bit patterns of t=
he value representation<br>represent numbers. These requirements do not hol=
d for other types. In any particular implementation, a<br>plain char object=
 can take on either the same values as a signed char or an unsigned char; w=
hich one is<br>implementation-defined.</blockquote><div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_340_17799915.1384433293218--

.