Topic: type reduction for integer types(sign bits)
Author: unituniverse.1@gmail.com
Date: Sun, 2 Jun 2013 02:40:53 -0700 (PDT)
Raw View
------=_Part_2099_32548779.1370166053824
Content-Type: text/plain; charset=ISO-8859-1
Considering there is an integer type XInt_Type with bitwidth of n:
How about to let the form of
unsigned XInt_Type
be as an unsigned integer type and the form of
signed XInt_Type as an signed integer type?
It's useful if it is used in template.
template < typename _XInt_Ty >
Make_Signed
{
typedef signed _XInt_Ty type;
};
template < typename _XInt_Ty >
Make_Unsigned
{
typedef unsigned _XInt_Ty type;
};
class A;
'Make_Signed<signed Int16>::type' is 'signed Int16'
'Make_Signed<unsigned Int64>::type' is 'unsigned Int64'
'Make_Signed<void *>::type' is 'void *' (no effect to Pointers)
'Make_Signed<A>::type' causes compiling error
'Make_Signed<signed char>::type' is always signed.
'Make_Unsigned<signed Int32>::type' is 'unsigned Int32'
'Make_Unsigned<unsigned Int64>::type' is 'unsigned Int64'
'Make_Unsigned<void *>::type' is 'void *' (no effect to Pointers)
'Make_Unsigned<A>::type' causes compiling error
'Make_Unsigned<signed char>::type' is always unsigned.
Let the signed [other signes...] [integer_type] be always the signed
integer type and the
signed [other signes...] [integer_type] be always the unsigned integer type.
Such mapping tech that used in BOOST library seems can't cover all the
integer types (of the future or compiler extended integer types),
comparison to the post at this. Either they weren't brief.
--
---
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/?hl=en.
------=_Part_2099_32548779.1370166053824
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Considering there is an integer type XInt_Type with bitwidth of n:</di=
v><div><br></div><div>How about to let the form of</div><div>unsigned XInt_=
Type</div><div>be as an unsigned integer type and the form of</div><div>sig=
ned XInt_Type as an signed integer type?</div><div><br></div><div>It's usef=
ul if it is used in template.</div><div><br></div><div>template < typena=
me _XInt_Ty ></div><div>Make_Signed</div><div>{</div><div> =
typedef signed _XInt_Ty type;</div><div>};</div><div><br></div><div>templat=
e < typename _XInt_Ty ></div><div>Make_Unsigned</div><div>{</div><div=
> typedef unsigned _XInt_Ty type;</div><div>};</div><div><br><=
/div><div><br></div><div>class A;</div><div><br></div><div>'Make_Signed<=
signed Int16>::type' is 'signed Int16'</div><div>'Make_Signed<unsigne=
d Int64>::type' is 'unsigned Int64'</div><div>'Make_Signed<void *>=
::type' is 'void *' (no effect to Pointers)</div><div>'Make_Signed<A>=
::type' causes compiling error</div><div>'Make_Signed<signed char>::t=
ype' is always signed.</div><div>'Make_Unsigned<signed Int32>::type' =
is 'unsigned Int32'</div><div>'Make_Unsigned<unsigned Int64>::type' i=
s 'unsigned Int64'</div><div>'Make_Unsigned<void *>::type' is 'void *=
' (no effect to Pointers)</div><div>'Make_Unsigned<A>::type' causes c=
ompiling error</div><div>'Make_Unsigned<signed char>::type' is always=
unsigned.</div><div><br></div><div>Let the signed [other signes...] [integ=
er_type] be always the signed integer type and the</div><div>signed [other =
signes...] [integer_type] be always the unsigned integer type.</div><div><b=
r></div><div>Such mapping tech that used in BOOST library seems can't cover=
all the integer types (of the future or compiler extended integer types), =
comparison to the post at this. Either they weren't brief.</div><div><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" 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2099_32548779.1370166053824--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Sun, 2 Jun 2013 13:50:44 +0200
Raw View
2013/6/2 <unituniverse.1@gmail.com>:
> Considering there is an integer type XInt_Type with bitwidth of n:
>
> How about to let the form of
> unsigned XInt_Type
> be as an unsigned integer type and the form of
> signed XInt_Type as an signed integer type?
>
> It's useful if it is used in template.
>
> template < typename _XInt_Ty >
> Make_Signed
> {
> typedef signed _XInt_Ty type;
> };
>
> template < typename _XInt_Ty >
> Make_Unsigned
> {
> typedef unsigned _XInt_Ty type;
> };
>
>
> class A;
>
> 'Make_Signed<signed Int16>::type' is 'signed Int16'
> 'Make_Signed<unsigned Int64>::type' is 'unsigned Int64'
> 'Make_Signed<void *>::type' is 'void *' (no effect to Pointers)
> 'Make_Signed<A>::type' causes compiling error
> 'Make_Signed<signed char>::type' is always signed.
> 'Make_Unsigned<signed Int32>::type' is 'unsigned Int32'
> 'Make_Unsigned<unsigned Int64>::type' is 'unsigned Int64'
> 'Make_Unsigned<void *>::type' is 'void *' (no effect to Pointers)
> 'Make_Unsigned<A>::type' causes compiling error
> 'Make_Unsigned<signed char>::type' is always unsigned.
>
> Let the signed [other signes...] [integer_type] be always the signed integer
> type and the
> signed [other signes...] [integer_type] be always the unsigned integer type.
I assume for the last sentence that you intended to say here:
"unsigned [other signes...] [integer_type] be always the unsigned integer type."
I'm not so happy with that proposal for the following reasons:
a) The unsigned/signed specifiers are not applicable to user-defined
types (like const or volatile), they are also not isolated specifiers,
because they are used to denote a type such as 'unsigned int'. So in
any way the suggested rules only help when applied to built-in types.
b) We have already a library solution for this: std::make_signed and
std::make_unsigned. It is valid for *all* all integer types (including
the extended ones).
c) I also find your suggested rules confusing: Why is
Make_Unsigned<void *>::type well-formed and a no-op, but
Make_Unsigned<A>::type is ill-formed? What is the rationale for that
difference?
> Such mapping tech that used in BOOST library seems can't cover all the
> integer types (of the future or compiler extended integer types), comparison
> to the post at this.
Exactly for this reason the std::make_signed and std::make_unsigned
where introduced. At the moment I see no convincing reasons for a core
language change, especially because I wouldn't see clear consensus on
the effects of applying these specifiers on non-integral types.
- Daniel
--
---
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/?hl=en.
.
Author: unituniverse.1@gmail.com
Date: Sun, 2 Jun 2013 10:21:59 -0700 (PDT)
Raw View
------=_Part_2368_4896649.1370193719645
Content-Type: text/plain; charset=ISO-8859-1
a) 'the unsigned/signed specifiers are not applicable to user-defined types'
The purpose of these two is still not changed, which is to denote a
build-in integer types, then we can just leave this alone, and this kind of
proposal is not to target to change it.
b) Actually the make_signed and make unsigned are not valid for *all*
integer types. It internally uses a kind of enumerating method, which means
that you can't make sure that the same header can work for all compilers:
The file here is snipped from msvc:
// TEMPLATE CLASS make_signed
template<class _Ty>
struct make_signed
{ // signed partner to _Ty
static const size_t _Bytes = sizeof (_Ty);
typedef typename _If<is_signed<_Ty>::value, _Ty,
typename _If<_Bytes <= sizeof (char), signed char,
typename _If<_Bytes <= sizeof (short), short,
typename _If<_Bytes <= sizeof (int), int,
typename _If<_Bytes <= sizeof (long), long,
_Longlong>::_Type>::_Type>::_Type>
::_Type>::_Type type;
};
// TEMPLATE CLASS make_unsigned
template<class _Ty>
struct make_unsigned
{ // unsigned partner to _Ty
static const size_t _Bytes = sizeof (_Ty);
typedef typename _If<is_unsigned<_Ty>::value, _Ty,
typename _If<_Bytes <= sizeof (char), unsigned char,
typename _If<_Bytes <= sizeof (short), unsigned short,
typename _If<_Bytes <= sizeof (int), unsigned int,
typename _If<_Bytes <= sizeof (long), unsigned long,
_ULonglong>::_Type>::_Type>::_Type>
::_Type>::_Type type;
};
Assuming if a kind of integer type like __int128 has been implimented into
the compiler as the extended integer types from some day, The make_xsigned
templates have to be adjusted too to cover that extension. So that solution
is not once-for-all's.
c) Roughly i think that there are several compilers care about the sign bit
of the pointers internally and others don't, on the contrary. However it
shouldn't have been relied on in well formed C++ sources, so i said 'no
effect'.
The two have been ruled forbidden to denote the UDTs currently, so we can
just keep on what the rule is for UDTs. If it's necessary, we can forbid
signed/unsigned for pointers either.
MY NETWORK IS A CRAP!!!
--
---
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/?hl=en.
------=_Part_2368_4896649.1370193719645
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>a) 'the unsigned/signed specifiers are not applicable to user-defined =
types'</div><div>The purpose of these two is still not changed, which is to=
denote a build-in integer types, then we can just leave this alone, and th=
is kind of proposal is not to target to change it.</div><div><br></div><div=
>b) Actually the make_signed and make unsigned are not valid for *all* inte=
ger types. It internally uses a kind of enumerating method, which means tha=
t you can't make sure that the same header can work for all compilers:</div=
><div>The file here is snipped from msvc:</div><div><br></div><div><span cl=
ass=3D"Apple-tab-span" style=3D"white-space:pre"> </span>// TEMPLATE CLASS =
make_signed</div><div>template<class _Ty></div><div><span class=3D"Ap=
ple-tab-span" style=3D"white-space:pre"> </span>struct make_signed</div><di=
v><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>{<span c=
lass=3D"Apple-tab-span" style=3D"white-space:pre"> </span>// signed partner=
to _Ty</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">=
</span>static const size_t _Bytes =3D sizeof (_Ty);</div><div><br></div><d=
iv><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>typedef=
typename _If<is_signed<_Ty>::value, _Ty,</div><div><span class=3D=
"Apple-tab-span" style=3D"white-space:pre"> </span>typename _If<_Bytes =
<=3D sizeof (char), signed char,</div><div><span class=3D"Apple-tab-span=
" style=3D"white-space:pre"> </span>typename _If<_Bytes <=3D sizeof=
(short), short,</div><div><span class=3D"Apple-tab-span" style=3D"white-sp=
ace:pre"> </span>typename _If<_Bytes <=3D sizeof (int), int,</div>=
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>t=
ypename _If<_Bytes <=3D sizeof (long), long,</div><div><span class=3D=
"Apple-tab-span" style=3D"white-space:pre"> </span>_Longlong>::_Typ=
e>::_Type>::_Type></div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre"> </span>::_Type>::_Type type;</div><div><span=
class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>};</div><div><b=
r></div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </sp=
an>// TEMPLATE CLASS make_unsigned</div><div>template<class _Ty></div=
><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>stru=
ct make_unsigned</div><div><span class=3D"Apple-tab-span" style=3D"white-sp=
ace:pre"> </span>{<span class=3D"Apple-tab-span" style=3D"white-space:pre">=
</span>// unsigned partner to _Ty</div><div><span class=3D"Apple-tab-span"=
style=3D"white-space:pre"> </span>static const size_t _Bytes =3D sizeof (_=
Ty);</div><div><br></div><div><span class=3D"Apple-tab-span" style=3D"white=
-space:pre"> </span>typedef typename _If<is_unsigned<_Ty>::value, =
_Ty,</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> <=
/span>typename _If<_Bytes <=3D sizeof (char), unsigned char,</div><di=
v><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>typena=
me _If<_Bytes <=3D sizeof (short), unsigned short,</div><div><span cl=
ass=3D"Apple-tab-span" style=3D"white-space:pre"> </span>typename _If<=
;_Bytes <=3D sizeof (int), unsigned int,</div><div><span class=3D"Apple-=
tab-span" style=3D"white-space:pre"> </span>typename _If<_Bytes <=
=3D sizeof (long), unsigned long,</div><div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"> </span>_ULonglong>::_Type>::_Type>=
::_Type></div><div><span class=3D"Apple-tab-span" style=3D"white-space:p=
re"> </span>::_Type>::_Type type;</div><div><span class=3D"Apple-t=
ab-span" style=3D"white-space:pre"> </span>};</div><div><br></div><div>Assu=
ming if a kind of integer type like __int128 has been implimented into the =
compiler as the extended integer types from some day, The make_xsigned temp=
lates have to be adjusted too to cover that extension. So that solution is =
not once-for-all's.</div><div><br></div><div>c) Roughly i think that there =
are several compilers care about the sign bit of the pointers internally an=
d others don't, on the contrary. However it shouldn't have been relied on i=
n well formed C++ sources, so i said 'no effect'.</div><div>The two have be=
en ruled forbidden to denote the UDTs currently, so we can just keep on wha=
t the rule is for UDTs. If it's necessary, we can forbid signed/unsigned fo=
r pointers either.</div><div><br></div><div><br></div><div>MY NETWORK IS A =
CRAP!!!</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2368_4896649.1370193719645--
.
Author: Martinho Fernandes <martinho.fernandes@gmail.com>
Date: Mon, 3 Jun 2013 13:24:02 +0200
Raw View
--14dae94ede3ba5176704de3e337f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sun, Jun 2, 2013 at 7:21 PM, <unituniverse.1@gmail.com> wrote:
> b) Actually the make_signed and make unsigned are not valid for *all*
> integer types.
This is from the standard text:
template <class T>
struct make_signed;
If T names a (possibly cv-qualified) signed integer type (3.9.1) then the
member typedef type shall name the type T; otherwise, if T names a
(possibly cv-qualified) unsigned integer type then type shall name the
corresponding signed integer type, with the same cv-qualifiers as T;
otherwise, type shall name the signed integer type with smallest
rank (4.13) for which sizeof(T) =3D=3D sizeof(type), with the same
cv-qualifiers as T.
Requires:T shall be a (possibly cv-qualified) integral type or enumeration
but not a bool type.
template <class T>
struct make_unsigned;
If T names a (possibly cv-qualified) unsigned integer type (3.9.1) then
the member typedef type shall name the type T; otherwise, if T names a
(possibly cv-qualified) signed integer type then type shall name the
corresponding unsigned integer type, with the same cv-qualifiers as T;
otherwise, type shall name the unsigned integer type with smallest
rank (4.13) for which sizeof(T) =3D=3D sizeof(type), with the same
cv-qualifiers as T.
Requires:T shall be a (possibly cv-qualified) integral type or enumeration
but not a bool type.
It says so right there that it is valid for *all* integer types.
It internally uses a kind of enumerating method, which means that you can't
> make sure that the same header can work for all compilers:
>
Who cares? There are lots of stuff in the standard library that require
compiler magic. That was never a problem. Good luck making a particular
implementation of is_pod work on all compilers.
Those traits are the primitives. Treat them as such. There is no point in
adding another primitive that is the same and whose sole use case is the
implementation of the other primitive.
MY NETWORK IS A CRAP!!!
>
Ok.
Mit freundlichen Gr=FC=DFen,
Martinho
--=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/?hl=3Den.
--14dae94ede3ba5176704de3e337f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>On Sun, Jun 2, 2013 at 7:21 PM, <span dir=3D"ltr">&l=
t;<a href=3D"mailto:unituniverse.1@gmail.com" target=3D"_blank">unitunivers=
e.1@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">
b) Actually the make_signed and make unsigned are not valid for *all* integ=
er types.</blockquote><br>This is from the standard text:<br><br>template &=
lt;class T><br>struct make_signed;<br><br>If T names a (possibly cv-qual=
ified) signed integer type (3.9.1) then the<br>
member typedef type shall name the type T; otherwise, if T names a<br>(poss=
ibly cv-qualified) unsigned integer type then type shall name the<br>corres=
ponding signed integer type, with the same cv-qualifiers as T;<br>otherwise=
, type shall name the signed integer type with smallest<br>
rank (4.13) for which sizeof(T) =3D=3D sizeof(type), with the same<br>cv-qu=
alifiers as T.<br>Requires:T shall be a (possibly cv-qualified) integral ty=
pe or enumeration<br>but not a bool type.<br><br>template <class T><b=
r>
struct make_unsigned;<br>If T names a (possibly cv-qualified) unsigned inte=
ger type (3.9.1) then<br>the member typedef type shall name the type T; oth=
erwise, if T names a<br>(possibly cv-qualified) signed integer type then ty=
pe shall name the<br>
corresponding unsigned integer type, with the same cv-qualifiers as T;<br>o=
therwise, type shall name the unsigned integer type with smallest<br>rank (=
4.13) for which sizeof(T) =3D=3D sizeof(type), with the same<br>cv-qualifie=
rs as T.<br>
Requires:T shall be a (possibly cv-qualified) integral type or enumeration<=
br>but not a bool type.<br><br></div>It says so right there that it is vali=
d for *all* integer types.<br><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">
<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">It internally uses a =
kind of enumerating method, which means that you can't make sure that t=
he same header can work for all compilers:<div>
</div></blockquote><div><br></div><div>Who cares? There are lots of stuff i=
n the standard library that require compiler magic. That was never a proble=
m. Good luck making a particular implementation of is_pod work on all compi=
lers.<br>
<br>Those traits are the primitives. Treat them as such. There is no point =
in adding another primitive that is the same and whose sole use case is the=
implementation of the other primitive.<br></div><div><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">
<div></div><div>MY NETWORK IS A CRAP!!!<br></div></blockquote><div>=A0</div=
><div>Ok. <br><br clear=3D"all"><div>Mit freundlichen Gr=FC=DFen,<br><br>Ma=
rtinho</div>
</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" 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--14dae94ede3ba5176704de3e337f--
.