Topic: 3 possible improvements for C++
Author: nibrot4@gmail.com
Date: Tue, 21 Feb 2017 10:52:22 -0800 (PST)
Raw View
------=_Part_1580_409549483.1487703142709
Content-Type: multipart/alternative;
boundary="----=_Part_1581_402462367.1487703142709"
------=_Part_1581_402462367.1487703142709
Content-Type: text/plain; charset=UTF-8
At a Quora's question [1], in a reply to my answer Michael Finney pointed
three improvements he would like that C++ has.
Please have a look at them and let me know your opinion. Thank you in
advance.
Jordi Noguer
(1st) This is merely one example. Consider the case where you need to build
a finite state machine for some protocol. Generally, there is some block of
common code and then control is transferred to a specific state which may
take additional actions or change the state. How can the state transfer be
accomplished in C/C++? You can use a large IF statement, you can use a
SWITCH statement or you can create a State object hierarchy, where changing
the state is an assignment and switching to the state is invoking
operator(). All of these have unacceptable overheads. Except for PL/1 or
assembly this is difficult to do with maximum efficiency (which can be
critical). Suppose that a new control structure PIVOT were to be added to
C/C++. It would have a required label (because it needs a name), and there
would be a block of code associated with it. Then there would be additional
named blocks of code, which form the individual states. Then a simple,
non-computed, indirect jump could be generated by the compiler. So, it
would look something like this...
MyFsm: pivot
{ code; goto MyFsm }
State1: {
MyFsm = State2; }
State2: {
MyFsm = State1;}
This is not an uncontrolled goto statement, only states for MyFsm could be
assigned to MyFsm.
(2nd) Another example is that break and continue need to be able to specify
the name of the control structure which is the target of break and
continue. Right now, this can only be accomplished by uncontrolled use of
GOTO statements for anything except the inner-most level. This is the
essence of tree-structured code. At least, unlike Java, C/C++ still has a
GOTO statement.
(3rd) Also, there are no more machines whose register size is not a power
of two or which are not two's complement. The logical operator definitions
could be firmed up. Rotate should be added. Explicit logic and arithmetic
shifts should be specified. All of the above could be accomplished without
affecting the validitiy of current code.
[1] https://www.quora.com/What-problem-does-C++-solve-well-that-other-programming-languages-do-not/answer/Jordi-Noguer/comment/30868147?__filter__&__nsrc__=2&__snid3__=776758172
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a28527b3-fd72-42f8-986a-4b7f6c4a52da%40isocpp.org.
------=_Part_1581_402462367.1487703142709
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span class=3D"rendered_qtext"><br>At a Quora's questi=
on [1], in a reply to my answer </span><span class=3D"rendered_qtext">Micha=
el Finney pointed three improvements he would like that C++ has.<br><br>Ple=
ase have a look at them and let me know your opinion. Thank you in advance.=
<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Jordi Noguer<br><br>(1st) This is me=
rely one example. Consider the=20
case where you need to build a finite state machine for some protocol.=20
Generally, there is some block of common code and then control is=20
transferred to a specific state which may take additional actions or=20
change the state. How can the state transfer be accomplished in C/C++?=20
You can use a large IF statement, you can use a SWITCH statement or you=20
can create a State object hierarchy, where changing the state is an=20
assignment and switching to the state is invoking operator(). All of=20
these have unacceptable overheads. Except for PL/1 or assembly this is=20
difficult to do with maximum efficiency (which can be critical). Suppose
that a new control structure PIVOT were to be added to C/C++. It would=20
have a required label (because it needs a name), and there would be a=20
block of code associated with it. Then there would be additional named=20
blocks of code, which form the individual states. Then a simple,=20
non-computed, indirect jump could be generated by the compiler. So, it=20
would look something like this...<br>MyFsm: pivot<br>=C2=A0{ code; goto MyF=
sm }<br>=C2=A0State1: {<br>=C2=A0MyFsm =3D State2; }<br>=C2=A0State2: {<br>=
=C2=A0MyFsm =3D State1;}<br>This is not an uncontrolled goto statement, onl=
y states for MyFsm could be assigned to MyFsm.<br><br>(2nd) Another
example is that break and continue need to be able to specify the name=20
of the control structure which is the target of break and continue.=20
Right now, this can only be accomplished by uncontrolled use of GOTO=20
statements for anything except the inner-most level. This is the essence
of tree-structured code. At least, unlike Java, C/C++ still has a GOTO=20
statement.<br><br>(3rd) Also, there are no more machines whose register siz=
e is=20
not a power of two or which are not two's complement. The logical=20
operator definitions could be firmed up. Rotate should be added.=20
Explicit logic and arithmetic shifts should be specified. All of the=20
above could be accomplished without affecting the validitiy of current=20
code.<br><br>[1] </span><span class=3D"rendered_qtext">https://www.quora.co=
m/What-problem-does-C++-solve-well-that-other-programming-languages-do-not/=
answer/Jordi-Noguer/comment/30868147?__filter__&__nsrc__=3D2&__snid=
3__=3D776758172
</span></div>
<p></p>
-- <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 <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a28527b3-fd72-42f8-986a-4b7f6c4a52da%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a28527b3-fd72-42f8-986a-4b7f6c4a52da=
%40isocpp.org</a>.<br />
------=_Part_1581_402462367.1487703142709--
------=_Part_1580_409549483.1487703142709--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 21 Feb 2017 12:07:00 -0800 (PST)
Raw View
------=_Part_1527_1436283238.1487707620200
Content-Type: multipart/alternative;
boundary="----=_Part_1528_701977697.1487707620200"
------=_Part_1528_701977697.1487707620200
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 21, 2017 at 1:52:22 PM UTC-5, nib...@gmail.com wrote:
>
> (3rd) Also, there are no more machines whose register size is not a power
> of two or which are not two's complement.
>
A lot of people say things like that, but is there any actual proof of that?
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a251867e-746d-4804-b77e-7a4178150605%40isocpp.org.
------=_Part_1528_701977697.1487707620200
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, February 21, 2017 at 1:52:22 PM UTC-5,=
nib...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><span></span><span>(3rd) Also, there are no more machines whose =
register size is=20
not a power of two or which are not two's complement.</span></div></blo=
ckquote><div><br>A lot of people say things like that, but is there any act=
ual proof of that?</div></div>
<p></p>
-- <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 <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a251867e-746d-4804-b77e-7a4178150605%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a251867e-746d-4804-b77e-7a4178150605=
%40isocpp.org</a>.<br />
------=_Part_1528_701977697.1487707620200--
------=_Part_1527_1436283238.1487707620200--
.
Author: John Yates <john@yates-sheets.org>
Date: Tue, 21 Feb 2017 18:10:33 -0500
Raw View
--001a11411480bcb0840549127c1c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Feb 21, 2017 at 3:07 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, February 21, 2017 at 1:52:22 PM UTC-5, nib...@gmail.com wrote=
:
>>
>> (3rd) Also, there are no more machines whose register size is not a powe=
r
>> of two or which are not two's complement.
>>
>
> A lot of people say things like that, but is there any actual proof of
> that?
>
=E2=80=8BBefore the advent of byte addressable machine power 2 word sizes w=
ere
essentially non-existent. Typically the word size was a multiple of 6
bits. Off the top of my head:
48: Burroughs "Large systems" (B5000 .. B8500)
36: Digital PDP-6 / -10
36: GE 600 (645 =3D Multics)
36: IBM 700 / 7000 series (Lisp: CAR =3D Contents of Address Register, CDR=
=3D
Contents of Data Register)
36: Univac 1100
18: Digital PDP-1 / -4 / -7 (Thompson's original Unix and B) / -9 / -15
12: Digital PDP-5 / -8 / -12
Ubiquitous byte addressing was preceded by a number of machines with 16 bit
words:
Burroughs "Small and medium systems (B1000 .. B4900)
DataGenerl Nova
IBM 1130
many foregotten mini-computers=E2=80=8B
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAJnXXojCYQLnUtp7Autyv698NgpdJVMQu8jN1%3DMP9587%=
2BncwHA%40mail.gmail.com.
--001a11411480bcb0840549127c1c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif"><span style=3D"font-family:arial,sans-serif">On Tue, Fe=
b 21, 2017 at 3:07 PM, Nicol Bolas </span><span dir=3D"ltr" style=3D"font-f=
amily:arial,sans-serif"><<a href=3D"mailto:jmckesson@gmail.com" target=
=3D"_blank">jmckesson@gmail.com</a>></span><span style=3D"font-family:ar=
ial,sans-serif"> wrote:</span><br></div><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><span class=3D"gmail-">On Tuesday, February 21, 2017 at 1:52:22 =
PM UTC-5, <a href=3D"mailto:nib...@gmail.com" target=3D"_blank">nib...@gmai=
l.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><span></span><span>(3rd) Also, there are no more machines whose re=
gister size is=20
not a power of two or which are not two's complement.</span></div></blo=
ckquote></span><div><br>A lot of people say things like that, but is there =
any actual proof of that?</div></div></blockquote><div><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">=E2=80=
=8BBefore the advent of byte addressable machine power 2 word sizes were es=
sentially non-existent.=C2=A0 Typically the word size was a multiple of 6 b=
its.=C2=A0 Off the top of my head:</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif"><br></div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif">48: Burroughs &quo=
t;Large systems" (B5000 .. B8500)</div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif"><br></div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif">36: Digital PDP=
-6 / -10</div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif">36: GE 600 (645 =3D Multics)</div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif">36: IBM 700 / 7000 se=
ries =C2=A0(Lisp: CAR =3D Contents of Address Register, CDR =3D Contents of=
Data Register)</div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif">36: Univac 1100<br></div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif"><br></div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">18: Digita=
l PDP-1 / -4 / -7 (<span style=3D"color:rgb(37,37,37);font-family:sans-seri=
f;font-size:14px">Thompson's original=C2=A0</span>Unix and B) / -9 / -1=
5</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif"><br></div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif">12: Digital PDP-5 / -8 / -12</div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif"><br></div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">Ub=
iquitous byte addressing was preceded by a number of machines with 16 bit w=
ords:<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif"><br></div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif">Burroughs "Small and medium systems (B1=
000 .. B4900)</div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif">DataGenerl Nova</div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif">IBM 1130</div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif">many foregot=
ten mini-computers=E2=80=8B</div><div><br></div></div>
</div></div>
<p></p>
-- <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 <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnXXojCYQLnUtp7Autyv698NgpdJVMQu8jN=
1%3DMP9587%2BncwHA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnXXojCYQLn=
Utp7Autyv698NgpdJVMQu8jN1%3DMP9587%2BncwHA%40mail.gmail.com</a>.<br />
--001a11411480bcb0840549127c1c--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Tue, 21 Feb 2017 15:13:00 -0800 (PST)
Raw View
------=_Part_1516_1099491028.1487718780929
Content-Type: multipart/alternative;
boundary="----=_Part_1517_988310758.1487718780929"
------=_Part_1517_988310758.1487718780929
Content-Type: text/plain; charset=UTF-8
1)
This seems like a function pointer to me, with each state being a function
of like signature.
2)
There have been many proposals in this direction, but none have been passed
so far. There could be many reasons for this, but I would agree that a
solution for this and the problem of knowing if a loop ended by break would
be a nice improvement of control strucures.
3)
I'm pretty sure there aren't any non-power of two machines out there, but
we don't need to go that far, it is enough that there are no such machines
for which a C++ compiler is in active development and would be expected to
upgrade to C++2x or whatever version this could get into. As compiler
vendors have to monitor the standardization process quite closely I'm
pretty sure someone will speak up if they work towards such a target
architecture. I would definitley favor dropping restrictions that have got
to do with non-eight bit bytes, non-twos complement arithmetic and on-IEEE
floats in the standard float and double types. Although I think IBM may
still have hardware with other floats out there IEEE is also supported and
probably already used for the float and double types (although this last
part is speculation).
Den tisdag 21 februari 2017 kl. 21:07:00 UTC+1 skrev Nicol Bolas:
>
>
>
> On Tuesday, February 21, 2017 at 1:52:22 PM UTC-5, nib...@gmail.com wrote:
>>
>> (3rd) Also, there are no more machines whose register size is not a power
>> of two or which are not two's complement.
>>
>
> A lot of people say things like that, but is there any actual proof of
> that?
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ac794e4a-6fa5-4718-8f3f-bc87d539d5f2%40isocpp.org.
------=_Part_1517_988310758.1487718780929
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>1)</div><div>This seems like a function pointer to me=
, with each state being a function of like signature.</div><div><br></div><=
div>2)=C2=A0</div><div>There have been many proposals in this direction, bu=
t none have been passed so far. There could be many reasons for this, but I=
would agree that a solution for this and the problem of knowing if a loop =
ended by break would be a nice improvement of control strucures.</div><div>=
<br></div><div>3)</div>I'm pretty sure there aren't any non-power o=
f two machines out there, but we don't need to go that far, it is enoug=
h that there are no such machines for which a C++ compiler is in active dev=
elopment and would be expected to upgrade to C++2x or whatever version this=
could get into. As compiler vendors have to monitor the standardization pr=
ocess quite closely I'm pretty sure someone will speak up if they work =
towards such a target architecture. I would definitley favor dropping restr=
ictions that have got to do with non-eight bit bytes, non-twos complement a=
rithmetic and on-IEEE floats in the standard float and double types. Althou=
gh I think IBM may still have hardware with other floats out there IEEE is =
also supported and probably already used for the float and double types (al=
though this last part is speculation).<br><br>Den tisdag 21 februari 2017 k=
l. 21:07:00 UTC+1 skrev Nicol Bolas:<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, February 21, 2017 at 1:52:22 PM =
UTC-5, <a>nib...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><span></span><span>(3rd) Also, there are no more machine=
s whose register size is=20
not a power of two or which are not two's complement.</span></div></blo=
ckquote><div><br>A lot of people say things like that, but is there any act=
ual proof of that?</div></div></blockquote></div>
<p></p>
-- <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 <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ac794e4a-6fa5-4718-8f3f-bc87d539d5f2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ac794e4a-6fa5-4718-8f3f-bc87d539d5f2=
%40isocpp.org</a>.<br />
------=_Part_1517_988310758.1487718780929--
------=_Part_1516_1099491028.1487718780929--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 22 Feb 2017 01:18:50 +0200
Raw View
On 22 February 2017 at 01:13, Bengt Gustafsson
<bengt.gustafsson@beamways.com> wrote:
> 3)
> I'm pretty sure there aren't any non-power of two machines out there, but we
Some DSP platforms available today disagree.
> I would definitley favor dropping restrictions that have got to do with
> non-eight bit bytes, non-twos complement arithmetic and on-IEEE floats in
Same here, some DSP platforms available today disagree. Their machine
words are 24 bits.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZDLwZVKE1vh4XZb8cnEOYGhkrpDWY-0LndyvEif6GoDg%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 21 Feb 2017 16:06:02 -0800 (PST)
Raw View
------=_Part_1600_1124823175.1487721962680
Content-Type: multipart/alternative;
boundary="----=_Part_1601_998329521.1487721962680"
------=_Part_1601_998329521.1487721962680
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 21, 2017 at 6:13:01 PM UTC-5, Bengt Gustafsson wrote:
>
> 1)
> This seems like a function pointer to me, with each state being a function
> of like signature.
>
Function pointers are pointers and thus represent a less-than-predictable
branch. It would presumably be easier to optimize this particular case if
the compiler knew at compile time what all of the possible states were and
exactly what code they map to.
In theory.
2)
> There have been many proposals in this direction, but none have been
> passed so far.
>
I don't think any along those lines have gotten to the committee thus far.
The only thing the committee has considered was `for/break/continue`
<http://wg21.link/P0082>, and really the only thing they asked to change
was to make them use actual keywords rather than trying to appropriate
others.
There could be many reasons for this, but I would agree that a solution for
> this and the problem of knowing if a loop ended by break would be a nice
> improvement of control strucures.
>
> 3)
> I'm pretty sure there aren't any non-power of two machines out there, but
> we don't need to go that far, it is enough that there are no such machines
> for which a C++ compiler is in active development and would be expected to
> upgrade to C++2x or whatever version this could get into.
>
[citation needed]
> As compiler vendors have to monitor the standardization process quite
> closely I'm pretty sure someone will speak up if they work towards such a
> target architecture.
>
Which they do. They don't bother talking about it here, though.
I would definitley favor dropping restrictions that have got to do with
> non-eight bit bytes, non-twos complement arithmetic and on-IEEE floats in
> the standard float and double types. Although I think IBM may still have
> hardware with other floats out there IEEE is also supported and probably
> already used for the float and double types (although this last part is
> speculation).
>
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f0b262b9-e69c-4fb5-8ad0-e9c3ccf39b05%40isocpp.org.
------=_Part_1601_998329521.1487721962680
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 21, 2017 at 6:13:01 PM UTC-5, Bengt G=
ustafsson 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"><div>1)</div><div>This seems like a function pointer to me, with each st=
ate being a function of like signature.</div></div></blockquote><div><br>Fu=
nction pointers are pointers and thus represent a less-than-predictable bra=
nch. It would presumably be easier to optimize this particular case if the =
compiler knew at compile time what all of the possible states were and exac=
tly what code they map to.<br><br>In theory.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>2)=C2=A0</div>=
<div>There have been many proposals in this direction, but none have been p=
assed so far.</div></div></blockquote><div><br>I don't think any along =
those lines have gotten to the committee thus far. The only thing the commi=
ttee has considered was <a href=3D"http://wg21.link/P0082">`for/break/conti=
nue`</a>, and really the only thing they asked to change was to make them u=
se actual keywords rather than trying to appropriate others.<br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>There cou=
ld be many reasons for this, but I would agree that a solution for this and=
the problem of knowing if a loop ended by break would be a nice improvemen=
t of control strucures.</div><div><br></div><div>3)</div>I'm pretty sur=
e there aren't any non-power of two machines out there, but we don'=
t need to go that far, it is enough that there are no such machines for whi=
ch a C++ compiler is in active development and would be expected to upgrade=
to C++2x or whatever version this could get into.</div></blockquote><div><=
br>[citation needed]<br>=C2=A0</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">As compiler vendors have to monitor the standardizat=
ion process quite closely I'm pretty sure someone will speak up if they=
work towards such a target architecture.</div></blockquote><div><br>Which =
they do. They don't bother talking about it here, though.<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I would defin=
itley favor dropping restrictions that have got to do with non-eight bit by=
tes, non-twos complement arithmetic and on-IEEE floats in the standard floa=
t and double types. Although I think IBM may still have hardware with other=
floats out there IEEE is also supported and probably already used for the =
float and double types (although this last part is speculation).<br><br></d=
iv></blockquote></div>
<p></p>
-- <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 <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f0b262b9-e69c-4fb5-8ad0-e9c3ccf39b05%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f0b262b9-e69c-4fb5-8ad0-e9c3ccf39b05=
%40isocpp.org</a>.<br />
------=_Part_1601_998329521.1487721962680--
------=_Part_1600_1124823175.1487721962680--
.
Author: Jean-Marc Bourguet <jm.bourguet@gmail.com>
Date: Tue, 21 Feb 2017 23:59:52 -0800 (PST)
Raw View
------=_Part_5328_1188039711.1487750392893
Content-Type: multipart/alternative;
boundary="----=_Part_5329_1961444855.1487750392893"
------=_Part_5329_1961444855.1487750392893
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le mercredi 22 f=C3=A9vrier 2017 00:10:37 UTC+1, John Yates a =C3=A9crit :
>
> On Tue, Feb 21, 2017 at 3:07 PM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
>> On Tuesday, February 21, 2017 at 1:52:22 PM UTC-5, nib...@gmail.com=20
>> wrote:
>>>
>>> (3rd) Also, there are no more machines whose register size is not a=20
>>> power of two or which are not two's complement.
>>>
>>
>> A lot of people say things like that, but is there any actual proof of=
=20
>> that?
>>
>
> =E2=80=8BBefore the advent of byte addressable machine power 2 word sizes=
were=20
> essentially non-existent. Typically the word size was a multiple of 6=20
> bits. Off the top of my head:
>
> 48: Burroughs "Large systems" (B5000 .. B8500)
> 36: Univac 1100
>
>
Unisys was still selling members of those families last time I checked=20
(look for OS2200 and MCP), but they were going the path of emulation for=20
lower end one. I'm not sure they are really relevant for C++ (although=20
they had a C compiler for a one complement word addressable, 36-bit word=20
machine).
I don't think one complement or sign and magnitude will ever make sense=20
again, Non power of two word size and word addressable machine on the other=
=20
hand are still meaningful more more specialized markets (there the only=20
question is if a more specialized machine make sense economically, the=20
answer currently seems to be yes for DSP and no for embedded system, but I=
=20
would not bet against a change in either direction).
Yours,
--=20
Jean-Marc
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/862b254b-6296-4109-a1aa-60863e989e09%40isocpp.or=
g.
------=_Part_5329_1961444855.1487750392893
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le mercredi 22 f=C3=A9vrier 2017 00:10:37 UTC+1, John Yate=
s a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif"><span style=
=3D"font-family:arial,sans-serif">On Tue, Feb 21, 2017 at 3:07 PM, Nicol Bo=
las </span><span dir=3D"ltr" style=3D"font-family:arial,sans-serif"><<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"1PLiY5kUBwA=
J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return=
true;" onclick=3D"this.href=3D'javascript:';return true;">jmck...@=
gmail.com</a>></span><span style=3D"font-family:arial,sans-serif"> wrote=
:</span><br></div><div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><span>On Tuesday, February 21, 20=
17 at 1:52:22 PM UTC-5, <a>nib...@gmail.com</a> wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><span></span><span>(3rd) Also=
, there are no more machines whose register size is=20
not a power of two or which are not two's complement.</span></div></blo=
ckquote></span><div><br>A lot of people say things like that, but is there =
any actual proof of that?</div></div></blockquote><div><br></div><div style=
=3D"font-family:arial,helvetica,sans-serif">=E2=80=8BBefore the advent of b=
yte addressable machine power 2 word sizes were essentially non-existent.=
=C2=A0 Typically the word size was a multiple of 6 bits.=C2=A0 Off the top =
of my head:</div><div style=3D"font-family:arial,helvetica,sans-serif"><br>=
</div><div style=3D"font-family:arial,helvetica,sans-serif">48: Burroughs &=
quot;Large systems" (B5000 .. B8500)</div><div style=3D"font-family:ar=
ial,helvetica,sans-serif">36: Univac 1100<br></div><div style=3D"font-famil=
y:arial,helvetica,sans-serif"><br></div></div></div></div></blockquote><div=
><br></div><div>Unisys was still selling members of those families last tim=
e I checked (look for OS2200 and MCP), but they were going the path of emul=
ation for lower end one. =C2=A0I'm not sure they are really relevant fo=
r C++ (although they had a C compiler for a one complement word addressable=
, 36-bit word machine).</div><div><br></div><div>I don't think one comp=
lement or sign and magnitude will ever make sense again, Non power of two w=
ord size and word addressable machine on the other hand are still meaningfu=
l more more specialized markets (there the only question is if a more speci=
alized machine make sense economically, the answer currently seems to be ye=
s for DSP and no for embedded system, but I would not bet against a change =
in either direction).</div><div><br></div><div>Yours,</div><div><br></div><=
div>--=C2=A0</div><div>Jean-Marc</div></div>
<p></p>
-- <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 <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/862b254b-6296-4109-a1aa-60863e989e09%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/862b254b-6296-4109-a1aa-60863e989e09=
%40isocpp.org</a>.<br />
------=_Part_5329_1961444855.1487750392893--
------=_Part_5328_1188039711.1487750392893--
.