Topic: A constexpr Bitwise operations library 2
Author: fmatthew5876@gmail.com
Date: Sun, 10 Nov 2013 21:51:11 -0800 (PST)
Raw View
------=_Part_660_33511968.1384149071206
Content-Type: text/plain; charset=ISO-8859-1
This is a continuation of
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/8WB2Z9d7A0w
Please do not post on that thread anymore.
I've created a new thread because the github link has changed:
https://github.com/fmatthew5876/stdcxx-bitops
I've made updates to the reference header and have started writing the
proposal.
--
---
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_660_33511968.1384149071206
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This is a continuation of <br><br>https://groups.google.co=
m/a/isocpp.org/forum/#!topic/std-proposals/8WB2Z9d7A0w<br><br>Please do not=
post on that thread anymore.<br><br>I've created a new thread because the =
github link has changed:<br>https://github.com/fmatthew5876/stdcxx-bitops<b=
r><br>I've made updates to the reference header and have started writing th=
e proposal.<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_660_33511968.1384149071206--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 11 Nov 2013 10:54:27 -0500
Raw View
On Mon, Nov 11, 2013 at 12:51 AM, <fmatthew5876@gmail.com> wrote:
> I've created a new thread because the github link has changed:
> https://github.com/fmatthew5876/stdcxx-bitops
Some findings:
1. The `integral` template argument is not constrained; you need some
"Requirements" for it.
2. Some other papers of SG6 also add their shifting operations; It might
be helpful to split this part into an additional section, then we discuss
how to deal with those.
3. It might be helpful to make up an sub namespace. If you plan to go
to a TS as well, it may look like: std::experimental::bitops .
4. The naming is cryptic. A naming scheme I can think of is
cntt0 -> count_trailing<0>, popcount -> count<1>,
mskt0ls1b -> mask_trailing_and_least_significant<0, 1>,
where the template parameters are bool. This is merely a
thought.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
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/.
.
Author: fmatthew5876@gmail.com
Date: Mon, 11 Nov 2013 19:20:18 -0800 (PST)
Raw View
------=_Part_1018_5087694.1384226418833
Content-Type: text/plain; charset=ISO-8859-1
On Monday, November 11, 2013 10:54:27 AM UTC-5, Zhihao Yuan wrote:
>
> On Mon, Nov 11, 2013 at 12:51 AM, <fmatth...@gmail.com <javascript:>>
> wrote:
> > I've created a new thread because the github link has changed:
> > https://github.com/fmatthew5876/stdcxx-bitops
>
> Some findings:
>
> 1. The `integral` template argument is not constrained; you need some
> "Requirements" for it.
>
If you mean in the paper. I added some comments. If you mean in the example
header, I'm leaving them out for now to reduce clutter.
>
> 2. Some other papers of SG6 also add their shifting operations; It might
> be helpful to split this part into an additional section, then we
> discuss
> how to deal with those.
>
I'm not exactly sure what you mean by shifting operation if its not
logical, arithmetic, and rotate. Do you have an example? If you mean
proposals like the unbounded precision integer proposal, overloads could
easily be added for the shifts.
>
> 3. It might be helpful to make up an sub namespace. If you plan to go
> to a TS as well, it may look like: std::experimental::bitops .
>
> I'll take a note on that. Right now just want to get a working paper for
submission.
> 4. The naming is cryptic. A naming scheme I can think of is
> cntt0 -> count_trailing<0>, popcount -> count<1>,
> mskt0ls1b -> mask_trailing_and_least_significant<0, 1>,
> where the template parameters are bool. This is merely a
> thought.
>
> Naming, the hardest task there is in programming.
I'm not sure I like those names because they are very long. The template
arguments don't buy you anything really in terms of expression and I think
they just add even more verbosity and confusion, especially the double
argument mask_trailing_and_least-significant<X,Y>. Also using template
arguments means this proposal has no chance to be adopted in C. If it
gains traction, I might consider a C proposal along with this one. I think
cntt0 is much better than ctz. I've thought about this for a while and have
come to the conclusion that for these short style of mnemonics, verbs
should be least 3 characters long. Just the letter 'c' could have a lot of
meanings like count, clone, clear, compress, crypto, etc.. The nouns can be
shorter because they are reused so often and create a sort of theme.
That being said I'm not married to the names I have now. They will probably
change 20 more times before this work is done.
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>
--
---
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_1018_5087694.1384226418833
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, November 11, 2013 10:54:27 AM UTC-5, Zh=
ihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Mon, Nov 11=
, 2013 at 12:51 AM, <<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"j3kEy-vfS34J">fmatth...@gmail.com</a>> wrote:
<br>> I've created a new thread because the github link has changed:
<br>> <a href=3D"https://github.com/fmatthew5876/stdcxx-bitops" target=
=3D"_blank">https://github.com/<wbr>fmatthew5876/stdcxx-bitops</a>
<br>
<br>Some findings:
<br>
<br> 1. The `integral` template argument is not constrained; you need =
some
<br> "Requirements" for it.
<br></blockquote><div>If you mean in the paper. I added some comments. If y=
ou mean in the example header, I'm leaving them out for now to reduce clutt=
er. </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br> 2. Some other papers of SG6 also add their shifting operations; I=
t might
<br> be helpful to split this part into an additional section,=
then we discuss
<br> how to deal with those.
<br></blockquote><div>I'm not exactly sure what you mean by shifting operat=
ion if its not logical, arithmetic, and rotate. Do you have an example? If =
you mean proposals like the unbounded precision integer proposal, overloads=
could easily be added for the shifts.</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">
<br> 3. It might be helpful to make up an sub namespace. If you =
plan to go
<br> to a TS as well, it may look like: std::experimental::bit=
ops .
<br>
<br></blockquote><div>I'll take a note on that. Right now just want to get =
a working paper for submission.</div><div> </div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"> 4. The naming is cryptic. A naming sche=
me I can think of is
<br> cntt0 -> count_trailing<0>, popcount -> count=
<1>,
<br> mskt0ls1b -> mask_trailing_and_least_<wbr>significant&=
lt;0, 1>,
<br> where the template parameters are bool. This is mer=
ely a
<br> thought.
<br>
<br></blockquote><div>Naming, the hardest task there is in programming.&nbs=
p;</div><div><br></div><div>I'm not sure I like those names because they ar=
e very long. <span style=3D"font-size: 13px;">The template arguments d=
on't buy you anything really in terms of expression and I think they just a=
dd even more verbosity and confusion, especially the double argument mask_t=
railing_and_least-significant<X,Y>. </span><span style=3D"font-s=
ize: 13px;">Also using template arguments means this proposal has no chance=
to be adopted in C. If it gains traction, I might consider a C propo=
sal along with this one. I think cntt0 is much better than ctz. I've though=
t about this for a while and have come to the conclusion that for these sho=
rt style of mnemonics, verbs should be least 3 characters long. Just the le=
tter 'c' could have a lot of meanings like count, clone, clear, compress, c=
rypto, etc.. The nouns can be shorter because they are reused so often and =
create a sort of theme.</span></div><div><span style=3D"font-size: 13px;"><=
br></span></div><div><span style=3D"font-size: 13px;">That being said I'm n=
ot married to the names I have now. They will probably change 20 more times=
before this work is done.</span></div><div> </div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/=
</a>
<br></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" 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_1018_5087694.1384226418833--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Tue, 12 Nov 2013 00:16:41 -0500
Raw View
On Mon, Nov 11, 2013 at 10:20 PM, <fmatthew5876@gmail.com> wrote:
> If you mean in the paper. I added some comments. If you mean in the example
> header, I'm leaving them out for now to reduce clutter.
I only see
//template arguments named "integral" are assumed to be signed or
unsigned integer types.
//That is, std::is_integral<integral>::value == true.
I think sometimes you don't need both.
>> 2. Some other papers of SG6 also add their shifting operations; It might
>> be helpful to split this part into an additional section, then we
>> discuss
>> how to deal with those.
As a follow up to
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3352.html
SG6 wants to standardize some generic rounding facilities, like
(copy-paste Lawrence's initial material in Chicago):
// Right Shift
template< rounding Rnd, typename Type >
constexpr Type rshift( Type value, int count /* > or >= 0 */ );
// Bidirectional Shift
template< rounding Rnd, typename Type >
constexpr Type bshift( Type value, int count );
I'm not saying "split your shift ops into another paper", just
another section -- an editorial change.
> Also using template
> arguments means this proposal has no chance to be adopted in C. If it gains
> traction, I might consider a C proposal along with this one.
I cross my fingers to wish wg14 shows no interest to this,
but it's very unlikely to be possible. I want to see templated
(I mean `integral`) bitops in c++.
> That being said I'm not married to the names I have now. They will probably
> change 20 more times before this work is done.
Don't worry, LEWG has a very efficient solution to those naming
issues: propose all (by all the participants!), vote two rounds :)
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
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/.
.
Author: fmatthew5876@gmail.com
Date: Tue, 12 Nov 2013 05:17:47 -0800 (PST)
Raw View
------=_Part_907_32465894.1384262267401
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, November 12, 2013 12:16:41 AM UTC-5, Zhihao Yuan wrote:
>
> On Mon, Nov 11, 2013 at 10:20 PM, <fmatth...@gmail.com <javascript:>>
> wrote:
> > If you mean in the paper. I added some comments. If you mean in the
> example
> > header, I'm leaving them out for now to reduce clutter.
>
> I only see
>
> //template arguments named "integral" are assumed to be signed or
> unsigned integer types.
> //That is, std::is_integral<integral>::value == true.
>
> I think sometimes you don't need both.
>
I'm planning on supporting signed and unsigned types unless someone comes
up with a good reason not to. They are both just binary numbers and some
operations like cntl1 (count leading sign bits) are sort of made for signed
values. lshr() is also really just a usability wrapper for logically
shifting right signed numbers. The danger of the 2 int types comes with
comparing signed and unsigned, the interface doesn't impose or encourage
those comparisons.
> >> 2. Some other papers of SG6 also add their shifting operations; It
> might
> >> be helpful to split this part into an additional section, then we
> >> discuss
> >> how to deal with those.
>
> As a follow up to
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3352.html
>
> SG6 wants to standardize some generic rounding facilities, like
> (copy-paste Lawrence's initial material in Chicago):
>
> // Right Shift
> template< rounding Rnd, typename Type >
> constexpr Type rshift( Type value, int count /* > or >= 0 */ );
>
> // Bidirectional Shift
> template< rounding Rnd, typename Type >
> constexpr Type bshift( Type value, int count );
>
> I'm not saying "split your shift ops into another paper", just
> another section -- an editorial change.
>
Will look into it, thanks!
>
> > Also using template
> > arguments means this proposal has no chance to be adopted in C. If it
> gains
> > traction, I might consider a C proposal along with this one.
>
> I cross my fingers to wish wg14 shows no interest to this,
> but it's very unlikely to be possible. I want to see templated
> (I mean `integral`) bitops in c++.
>
One solution could be something like this:
template <class integral> int op(integral x);
int op(unsigned int x);
int opl(unsigned long x);
int opll(unsigned long long x);
int ops(unsigned short x);
int opb(unsigned char x);
Or use templates in C++ and that horrible generic macro thing in C11.
That being said I really don't want to give up templates and constexpr just
to satisfy the C community and will fight for them. I think that's a very
bad situation if we have to limit our interfaces just because C hasn't
caught up. This is a C++ proposal first and foremost, C compatibility is
highly desirable but secondary.
> > That being said I'm not married to the names I have now. They will
> probably
> > change 20 more times before this work is done.
>
> Don't worry, LEWG has a very efficient solution to those naming
> issues: propose all (by all the participants!), vote two rounds :)
>
Ok, I'll make a name section with all of the proposals and a few other of
my own. If anyone else has ideas for how to name one or more functions, let
me know and I'll add your idea.
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>
BTW, thank you for your help. Its much appreciated!
--
---
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_907_32465894.1384262267401
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, November 12, 2013 12:16:41 AM UTC-5, Z=
hihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Mon, Nov 1=
1, 2013 at 10:20 PM, <<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"CPzeBR4__VQJ">fmatth...@gmail.com</a>> wrote:
<br>> If you mean in the paper. I added some comments. If you mean in th=
e example
<br>> header, I'm leaving them out for now to reduce clutter.
<br>
<br>I only see
<br>
<br> //template arguments named "integral" are assumed to be signed o=
r
<br>unsigned integer types.
<br> //That is, std::is_integral<integral>::<wbr>value =3D=3D t=
rue.
<br>
<br>I think sometimes you don't need both.
<br></blockquote><div> </div><div>I'm planning on supporting signed an=
d unsigned types unless someone comes up with a good reason not to. <s=
pan style=3D"font-size: 13px;">They are both just binary numbers and some o=
perations like cntl1 (count leading sign bits) are sort of made for signed =
values. lshr() is also really just a usability wrapper for logically shifti=
ng right signed numbers. </span><span style=3D"font-size: 13px;">The d=
anger of the 2 int types comes with comparing signed and unsigned, the inte=
rface doesn't impose or encourage those comparisons. </span></div><div=
><span style=3D"font-size: 13px;"><br></span></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">
<br>>> 2. Some other papers of SG6 also add their shifting oper=
ations; It might
<br>>> be helpful to split this part into an additional=
section, then we
<br>>> discuss
<br>>> how to deal with those.
<br>
<br>As a follow up to
<br>
<br> <a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/20=
12/n3352.html" target=3D"_blank">http://www.open-std.org/JTC1/<wbr>SC22/WG2=
1/docs/papers/2012/<wbr>n3352.html</a>
<br>
<br>SG6 wants to standardize some generic rounding facilities, like
<br>(copy-paste Lawrence's initial material in Chicago):
<br>
<br> // Right Shift
<br> template< rounding Rnd, typename Type >
<br> constexpr Type rshift( Type value, int count /* > or >=3D =
0 */ );
<br>
<br> // Bidirectional Shift
<br> template< rounding Rnd, typename Type >
<br> constexpr Type bshift( Type value, int count );
<br>
<br>I'm not saying "split your shift ops into another paper", just
<br>another section -- an editorial change.
<br></blockquote><div> </div><div>Will look into it, thanks!</div><div=
> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>> Also using template
<br>> arguments means this proposal has no chance to be adopted in C. &n=
bsp;If it gains
<br>> traction, I might consider a C proposal along with this one.
<br>
<br>I cross my fingers to wish wg14 shows no interest to this,
<br>but it's very unlikely to be possible. I want to see templated
<br>(I mean `integral`) bitops in c++.
<br></blockquote><div><br></div><div>One solution could be something like t=
his:</div><div>template <class integral> int op(integral x); </d=
iv><div>int op(unsigned int x);</div><div>int opl(unsigned long x);</div><d=
iv>int opll(unsigned long long x);</div><div>int ops(unsigned short x);</di=
v><div>int opb(unsigned char x);</div><div><br></div><div>Or use templates =
in C++ and that horrible generic macro thing in C11.</div><div><br></div><d=
iv>That being said I really don't want to give up templates and constexpr j=
ust to satisfy the C community and will fight for them. I think that's a ve=
ry bad situation if we have to limit our interfaces just because C hasn't c=
aught up. This is a C++ proposal first and foremost, C compatibility is hig=
hly desirable but secondary.</div><div> </div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">> That being said I'm not married to the names I ha=
ve now. They will probably
<br>> change 20 more times before this work is done.
<br>
<br>Don't worry, LEWG has a very efficient solution to those naming
<br>issues: propose all (by all the participants!), vote two rounds :)
<br></blockquote><div> </div><div>Ok, I'll make a name section with al=
l of the proposals and a few other of my own. If anyone else has ideas for =
how to name one or more functions, let me know and I'll add your idea.</div=
><div> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/=
</a>
<br></blockquote><div><br></div><div>BTW, thank you for your help. Its much=
appreciated! </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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_907_32465894.1384262267401--
.
Author: fmatthew5876@gmail.com
Date: Sun, 8 Dec 2013 18:19:24 -0800 (PST)
Raw View
------=_Part_2537_12378843.1386555564360
Content-Type: text/plain; charset=ISO-8859-1
Everyone, sorry I've been away for such a long time. I've finally got a
full draft of the entire proposal available now on github in markdown and
html format.
I looked at that SG6 paper you mentioned and didn't see anything about
shift operations. Also, I'm not so sure it makes sense to have rounding
modes for shifts. You're just shifting bits, what kind of rounding is there
in relation to that?
Any feedback on the paper would be greatly appreciated. Thank you!
On Tuesday, November 12, 2013 8:17:47 AM UTC-5, fmatth...@gmail.com wrote:
>
>
>
> On Tuesday, November 12, 2013 12:16:41 AM UTC-5, Zhihao Yuan wrote:
>>
>> On Mon, Nov 11, 2013 at 10:20 PM, <fmatth...@gmail.com> wrote:
>> > If you mean in the paper. I added some comments. If you mean in the
>> example
>> > header, I'm leaving them out for now to reduce clutter.
>>
>> I only see
>>
>> //template arguments named "integral" are assumed to be signed or
>> unsigned integer types.
>> //That is, std::is_integral<integral>::value == true.
>>
>> I think sometimes you don't need both.
>>
>
> I'm planning on supporting signed and unsigned types unless someone comes
> up with a good reason not to. They are both just binary numbers and some
> operations like cntl1 (count leading sign bits) are sort of made for signed
> values. lshr() is also really just a usability wrapper for logically
> shifting right signed numbers. The danger of the 2 int types comes with
> comparing signed and unsigned, the interface doesn't impose or encourage
> those comparisons.
>
>
>> >> 2. Some other papers of SG6 also add their shifting operations; It
>> might
>> >> be helpful to split this part into an additional section, then we
>> >> discuss
>> >> how to deal with those.
>>
>> As a follow up to
>>
>> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3352.html
>>
>> SG6 wants to standardize some generic rounding facilities, like
>> (copy-paste Lawrence's initial material in Chicago):
>>
>> // Right Shift
>> template< rounding Rnd, typename Type >
>> constexpr Type rshift( Type value, int count /* > or >= 0 */ );
>>
>> // Bidirectional Shift
>> template< rounding Rnd, typename Type >
>> constexpr Type bshift( Type value, int count );
>>
>> I'm not saying "split your shift ops into another paper", just
>> another section -- an editorial change.
>>
>
> Will look into it, thanks!
>
>
>>
>> > Also using template
>> > arguments means this proposal has no chance to be adopted in C. If it
>> gains
>> > traction, I might consider a C proposal along with this one.
>>
>> I cross my fingers to wish wg14 shows no interest to this,
>> but it's very unlikely to be possible. I want to see templated
>> (I mean `integral`) bitops in c++.
>>
>
> One solution could be something like this:
> template <class integral> int op(integral x);
> int op(unsigned int x);
> int opl(unsigned long x);
> int opll(unsigned long long x);
> int ops(unsigned short x);
> int opb(unsigned char x);
>
> Or use templates in C++ and that horrible generic macro thing in C11.
>
> That being said I really don't want to give up templates and constexpr
> just to satisfy the C community and will fight for them. I think that's a
> very bad situation if we have to limit our interfaces just because C hasn't
> caught up. This is a C++ proposal first and foremost, C compatibility is
> highly desirable but secondary.
>
>
>> > That being said I'm not married to the names I have now. They will
>> probably
>> > change 20 more times before this work is done.
>>
>> Don't worry, LEWG has a very efficient solution to those naming
>> issues: propose all (by all the participants!), vote two rounds :)
>>
>
> Ok, I'll make a name section with all of the proposals and a few other of
> my own. If anyone else has ideas for how to name one or more functions, let
> me know and I'll add your idea.
>
>
>>
>> --
>> Zhihao Yuan, ID lichray
>> The best way to predict the future is to invent it.
>> ___________________________________________________
>> 4BSD -- http://4bsd.biz/
>>
>
> BTW, thank you for your help. Its much appreciated!
>
--
---
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_2537_12378843.1386555564360
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Everyone, sorry I've been away for such a long time. I've =
finally got a full draft of the entire proposal available now on github in =
markdown and html format.<div><br></div><div>I looked at that SG6 paper you=
mentioned and didn't see anything about shift operations. Also, I'm not so=
sure it makes sense to have rounding modes for shifts. You're just shiftin=
g bits, what kind of rounding is there in relation to that?</div><div><br><=
/div><div>Any feedback on the paper would be greatly appreciated. Thank you=
!</div><div><br>On Tuesday, November 12, 2013 8:17:47 AM UTC-5, fmatth...@g=
mail.com 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><br>On Tuesday, November 12, 2013 12:16:41 AM UTC-5, Zhihao Yuan wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">On Mon, Nov 11, 2013 at 10:20 PM,=
<<a>fmatth...@gmail.com</a>> wrote:
<br>> If you mean in the paper. I added some comments. If you mean in th=
e example
<br>> header, I'm leaving them out for now to reduce clutter.
<br>
<br>I only see
<br>
<br> //template arguments named "integral" are assumed to be signed o=
r
<br>unsigned integer types.
<br> //That is, std::is_integral<integral>::<wbr>value =3D=3D t=
rue.
<br>
<br>I think sometimes you don't need both.
<br></blockquote><div> </div><div>I'm planning on supporting signed an=
d unsigned types unless someone comes up with a good reason not to. <s=
pan style=3D"font-size:13px">They are both just binary numbers and some ope=
rations like cntl1 (count leading sign bits) are sort of made for signed va=
lues. lshr() is also really just a usability wrapper for logically shifting=
right signed numbers. </span><span style=3D"font-size:13px">The dange=
r of the 2 int types comes with comparing signed and unsigned, the interfac=
e doesn't impose or encourage those comparisons. </span></div><div><sp=
an style=3D"font-size:13px"><br></span></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex">
<br>>> 2. Some other papers of SG6 also add their shifting oper=
ations; It might
<br>>> be helpful to split this part into an additional=
section, then we
<br>>> discuss
<br>>> how to deal with those.
<br>
<br>As a follow up to
<br>
<br> <a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/20=
12/n3352.html" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\75http%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2=
Fpapers%2F2012%2Fn3352.html\46sa\75D\46sntz\0751\46usg\75AFQjCNGaYOOhnd7AeT=
CvYrH4JLbIjekchg';return true;" onclick=3D"this.href=3D'http://www.google.c=
om/url?q\75http%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpape=
rs%2F2012%2Fn3352.html\46sa\75D\46sntz\0751\46usg\75AFQjCNGaYOOhnd7AeTCvYrH=
4JLbIjekchg';return true;">http://www.open-std.org/JTC1/<wbr>SC22/WG21/docs=
/papers/2012/<wbr>n3352.html</a>
<br>
<br>SG6 wants to standardize some generic rounding facilities, like
<br>(copy-paste Lawrence's initial material in Chicago):
<br>
<br> // Right Shift
<br> template< rounding Rnd, typename Type >
<br> constexpr Type rshift( Type value, int count /* > or >=3D =
0 */ );
<br>
<br> // Bidirectional Shift
<br> template< rounding Rnd, typename Type >
<br> constexpr Type bshift( Type value, int count );
<br>
<br>I'm not saying "split your shift ops into another paper", just
<br>another section -- an editorial change.
<br></blockquote><div> </div><div>Will look into it, thanks!</div><div=
> </div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>> Also using template
<br>> arguments means this proposal has no chance to be adopted in C. &n=
bsp;If it gains
<br>> traction, I might consider a C proposal along with this one.
<br>
<br>I cross my fingers to wish wg14 shows no interest to this,
<br>but it's very unlikely to be possible. I want to see templated
<br>(I mean `integral`) bitops in c++.
<br></blockquote><div><br></div><div>One solution could be something like t=
his:</div><div>template <class integral> int op(integral x); </d=
iv><div>int op(unsigned int x);</div><div>int opl(unsigned long x);</div><d=
iv>int opll(unsigned long long x);</div><div>int ops(unsigned short x);</di=
v><div>int opb(unsigned char x);</div><div><br></div><div>Or use templates =
in C++ and that horrible generic macro thing in C11.</div><div><br></div><d=
iv>That being said I really don't want to give up templates and constexpr j=
ust to satisfy the C community and will fight for them. I think that's a ve=
ry bad situation if we have to limit our interfaces just because C hasn't c=
aught up. This is a C++ proposal first and foremost, C compatibility is hig=
hly desirable but secondary.</div><div> </div><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">> That being said I'm not married to the names I have no=
w. They will probably
<br>> change 20 more times before this work is done.
<br>
<br>Don't worry, LEWG has a very efficient solution to those naming
<br>issues: propose all (by all the participants!), vote two rounds :)
<br></blockquote><div> </div><div>Ok, I'll make a name section with al=
l of the proposals and a few other of my own. If anyone else has ideas for =
how to name one or more functions, let me know and I'll add your idea.</div=
><div> </div><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank" onmousedown=3D"t=
his.href=3D'http://www.google.com/url?q\75http%3A%2F%2F4bsd.biz%2F\46sa\75D=
\46sntz\0751\46usg\75AFQjCNEEohiBBmXaBWMbzqBFWtWEgT5t9g';return true;" oncl=
ick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2F4bsd.biz%2F\=
46sa\75D\46sntz\0751\46usg\75AFQjCNEEohiBBmXaBWMbzqBFWtWEgT5t9g';return tru=
e;">http://4bsd.biz/</a>
<br></blockquote><div><br></div><div>BTW, thank you for your help. Its much=
appreciated! </div></div></blockquote></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2537_12378843.1386555564360--
.