Topic: Why do we include a Matrix and Vector class into
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 09 Jun 2017 07:50:17 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">That Matrix class shouldn't be called Matrix at all=E2=80=8E. I=
t should be called something like Transform or affine_transform. It is bare=
ly a matrix. </div><div style=3D"width: 100%; font-size: initial; font=
-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 1=
25); text-align: initial; background-color: rgb(255, 255, 255);"><br></div>=
<div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate=
Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial=
; background-color: rgb(255, 255, 255);">Vector would be more friendly as '=
point' or 'point2D' etc. </div><div style=3D"width: 100%; font-size: i=
nitial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: r=
gb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);=
"><br></div><div style=3D"width: 100%; font-size: initial; font-family: Cal=
ibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-al=
ign: initial; background-color: rgb(255, 255, 255);">They should all be in =
a sub namespace, not directly in std, so that we can make 'real' matrix and=
vector classes later. </div><div style=3D"width: 100%; font-size: ini=
tial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb=
(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">=
<br></div><div style=3D"width: 100%; font-size: initial; font-family: Calib=
ri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-alig=
n: initial; background-color: rgb(255, 255, 255);">In my opinion. </div> =
=
<div style=3D"width:=
100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, s=
ans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: =
rgb(255, 255, 255);"><br></div> =
=
=
<div style=3D"font-size: initial; font-family: Calibri, 'Slate Pro', sans-=
serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background=
-color: rgb(255, 255, 255);">Sent from my BlackBerry po=
rtable Babbage Device</div> =
=
<table wid=
th=3D"100%" style=3D"background-color:white;border-spacing:0px;"> <tbody><t=
r><td colspan=3D"2" style=3D"font-size: initial; text-align: initial; backg=
round-color: rgb(255, 255, 255);"> <div style=3D"=
border-style: solid none none; border-top-color: rgb(181, 196, 223); border=
-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans'=
, 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>Jakob Riedle=E2=80=8E<=
/div><div><b>Sent: </b>Friday, June 9, 2017 7:15 AM</div><div><b>To: </b>IS=
O C++ Standard - Future Proposals</div><div><b>Reply To: </b>std-proposals@=
isocpp.org</div><div><b>Subject: </b>[std-proposals] Why do we include a Ma=
trix and Vector class into the proposed 2D Graphics Library?</div></div></t=
d></tr></tbody></table><div style=3D"border-style: solid none none; border-=
top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: initial; t=
ext-align: initial; background-color: rgb(255, 255, 255);"></div><br><div i=
d=3D"_originalContent" style=3D""><div dir=3D"ltr">Hello Folks,<div><br></d=
iv><div>concerning <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/p=
apers/2017/p0267r4.pdf">Proposal P0267R1-4</a> (the proposed 2D Graphi=
cs extension):<br><br></div><div>Recently stated the question, whether ther=
e is any interest in something like a matrix/vector/tensor class extension.=
</div><div>The Consensus there was, that because we are confronted with the=
opinions of a bunch of different stakeholders,</div><div>we should first a=
pproach the concept of Matrices from a "conceptional" perspective before we=
even think about a specific implementation.</div><div><br></div><div>That =
means, we should first come up with a set of <i>Concepts </i>that provide i=
nterfaces for the idea of multidimensional Arrays.</div><div><br></div><div=
><br></div><div>Now what is being done in <a href=3D"http://www.open-s=
td.org/jtc1/sc22/wg21/docs/papers/2017/p0267r4.pdf">P0267R1-4</a> is t=
he exact opposite of that:</div><div>Come up with an arbitrary, highly cont=
ext dependent Matrix class that is not reusable for anyone but the few peop=
le that want to work with 2D Graphics.</div><div><br></div><div><br></div><=
div>I have the strong feeling that this is absolutely not desirable from a =
standpoint of standardization:</div><div><b>We want a C++ standard Library =
that is consistent in itself and does not reinvent the wheel for every spec=
ific extension it gets.</b></div><div><br></div><div><br></div><div>Please =
let me know your opinions on this!</div><div><br></div><div>Cheers and have=
a nice weekend,</div><div>Jakob</div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
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/7e3ee19d-f758-4d38-a015-0c474424073d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/7e3ee19d-f758-4d38-a015-0c474424=
073d%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<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/20170609115017.5132345.91153.30981%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20170609115017.5132345.91153.30981%40gm=
ail.com</a>.<br />
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Sat, 10 Jun 2017 09:02:45 -0700 (PDT)
Raw View
------=_Part_1837_1094770179.1497110565946
Content-Type: multipart/alternative;
boundary="----=_Part_1838_926903007.1497110565946"
------=_Part_1838_926903007.1497110565946
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
@Jakob: I had the same feeling when reading this proposal: These types=20
should not be part of a graphics library, but instances of a general=20
vocabulary matrix type. There are a couple of requirements to bring back=20
from the 2D graphics proposal:
- A vector/matrix type must be possible to instantiate with fixed size.
- A 2 element vector should have members named x and y.
To my knowledge the closest to a matrix type that has been formally=20
proposed was the array_view<T, N> template, where N is a rank, so it does=
=20
not support fixed sizes. The performance penalty for the non-fixed size=20
would be quite large for a 3x3 matrix, and in addition there was no=20
accompanying type which provided storage in that proposal. This proposal=20
also suffers from the same problem as the 2D graphics proposal: To index=20
and size the matrix it contains its own 1-d types index<N> and bounds<N>.
What I would like to see is something similar to Eigen, but more modern.=20
Eigen matrices are templated on the x and y size with a special marker=20
value indicating "variable size" in the respective dimensions. As this=20
library predates variadic templates it supports only vectors and=20
2D-matrices. Still, vectors are matrices with 1 row or column.
I argee that a good place to start would be to define some concepts around=
=20
this. It is going to be interesting to see if a Concept can be defined that=
=20
forces an indexing operator() to take as many integer indices as the rank=
=20
of the type under test. Off the top of my head I don't see how to do this,=
=20
but then I'm not an expert on concepts. Maybe I will come back with a=20
writeup on this later on, based on the matrix implementation indicated=20
below.
--------
I have made a matrix template which fulfills these requirements and I was=
=20
contemplating proposing it, but there is still a lot of work to do on this,=
=20
for instance how to create views and slices when the fixed or variable size=
=20
of both the original matrix bounds and the view bounds complicate how the=
=20
indexing calculation is to be optimized.
The other question regards if a vocabulary vector type could have named=20
members x, y, (z, ...). This can be done by specialization and I have given=
=20
this idea a try. I don't like the idea of having to call a function to get=
=20
the indivdual values when the object "feels" like a simple struct. I know=
=20
that there are different opinions on this, and this is mine: Keep it simple=
=20
to do simple things. The problem is that, although it "works" on decent=20
compilers it seems impossible to get named data members and simultaneously=
=20
no-overhead access via an operator[]. Options include an union between=20
scalars and an array and taking the address of x and index off of it, but I=
=20
believe that formally these are both UB. (Correct me if I'm wrong!). To fix=
=20
this we could a) rewrite the rules of unions/struct member placement to=20
make that behaviour defined, introduce "properties" with hidden=20
setters/getters or introduce a member data aliasing ability such as "using=
=20
x =3D _data[0]". Example:
union {
struct {
T x;
T y; // Is this guaranteed to be at the same address as _data[1]?
};
T _data[2];
};
=20
Den fredag 9 juni 2017 kl. 13:50:21 UTC+2 skrev Tony V E:
>
> That Matrix class shouldn't be called Matrix at all=E2=80=8E. It should b=
e called=20
> something like Transform or affine_transform. It is barely a matrix.=20
>
> Vector would be more friendly as 'point' or 'point2D' etc.=20
>
> They should all be in a sub namespace, not directly in std, so that we ca=
n=20
> make 'real' matrix and vector classes later.=20
>
> In my opinion.=20
>
> Sent from my BlackBerry portable Babbage Device
> *From: *Jakob Riedle=E2=80=8E
> *Sent: *Friday, June 9, 2017 7:15 AM
> *To: *ISO C++ Standard - Future Proposals
> *Reply To: *std-pr...@isocpp.org <javascript:>
> *Subject: *[std-proposals] Why do we include a Matrix and Vector class=20
> into the proposed 2D Graphics Library?
>
> Hello Folks,
>
> concerning Proposal P0267R1-4=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0267r4.pdf> (th=
e=20
> proposed 2D Graphics extension):
>
> Recently stated the question, whether there is any interest in something=
=20
> like a matrix/vector/tensor class extension.
> The Consensus there was, that because we are confronted with the opinions=
=20
> of a bunch of different stakeholders,
> we should first approach the concept of Matrices from a "conceptional"=20
> perspective before we even think about a specific implementation.
>
> That means, we should first come up with a set of *Concepts *that provide=
=20
> interfaces for the idea of multidimensional Arrays.
>
>
> Now what is being done in P0267R1-4=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0267r4.pdf> is=
=20
> the exact opposite of that:
> Come up with an arbitrary, highly context dependent Matrix class that is=
=20
> not reusable for anyone but the few people that want to work with 2D=20
> Graphics.
>
>
> I have the strong feeling that this is absolutely not desirable from a=20
> standpoint of standardization:
> *We want a C++ standard Library that is consistent in itself and does not=
=20
> reinvent the wheel for every specific extension it gets.*
>
>
> Please let me know your opinions on this!
>
> Cheers and have a nice weekend,
> Jakob
>
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7e3ee19d-f75=
8-4d38-a015-0c474424073d%40isocpp.org=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7e3ee19d-f7=
58-4d38-a015-0c474424073d%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
>
--=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/b53ee06e-9284-4e82-ab16-6f732ee8e18f%40isocpp.or=
g.
------=_Part_1838_926903007.1497110565946
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">@Jakob: I had the same feeling when reading this proposal:=
These types should not be part of a graphics library, but instances of a g=
eneral vocabulary matrix type. There are a couple of requirements to bring =
back from the 2D graphics proposal:<div><br></div><div>- A vector/matrix ty=
pe must be possible to instantiate with fixed size.</div><div>- A 2 element=
vector should have members named x and y.</div><div><br></div><div>To my k=
nowledge the closest to a matrix type that has been formally proposed was t=
he array_view<T, N> template, where N is a rank, so it does not suppo=
rt fixed sizes. The performance penalty for the non-fixed size would be qui=
te large for a 3x3 matrix, and in addition there was no accompanying type w=
hich provided storage in that proposal. This proposal also suffers from the=
same problem as the 2D graphics proposal: To index and size the matrix it =
contains its own 1-d types index<N> and bounds<N>.</div><div><b=
r></div><div>What I would like to see is something similar to Eigen, but mo=
re modern. Eigen matrices are templated on the x and y size with a special =
marker value indicating "variable size" in the respective dimensi=
ons. As this library predates variadic templates it supports only vectors a=
nd 2D-matrices. Still, vectors are matrices with 1 row or column.</div><div=
><br></div><div>I argee that a good place to start would be to define some =
concepts around this. It is going to be interesting to see if a Concept can=
be defined that forces an indexing operator() to take as many integer indi=
ces as the rank of the type under test. Off the top of my head I don't =
see how to do this, but then I'm not an expert on concepts. Maybe I wil=
l come back with a writeup on this later on, based on the matrix implementa=
tion indicated below.<br></div><div><br></div><div><br></div><div>--------<=
/div><div><br></div><div><br></div><div>I have made a matrix template which=
fulfills these requirements and I was contemplating proposing it, but ther=
e is still a lot of work to do on this, for instance how to create views an=
d slices when the fixed or variable size of both the original matrix bounds=
and the view bounds complicate how the indexing calculation is to be optim=
ized.<br></div><div><br></div><div>The other question regards if a vocabula=
ry vector type could have named members x, y, (z, ...). This can be done by=
specialization and I have given this idea a try. I don't like the idea=
of having to call a function to get the indivdual values when the object &=
quot;feels" like a simple struct. I know that there are different opin=
ions on this, and this is mine: Keep it simple to do simple things. The pro=
blem is that, although it "works" on decent compilers it seems im=
possible to get named data members and simultaneously no-overhead access vi=
a an operator[]. Options include an union between scalars and an array and =
taking the address of x and index off of it, but I believe that formally th=
ese are both UB. (Correct me if I'm wrong!). To fix this we could a) re=
write the rules of unions/struct member placement to make that behaviour de=
fined, introduce "properties" with hidden setters/getters or intr=
oduce a member data aliasing ability such as "using x =3D _data[0]&quo=
t;. Example:</div><div><br></div><div>union {</div><div>=C2=A0 =C2=A0 struc=
t {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 T x;</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 T y; =C2=A0 // Is this guaranteed to be at the same address as _=
data[1]?</div><div>=C2=A0 =C2=A0 };</div><div>=C2=A0 =C2=A0 T _data[2];</di=
v><div>};</div><div><br></div><div><br></div><div>=C2=A0 =C2=A0=C2=A0</div>=
<div><br></div><div><br></div><div><br></div><div><br><div><div><br><br>Den=
fredag 9 juni 2017 kl. 13:50:21 UTC+2 skrev Tony V E:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div lang=3D"en-US" style=3D"background-color:rgb(2=
55,255,255);line-height:initial"> =
<div style=3D"width:100%;font-s=
ize:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;c=
olor:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">T=
hat Matrix class shouldn't be called Matrix at all=E2=80=8E. It should =
be called something like Transform or affine_transform. It is barely a matr=
ix.=C2=A0</div><div style=3D"width:100%;font-size:initial;font-family:Calib=
ri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-alig=
n:initial;background-color:rgb(255,255,255)"><br></div><div style=3D"width:=
100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,s=
ans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,=
255,255)">Vector would be more friendly as 'point' or 'point2D&=
#39; etc.=C2=A0</div><div style=3D"width:100%;font-size:initial;font-family=
:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);tex=
t-align:initial;background-color:rgb(255,255,255)"><br></div><div style=3D"=
width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-s=
erif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rg=
b(255,255,255)">They should all be in a sub namespace, not directly in std,=
so that we can make 'real' matrix and vector classes later.=C2=A0<=
/div><div style=3D"width:100%;font-size:initial;font-family:Calibri,'Sl=
ate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;=
background-color:rgb(255,255,255)"><br></div><div style=3D"width:100%;font-=
size:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;=
color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">=
In my opinion. </div> =
=
<div style=3D"width:100%;font-size:initial;font-family:Calibri,'Sla=
te Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;b=
ackground-color:rgb(255,255,255)"><br></div> =
=
=
<div style=3D"font-size:initial;font-family:Calibri,'Slat=
e Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;ba=
ckground-color:rgb(255,255,255)">Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=
=A0<wbr>portable=C2=A0Babbage=C2=A0Device</div> =
=
=
<table width=3D"100%" style=3D"background-color:white;border-spacing:0px"> =
<tbody><tr><td colspan=3D"2" style=3D"font-size:initial;text-align:initial;=
background-color:rgb(255,255,255)"> <div style=3D=
"border-style:solid none none;border-top-color:rgb(181,196,223);border-top-=
width:1pt;padding:3pt 0in 0in;font-family:Tahoma,'BB Alpha Sans',&#=
39;Slate Pro';font-size:10pt"> <div><b>From: </b>Jakob Riedle=E2=80=8E=
</div><div><b>Sent: </b>Friday, June 9, 2017 7:15 AM</div><div><b>To: </b>I=
SO C++ Standard - Future Proposals</div><div><b>Reply To: </b><a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"1jLLbL-AAQAJ" rel=3D"=
nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" on=
click=3D"this.href=3D'javascript:';return true;">std-pr...@isocpp.o=
rg</a></div><div><b>Subject: </b>[std-proposals] Why do we include a Matrix=
and Vector class into the proposed 2D Graphics Library?</div></div></td></=
tr></tbody></table><div style=3D"border-style:solid none none;border-top-co=
lor:rgb(186,188,209);border-top-width:1pt;font-size:initial;text-align:init=
ial;background-color:rgb(255,255,255)"></div><br><div><div dir=3D"ltr">Hell=
o Folks,<div><br></div><div>concerning <a href=3D"http://www.open-std.org/j=
tc1/sc22/wg21/docs/papers/2017/p0267r4.pdf" target=3D"_blank" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%=
2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0267r4=
..pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH-bLhwk2ni5YB8cOCf9DK8LH9FNw&#=
39;;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x=
3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017=
%2Fp0267r4.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH-bLhwk2ni5YB8cOCf9D=
K8LH9FNw';return true;">Proposal P0267R1-4</a>=C2=A0(the proposed 2D Gr=
aphics extension):<br><br></div><div>Recently stated the question, whether =
there is any interest in something like a matrix/vector/tensor class extens=
ion.</div><div>The Consensus there was, that because we are confronted with=
the opinions of a bunch of different stakeholders,</div><div>we should fir=
st approach the concept of Matrices from a "conceptional" perspec=
tive before we even think about a specific implementation.</div><div><br></=
div><div>That means, we should first come up with a set of <i>Concepts </i>=
that provide interfaces for the idea of multidimensional Arrays.</div><div>=
<br></div><div><br></div><div>Now what is being done in=C2=A0<a href=3D"htt=
p://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0267r4.pdf" target=3D=
"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google=
..com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fp=
apers%2F2017%2Fp0267r4.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH-bLhwk2=
ni5YB8cOCf9DK8LH9FNw';return true;" onclick=3D"this.href=3D'http://=
www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%=
2Fdocs%2Fpapers%2F2017%2Fp0267r4.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQj=
CNH-bLhwk2ni5YB8cOCf9DK8LH9FNw';return true;">P0267R1-4</a>=C2=A0is the=
exact opposite of that:</div><div>Come up with an arbitrary, highly contex=
t dependent Matrix class that is not reusable for anyone but the few people=
that want to work with 2D Graphics.</div><div><br></div><div><br></div><di=
v>I have the strong feeling that this is absolutely not desirable from a st=
andpoint of standardization:</div><div><b>We want a C++ standard Library th=
at is consistent in itself and does not reinvent the wheel for every specif=
ic extension it gets.</b></div><div><br></div><div><br></div><div>Please le=
t me know your opinions on this!</div><div><br></div><div>Cheers and have a=
nice weekend,</div><div>Jakob</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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
1jLLbL-AAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"1jLLbL-AAQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/7e3ee19d-f758-4d38-a015-0c474424073d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/7e3ee19d-f758-4d38-a015-0c474424073d%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/7e3ee19d-f758-4d38-a015-0c474424073d%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/7e3ee19d-f758-4d38-<wbr>a015-=
0c474424073d%40isocpp.org</a><wbr>.<br>
<br></div></div>
</blockquote></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/b53ee06e-9284-4e82-ab16-6f732ee8e18f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b53ee06e-9284-4e82-ab16-6f732ee8e18f=
%40isocpp.org</a>.<br />
------=_Part_1838_926903007.1497110565946--
------=_Part_1837_1094770179.1497110565946--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 10 Jun 2017 09:58:13 -0700 (PDT)
Raw View
------=_Part_1927_2091321540.1497113893514
Content-Type: multipart/alternative;
boundary="----=_Part_1928_1094216784.1497113893514"
------=_Part_1928_1094216784.1497113893514
Content-Type: text/plain; charset="UTF-8"
On Saturday, June 10, 2017 at 12:02:46 PM UTC-4, Bengt Gustafsson wrote:
>
> @Jakob: I had the same feeling when reading this proposal: These types
> should not be part of a graphics library, but instances of a general
> vocabulary matrix type. There are a couple of requirements to bring back
> from the 2D graphics proposal:
>
> - A vector/matrix type must be possible to instantiate with fixed size.
> - A 2 element vector should have members named x and y.
>
The problem with all this is that, from the perspective of the graphics
library, generalizing these things is essentially irrelevant and pointless.
Sure, it makes those types more useful for other things, but it doesn't
make them more useful for the graphics library.
Having to get a full-fledged vector/matrix library through the committee is
a lot harder than just saying, "here's a few types that exist for a narrow
purpose". You'd essentially be delaying the standardization of the graphics
library for things that have nothing to do with graphics.
Now granted, I don't think the graphics library should be standardized *at
all*, but if it's going to happen, I'd rather not see it delayed due to
issues that are tangential to that library's needs.
The only generic issues I think need to be accounted for is the ability to
transform these types into `span`s (and therefore defining them explicitly
to contain arrays). But that's contingent on standardizing `span` itself.
--
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/d7d0213d-9706-49ac-b322-6013fabefd3a%40isocpp.org.
------=_Part_1928_1094216784.1497113893514
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, June 10, 2017 at 12:02:46 PM UTC-4, Bengt Gus=
tafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>@Jakob: I had the same feeling when reading this proposal: These types sho=
uld not be part of a graphics library, but instances of a general vocabular=
y matrix type. There are a couple of requirements to bring back from the 2D=
graphics proposal:<div><br></div><div>- A vector/matrix type must be possi=
ble to instantiate with fixed size.</div><div>- A 2 element vector should h=
ave members named x and y.</div></div></blockquote><div><br>The problem wit=
h all this is that, from the perspective of the graphics library, generaliz=
ing these things is essentially irrelevant and pointless. Sure, it makes th=
ose types more useful for other things, but it doesn't make them more u=
seful for the graphics library.<br><br>Having to get a full-fledged vector/=
matrix library through the committee is a lot harder than just saying, &quo=
t;here's a few types that exist for a narrow purpose". You'd e=
ssentially be delaying the standardization of the graphics library for thin=
gs that have nothing to do with graphics.<br><br>Now granted, I don't t=
hink the graphics library should be standardized <i>at all</i>, but if it&#=
39;s going to happen, I'd rather not see it delayed due to issues that =
are tangential to that library's needs.<br><br>The only generic issues =
I think need to be accounted for is the ability to transform these types in=
to `span`s (and therefore defining them explicitly to contain arrays). But =
that's contingent on standardizing `span` itself.</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/d7d0213d-9706-49ac-b322-6013fabefd3a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d7d0213d-9706-49ac-b322-6013fabefd3a=
%40isocpp.org</a>.<br />
------=_Part_1928_1094216784.1497113893514--
------=_Part_1927_2091321540.1497113893514--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Sat, 10 Jun 2017 11:42:21 -0700 (PDT)
Raw View
------=_Part_2020_32189902.1497120141813
Content-Type: multipart/alternative;
boundary="----=_Part_2021_264905610.1497120141813"
------=_Part_2021_264905610.1497120141813
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Here I think you are totally wrong. A lack of common vocabulary types is in=
=20
my view a major deterrant from using C++. By providing vocabulary types=20
like a (mathematical) vector and matrix we offer the possibility
for third party library vendors to create libraries that can be used=20
together seamlessly. If C++ had come with a more complete set of vocabulary=
=20
types long ago we wouldn't have had CString, QString and wxString nor would=
=20
we have QPoint, wxPoint, eigen::vector2i, osg::vec2d all with the same=20
contents but incompatible. This would have been very helpful to us who use=
=20
lots of third part libraries to perform complex tasks.
So on this point I say: Better late than never.
As for the graphics2d library I agree that it is too tangential to be=20
standardized but vectors and matrices (preferrably as one n-dimensional=20
template class) are not. With it third party libraries for 2D graphics, 3D=
=20
graphics, data analysis, image processing, and what not can be used=20
together with less pain, reducing the need to standardize the libraries=20
themselves (possibly with separate sets of such vocabulary types).
Den l=C3=B6rdag 10 juni 2017 kl. 18:58:13 UTC+2 skrev Nicol Bolas:
>
> On Saturday, June 10, 2017 at 12:02:46 PM UTC-4, Bengt Gustafsson wrote:
>>
>> @Jakob: I had the same feeling when reading this proposal: These types=
=20
>> should not be part of a graphics library, but instances of a general=20
>> vocabulary matrix type. There are a couple of requirements to bring back=
=20
>> from the 2D graphics proposal:
>>
>> - A vector/matrix type must be possible to instantiate with fixed size.
>> - A 2 element vector should have members named x and y.
>>
>
> The problem with all this is that, from the perspective of the graphics=
=20
> library, generalizing these things is essentially irrelevant and pointles=
s.=20
> Sure, it makes those types more useful for other things, but it doesn't=
=20
> make them more useful for the graphics library.
>
> Having to get a full-fledged vector/matrix library through the committee=
=20
> is a lot harder than just saying, "here's a few types that exist for a=20
> narrow purpose". You'd essentially be delaying the standardization of the=
=20
> graphics library for things that have nothing to do with graphics.
>
> Now granted, I don't think the graphics library should be standardized *a=
t=20
> all*, but if it's going to happen, I'd rather not see it delayed due to=
=20
> issues that are tangential to that library's needs.
>
> The only generic issues I think need to be accounted for is the ability t=
o=20
> transform these types into `span`s (and therefore defining them explicitl=
y=20
> to contain arrays). But that's contingent on standardizing `span` itself.
>
--=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/d71c480f-bcd2-4051-9f92-523e3e6fc563%40isocpp.or=
g.
------=_Part_2021_264905610.1497120141813
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Here I think you are totally wrong. A lack of common vocab=
ulary types is in my view a major deterrant from using C++. By providing vo=
cabulary types like a (mathematical) vector and matrix we offer the possibi=
lity<div>for third party library vendors to create libraries that can be us=
ed together seamlessly. If C++ had come with a more complete set of vocabul=
ary types long ago we wouldn't have had CString, QString and wxString n=
or would we have QPoint, wxPoint, eigen::vector2i, osg::vec2d all with the =
same contents but incompatible. This would have been very helpful to us who=
use lots of third part libraries to perform complex tasks.</div><div><br><=
/div><div>So on this point I say: Better late than never.</div><div><br></d=
iv><div>As for the graphics2d library I agree that it is too tangential to =
be standardized but vectors and matrices (preferrably as one n-dimensional =
template class) are not. With it third party libraries for 2D graphics, 3D =
graphics, data analysis, image processing, and what not can be used togethe=
r with less pain, reducing the need to standardize the libraries themselves=
(possibly with separate sets of such vocabulary types).<br><div><br><br>De=
n l=C3=B6rdag 10 juni 2017 kl. 18:58:13 UTC+2 skrev Nicol Bolas:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Saturday, June 10, 20=
17 at 12:02:46 PM UTC-4, Bengt Gustafsson wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr">@Jakob: I had the same feeling when reading t=
his proposal: These types should not be part of a graphics library, but ins=
tances of a general vocabulary matrix type. There are a couple of requireme=
nts to bring back from the 2D graphics proposal:<div><br></div><div>- A vec=
tor/matrix type must be possible to instantiate with fixed size.</div><div>=
- A 2 element vector should have members named x and y.</div></div></blockq=
uote><div><br>The problem with all this is that, from the perspective of th=
e graphics library, generalizing these things is essentially irrelevant and=
pointless. Sure, it makes those types more useful for other things, but it=
doesn't make them more useful for the graphics library.<br><br>Having =
to get a full-fledged vector/matrix library through the committee is a lot =
harder than just saying, "here's a few types that exist for a narr=
ow purpose". You'd essentially be delaying the standardization of =
the graphics library for things that have nothing to do with graphics.<br><=
br>Now granted, I don't think the graphics library should be standardiz=
ed <i>at all</i>, but if it's going to happen, I'd rather not see i=
t delayed due to issues that are tangential to that library's needs.<br=
><br>The only generic issues I think need to be accounted for is the abilit=
y to transform these types into `span`s (and therefore defining them explic=
itly to contain arrays). But that's contingent on standardizing `span` =
itself.</div></div></blockquote></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/d71c480f-bcd2-4051-9f92-523e3e6fc563%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d71c480f-bcd2-4051-9f92-523e3e6fc563=
%40isocpp.org</a>.<br />
------=_Part_2021_264905610.1497120141813--
------=_Part_2020_32189902.1497120141813--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sat, 10 Jun 2017 15:31:34 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">I don't think there is a disagreement here. We have</div><div s=
tyle=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro',=
sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; back=
ground-color: rgb(255, 255, 255);">1. (Nicol) General vector and matrix sho=
uld not (or need not) be done within the graphics library</div><div style=
=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', san=
s-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgrou=
nd-color: rgb(255, 255, 255);">2. (you)=E2=80=8E General vector and matrix =
is more important than the graphics library </div><div style=3D"width:=
100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, s=
ans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: =
rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: initia=
l; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31=
, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">OK,=
so someone needs to propose a general matrix and vector library. </di=
v><div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Sla=
te Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initi=
al; background-color: rgb(255, 255, 255);">And that can be looked at separa=
tely from the graphics library. </div><div style=3D"width: 100%; font-=
size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; c=
olor: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255=
, 255);">LEWG might even prioritize it over the graphics library, or, more =
likely, LEWG will look at both in due process. </div><div style=3D"wid=
th: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif=
, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-colo=
r: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: ini=
tial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb=
(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">=
If you are trying to say"'the author(s) of the graphics library should inst=
ead spend their time on general matrix and vector", well you are free to su=
ggest that to them, but we are all volunteers - people tend to work on what=
they feel is important, not what others think is important (rightly or wro=
ngly).</div><div style=3D"width: 100%; font-size: initial; font-family: Cal=
ibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-al=
ign: initial; background-color: rgb(255, 255, 255);"><br></div><div style=
=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', san=
s-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgrou=
nd-color: rgb(255, 255, 255);">Tony</div><div style=3D"width: 100%; font-si=
ze: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; col=
or: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, =
255);"><br></div> =
=
<div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate=
Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial=
; background-color: rgb(255, 255, 255);"><br style=3D"display:initial"></di=
v> =
=
<div style=3D"font-size: ini=
tial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb=
(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">=
Sent from my BlackBerry portable Babbage Devi=
ce</div> =
=
<table width=3D"100%" style=3D"backgrou=
nd-color:white;border-spacing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"=
font-size: initial; text-align: initial; background-color: rgb(255, 255, 25=
5);"> <div style=3D"border-style: solid none none=
; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt=
0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10p=
t;"> <div><b>From: </b>Bengt Gustafsson</div><div><b>Sent: </b>Saturday, J=
une 10, 2017 2:42 PM</div><div><b>To: </b>ISO C++ Standard - Future Proposa=
ls</div><div><b>Reply To: </b>std-proposals@isocpp.org</div><div><b>Subject=
: </b>Re: [std-proposals] Why do we include a Matrix and Vector class into =
the proposed 2D Graphics Library?</div></div></td></tr></tbody></table><div=
style=3D"border-style: solid none none; border-top-color: rgb(186, 188, 20=
9); border-top-width: 1pt; font-size: initial; text-align: initial; backgro=
und-color: rgb(255, 255, 255);"></div><br><div id=3D"_originalContent" styl=
e=3D""><div dir=3D"ltr">Here I think you are totally wrong. A lack of commo=
n vocabulary types is in my view a major deterrant from using C++. By provi=
ding vocabulary types like a (mathematical) vector and matrix we offer the =
possibility<div>for third party library vendors to create libraries that ca=
n be used together seamlessly. If C++ had come with a more complete set of =
vocabulary types long ago we wouldn't have had CString, QString and wxStrin=
g nor would we have QPoint, wxPoint, eigen::vector2i, osg::vec2d all with t=
he same contents but incompatible. This would have been very helpful to us =
who use lots of third part libraries to perform complex tasks.</div><div><b=
r></div><div>So on this point I say: Better late than never.</div><div><br>=
</div><div>As for the graphics2d library I agree that it is too tangential =
to be standardized but vectors and matrices (preferrably as one n-dimension=
al template class) are not. With it third party libraries for 2D graphics, =
3D graphics, data analysis, image processing, and what not can be used toge=
ther with less pain, reducing the need to standardize the libraries themsel=
ves (possibly with separate sets of such vocabulary types).<br><div><br><br=
>Den l=C3=B6rdag 10 juni 2017 kl. 18:58:13 UTC+2 skrev Nicol Bolas:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Saturday, June 10,=
2017 at 12:02:46 PM UTC-4, Bengt Gustafsson wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">@Jakob: I had the same feeling when readin=
g this proposal: These types should not be part of a graphics library, but =
instances of a general vocabulary matrix type. There are a couple of requir=
ements to bring back from the 2D graphics proposal:<div><br></div><div>- A =
vector/matrix type must be possible to instantiate with fixed size.</div><d=
iv>- A 2 element vector should have members named x and y.</div></div></blo=
ckquote><div><br>The problem with all this is that, from the perspective of=
the graphics library, generalizing these things is essentially irrelevant =
and pointless. Sure, it makes those types more useful for other things, but=
it doesn't make them more useful for the graphics library.<br><br>Having t=
o get a full-fledged vector/matrix library through the committee is a lot h=
arder than just saying, "here's a few types that exist for a narrow purpose=
". You'd essentially be delaying the standardization of the graphics librar=
y for things that have nothing to do with graphics.<br><br>Now granted, I d=
on't think the graphics library should be standardized <i>at all</i>, but i=
f it's going to happen, I'd rather not see it delayed due to issues that ar=
e tangential to that library's needs.<br><br>The only generic issues I thin=
k need to be accounted for is the ability to transform these types into `sp=
an`s (and therefore defining them explicitly to contain arrays). But that's=
contingent on standardizing `span` itself.</div></div></blockquote></div><=
/div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
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/d71c480f-bcd2-4051-9f92-523e3e6fc563%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/d71c480f-bcd2-4051-9f92-523e3e6f=
c563%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<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/20170610193134.5132345.14750.31022%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20170610193134.5132345.14750.31022%40gm=
ail.com</a>.<br />
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 10 Jun 2017 18:06:46 -0700 (PDT)
Raw View
------=_Part_2102_1286784886.1497143206988
Content-Type: multipart/alternative;
boundary="----=_Part_2103_1652608300.1497143206988"
------=_Part_2103_1652608300.1497143206988
Content-Type: text/plain; charset="UTF-8"
On Saturday, June 10, 2017 at 2:42:21 PM UTC-4, Bengt Gustafsson wrote:
>
> Here I think you are totally wrong. A lack of common vocabulary types is
> in my view a major deterrant from using C++. By providing vocabulary types
> like a (mathematical) vector and matrix we offer the possibility
> for third party library vendors to create libraries that can be used
> together seamlessly. If C++ had come with a more complete set of vocabulary
> types long ago we wouldn't have had CString, QString and wxString
>
C++98 had std::string. That stopped precisely *nobody* from making those
other string types. C++ users have proven that having a "vocabulary type"
will stop nobody from making their own. No matter how good that type is,
"not invented here" syndrome is strong among us.
That's not to say that we shouldn't have good types. It's just that we
shouldn't expect that having good types will prevent people from writing
their own.
nor would we have QPoint, wxPoint, eigen::vector2i, osg::vec2d all with the
> same contents but incompatible. This would have been very helpful to us who
> use lots of third part libraries to perform complex tasks.
>
> So on this point I say: Better late than never.
>
Mandatory XKCD <https://xkcd.com/927/>. Being late never helps.
Giving standard C++ a good 2D vector type will not cause all of those types
to vanish, nor will it cause users of those types to adopt them. Giving C++
a good Unicode string type will not stop people from rolling their own.
Yes, that doesn't mean we shouldn't have them. But we need to have
realistic expectations of the *results* of such things.
--
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/d574cde2-6023-4dea-9cc2-5004f4b50493%40isocpp.org.
------=_Part_2103_1652608300.1497143206988
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, June 10, 2017 at 2:42:21 PM UTC-4, Bengt Gust=
afsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
Here I think you are totally wrong. A lack of common vocabulary types is in=
my view a major deterrant from using C++. By providing vocabulary types li=
ke a (mathematical) vector and matrix we offer the possibility<div>for thir=
d party library vendors to create libraries that can be used together seaml=
essly. If C++ had come with a more complete set of vocabulary types long ag=
o we wouldn't have had CString, QString and wxString</div></div></block=
quote><div><br>C++98 had std::string. That stopped precisely <i>nobody</i> =
from making those other string types. C++ users have proven that having a &=
quot;vocabulary type" will stop nobody from making their own. No matte=
r how good that type is, "not invented here" syndrome is strong a=
mong us.<br><br>That's not to say that we shouldn't have good types=
.. It's just that we shouldn't expect that having good types will pr=
event people from writing their own.<br><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div>nor would we have QPoint, wxPoint=
, eigen::vector2i, osg::vec2d all with the same contents but incompatible. =
This would have been very helpful to us who use lots of third part librarie=
s to perform complex tasks.</div><div><br></div><div>So on this point I say=
: Better late than never.</div></div></blockquote><div><br>Mandatory <a hre=
f=3D"https://xkcd.com/927/">XKCD</a>. Being late never helps.<br><br>Giving=
standard C++ a good 2D vector type will not cause all of those types to va=
nish, nor will it cause users of those types to adopt them. Giving C++ a go=
od Unicode string type will not stop people from rolling their own.<br><br>=
Yes, that doesn't mean we shouldn't have them. But we need to have =
realistic expectations of the <i>results</i> of such things.</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/d574cde2-6023-4dea-9cc2-5004f4b50493%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d574cde2-6023-4dea-9cc2-5004f4b50493=
%40isocpp.org</a>.<br />
------=_Part_2103_1652608300.1497143206988--
------=_Part_2102_1286784886.1497143206988--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sun, 11 Jun 2017 21:15:45 -0700 (PDT)
Raw View
------=_Part_401_1960331645.1497240945150
Content-Type: multipart/alternative;
boundary="----=_Part_402_297090396.1497240945150"
------=_Part_402_297090396.1497240945150
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2017=E5=B9=B46=E6=9C=8811=E6=97=A5=E6=98=9F=E6=9C=9F=E6=97=A5 UTC=
+8=E4=B8=8A=E5=8D=889:06:47=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Saturday, June 10, 2017 at 2:42:21 PM UTC-4, Bengt Gustafsson wrote:
>>
>> Here I think you are totally wrong. A lack of common vocabulary types is=
=20
>> in my view a major deterrant from using C++. By providing vocabulary typ=
es=20
>> like a (mathematical) vector and matrix we offer the possibility
>> for third party library vendors to create libraries that can be used=20
>> together seamlessly. If C++ had come with a more complete set of vocabul=
ary=20
>> types long ago we wouldn't have had CString, QString and wxString
>>
>
> C++98 had std::string. That stopped precisely *nobody* from making those=
=20
> other string types. C++ users have proven that having a "vocabulary type"=
=20
> will stop nobody from making their own. No matter how good that type is,=
=20
> "not invented here" syndrome is strong among us.
>
> That's not to say that we shouldn't have good types. It's just that we=20
> shouldn't expect that having good types will prevent people from writing=
=20
> their own.
>
> The type std::string is not provided as a "vocabulary type" at first. It=
=20
is an instance of std::basic_string. It is already *abused* for a long time=
=20
where it is merely expected as a vocabulary type, e.g. in initializing=20
objects of standard exception classes. That can be hard to fix in reality=
=20
due to ABI compatibility, etc. So, be cautious to introduce new ones,=20
whatever good enough or not. (BTW, std::string is not good enough for many=
=20
reasons, but most of them come from std::basic_string, which is not=20
relevant here.)
nor would we have QPoint, wxPoint, eigen::vector2i, osg::vec2d all with the=
=20
>> same contents but incompatible. This would have been very helpful to us =
who=20
>> use lots of third part libraries to perform complex tasks.
>>
>> So on this point I say: Better late than never.
>>
>
> Mandatory XKCD=20
> <https://www.google.com/url?q=3Dhttps%3A%2F%2Fxkcd.com%2F927%2F&sa=3DD&sn=
tz=3D1&usg=3DAFQjCNHutHG3HTO1LGoS6qbLOY2PCPCtmw>.=20
> Being late never helps.
>
> At least, less troubles to regret, before being widespread.
Giving standard C++ a good 2D vector type will not cause all of those types=
=20
> to vanish, nor will it cause users of those types to adopt them. Giving C=
++=20
> a good Unicode string type will not stop people from rolling their own.
>
> Yes, that doesn't mean we shouldn't have them. But we need to have=20
> realistic expectations of the *results* of such things.
>
You still can't guarantee you will have them. In the case of graphics=20
library, such "vocabulary types" are essentially out of the scope. And it=
=20
can be more difficult to make them "good" as strings, giving users more=20
excuses to reinvent the wheel.
Instead of preventing NIH by adding mandatory types, specify requirements=
=20
of those types may be more appropriate (except for potential code bloat).
--=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/d504efc3-845f-4983-842c-1ca37fc650a8%40isocpp.or=
g.
------=_Part_402_297090396.1497240945150
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B46=E6=9C=8811=E6=97=A5=E6=98=
=9F=E6=9C=9F=E6=97=A5 UTC+8=E4=B8=8A=E5=8D=889:06:47=EF=BC=8CNicol Bolas=E5=
=86=99=E9=81=93=EF=BC=9A<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">On Saturday, June 10, 2017 at 2:42:21 PM UTC-4, Bengt Gustafsson=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Here I thin=
k you are totally wrong. A lack of common vocabulary types is in my view a =
major deterrant from using C++. By providing vocabulary types like a (mathe=
matical) vector and matrix we offer the possibility<div>for third party lib=
rary vendors to create libraries that can be used together seamlessly. If C=
++ had come with a more complete set of vocabulary types long ago we wouldn=
't have had CString, QString and wxString</div></div></blockquote><div>=
<br>C++98 had std::string. That stopped precisely <i>nobody</i> from making=
those other string types. C++ users have proven that having a "vocabu=
lary type" will stop nobody from making their own. No matter how good =
that type is, "not invented here" syndrome is strong among us.<br=
><br>That's not to say that we shouldn't have good types. It's =
just that we shouldn't expect that having good types will prevent peopl=
e from writing their own.<br><br></div></div></blockquote><div>The type std=
::string is not provided as a "vocabulary type" at first. It is a=
n instance of std::basic_string. It is already <i>abused</i> for a long tim=
e where it is merely expected as a vocabulary type, e.g. in initializing ob=
jects of standard exception classes. That can be hard to fix in reality due=
to ABI compatibility, etc. So, be cautious to introduce new ones, whatever=
good enough or not. (BTW, std::string is not good enough for many reasons,=
but most of them come from std::basic_string, which is not relevant here.)=
<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div>nor would we have QPoint, wxPoint, eigen::vector2i, osg::vec2d al=
l with the same contents but incompatible. This would have been very helpfu=
l to us who use lots of third part libraries to perform complex tasks.</div=
><div><br></div><div>So on this point I say: Better late than never.</div><=
/div></blockquote><div><br>Mandatory <a href=3D"https://www.google.com/url?=
q=3Dhttps%3A%2F%2Fxkcd.com%2F927%2F&sa=3DD&sntz=3D1&usg=3DAFQjC=
NHutHG3HTO1LGoS6qbLOY2PCPCtmw" target=3D"_blank" rel=3D"nofollow" onmousedo=
wn=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fxkcd.c=
om%2F927%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHutHG3HTO1LGoS6qbLOY2PC=
PCtmw';return true;" onclick=3D"this.href=3D'https://www.google.com=
/url?q\x3dhttps%3A%2F%2Fxkcd.com%2F927%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNHutHG3HTO1LGoS6qbLOY2PCPCtmw';return true;">XKCD</a>. Being late=
never helps.<br><br></div></div></blockquote><div>At least, less troubles =
to regret, before being widespread.</div><div> <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>Giving standard C++ a goo=
d 2D vector type will not cause all of those types to vanish, nor will it c=
ause users of those types to adopt them. Giving C++ a good Unicode string t=
ype will not stop people from rolling their own.<br><br>Yes, that doesn'=
;t mean we shouldn't have them. But we need to have realistic expectati=
ons of the <i>results</i> of such things.</div></div></blockquote><div><br>=
</div><div>You still can't guarantee you will have them. In the case of=
graphics library, such "vocabulary types" are essentially out of=
the scope. And it can be more difficult to make them "good" as s=
trings, giving users more excuses to reinvent the wheel.<br></div><div><br>=
</div><div>Instead of preventing NIH by adding mandatory types, specify req=
uirements of those types may be more appropriate (except for potential code=
bloat).<br></div><div> <br></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/d504efc3-845f-4983-842c-1ca37fc650a8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d504efc3-845f-4983-842c-1ca37fc650a8=
%40isocpp.org</a>.<br />
------=_Part_402_297090396.1497240945150--
------=_Part_401_1960331645.1497240945150--
.
Author: Dejan Milosavljevic <dmilos@gmail.com>
Date: Mon, 12 Jun 2017 10:54:52 +0200
Raw View
--001a11443e6ee5faf70551bf789d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
This may be considered as off topic!
> OK, so someone needs to propose a general matrix and vector library.
He is one possible vector definition:
namespace std::_space_to_be_named_
{
template< class T, std::size_t N>
using vector =3D std::array<T,N>; // Fixed length vector
}
This has to be combined with strong typedefs ( when they arrive ), and
additional requirements for T ( concepts ).
For matrix things are similar. First we need appropriate container(s) and
then typedef(s) in same manner.
On Sat, Jun 10, 2017 at 9:31 PM, Tony V E <tvaneerd@gmail.com> wrote:
> I don't think there is a disagreement here. We have
> 1. (Nicol) General vector and matrix should not (or need not) be done
> within the graphics library
> 2. (you)=E2=80=8E General vector and matrix is more important than the gr=
aphics
> library
>
> OK, so someone needs to propose a general matrix and vector library.
> And that can be looked at separately from the graphics library.
> LEWG might even prioritize it over the graphics library, or, more likely,
> LEWG will look at both in due process.
>
> If you are trying to say"'the author(s) of the graphics library should
> instead spend their time on general matrix and vector", well you are free
> to suggest that to them, but we are all volunteers - people tend to work =
on
> what they feel is important, not what others think is important (rightly =
or
> wrongly).
>
> Tony
>
>
> Sent from my BlackBerry portable Babbage Device
> *From: *Bengt Gustafsson
> *Sent: *Saturday, June 10, 2017 2:42 PM
> *To: *ISO C++ Standard - Future Proposals
> *Reply To: *std-proposals@isocpp.org
> *Subject: *Re: [std-proposals] Why do we include a Matrix and Vector
> class into the proposed 2D Graphics Library?
>
> Here I think you are totally wrong. A lack of common vocabulary types is
> in my view a major deterrant from using C++. By providing vocabulary type=
s
> like a (mathematical) vector and matrix we offer the possibility
> for third party library vendors to create libraries that can be used
> together seamlessly. If C++ had come with a more complete set of vocabula=
ry
> types long ago we wouldn't have had CString, QString and wxString nor wou=
ld
> we have QPoint, wxPoint, eigen::vector2i, osg::vec2d all with the same
> contents but incompatible. This would have been very helpful to us who us=
e
> lots of third part libraries to perform complex tasks.
>
> So on this point I say: Better late than never.
>
> As for the graphics2d library I agree that it is too tangential to be
> standardized but vectors and matrices (preferrably as one n-dimensional
> template class) are not. With it third party libraries for 2D graphics, 3=
D
> graphics, data analysis, image processing, and what not can be used
> together with less pain, reducing the need to standardize the libraries
> themselves (possibly with separate sets of such vocabulary types).
>
>
> Den l=C3=B6rdag 10 juni 2017 kl. 18:58:13 UTC+2 skrev Nicol Bolas:
>>
>> On Saturday, June 10, 2017 at 12:02:46 PM UTC-4, Bengt Gustafsson wrote:
>>>
>>> @Jakob: I had the same feeling when reading this proposal: These types
>>> should not be part of a graphics library, but instances of a general
>>> vocabulary matrix type. There are a couple of requirements to bring bac=
k
>>> from the 2D graphics proposal:
>>>
>>> - A vector/matrix type must be possible to instantiate with fixed size.
>>> - A 2 element vector should have members named x and y.
>>>
>>
>> The problem with all this is that, from the perspective of the graphics
>> library, generalizing these things is essentially irrelevant and pointle=
ss.
>> Sure, it makes those types more useful for other things, but it doesn't
>> make them more useful for the graphics library.
>>
>> Having to get a full-fledged vector/matrix library through the committee
>> is a lot harder than just saying, "here's a few types that exist for a
>> narrow purpose". You'd essentially be delaying the standardization of th=
e
>> graphics library for things that have nothing to do with graphics.
>>
>> Now granted, I don't think the graphics library should be standardized *=
at
>> all*, but if it's going to happen, I'd rather not see it delayed due to
>> issues that are tangential to that library's needs.
>>
>> The only generic issues I think need to be accounted for is the ability
>> to transform these types into `span`s (and therefore defining them
>> explicitly to contain arrays). But that's contingent on standardizing
>> `span` itself.
>>
> --
> 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/d71c480f-bcd2-4051-
> 9f92-523e3e6fc563%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d71c480f-bc=
d2-4051-9f92-523e3e6fc563%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
> --
> 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/20170610193134.
> 5132345.14750.31022%40gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20170610193=
134.5132345.14750.31022%40gmail.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>
--=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/CAEfefmwFwB3AoeGmGTCrvMTWxt7rF7V_2ZOwVpy6DVEUQOK=
1ig%40mail.gmail.com.
--001a11443e6ee5faf70551bf789d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>This may be considered as off topic!</div><div><br></=
div><div>> OK, so someone needs to propose a general matrix and vector l=
ibrary.</div><div><br></div><div>He is one possible vector definition: </di=
v><div><br>=C2=A0namespace std::_space_to_be_named_</div><div>=C2=A0 {</div=
><div>=C2=A0=C2=A0=C2=A0 template< class T,=C2=A0 std::size_t N></div=
><div>=C2=A0=C2=A0=C2=A0=C2=A0 using vector =3D std::array<T,N>; // F=
ixed length vector</div><div>=C2=A0 }</div><div><br></div><div>This has to =
be combined with strong typedefs ( when they arrive ), and additional requi=
rements for T ( concepts ).</div><div><br></div><div>For matrix things are =
similar. First we need appropriate container(s) and then typedef(s) in same=
manner. </div><div><span><br></span></div></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Sat, Jun 10, 2017 at 9:31 PM, Tony V E <=
span dir=3D"ltr"><<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank=
">tvaneerd@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div lang=3D"en-US" style=3D"background-color:rgb(255,255,255)"> =
=
<div style=3D"width:100%;color:rgb(31,73,125);font-family:Calibri,"S=
late Pro",sans-serif,sans-serif;background-color:rgb(255,255,255)">I d=
on't think there is a disagreement here. We have</div><div style=3D"wid=
th:100%;color:rgb(31,73,125);font-family:Calibri,"Slate Pro",sans=
-serif,sans-serif;background-color:rgb(255,255,255)">1. (Nicol) General vec=
tor and matrix should not (or need not) be done within the graphics library=
</div><div style=3D"width:100%;color:rgb(31,73,125);font-family:Calibri,&qu=
ot;Slate Pro",sans-serif,sans-serif;background-color:rgb(255,255,255)"=
>2. (you)=E2=80=8E General vector and matrix is more important than the gra=
phics library=C2=A0</div><div style=3D"width:100%;color:rgb(31,73,125);font=
-family:Calibri,"Slate Pro",sans-serif,sans-serif;background-colo=
r:rgb(255,255,255)"><br></div><div style=3D"width:100%;color:rgb(31,73,125)=
;font-family:Calibri,"Slate Pro",sans-serif,sans-serif;background=
-color:rgb(255,255,255)">OK, so someone needs to propose a general matrix a=
nd vector library.=C2=A0</div><div style=3D"width:100%;color:rgb(31,73,125)=
;font-family:Calibri,"Slate Pro",sans-serif,sans-serif;background=
-color:rgb(255,255,255)">And that can be looked at separately from the grap=
hics library.=C2=A0</div><div style=3D"width:100%;color:rgb(31,73,125);font=
-family:Calibri,"Slate Pro",sans-serif,sans-serif;background-colo=
r:rgb(255,255,255)">LEWG might even prioritize it over the graphics library=
, or, more likely, LEWG will look at both in due process.=C2=A0</div><div s=
tyle=3D"width:100%;color:rgb(31,73,125);font-family:Calibri,"Slate Pro=
",sans-serif,sans-serif;background-color:rgb(255,255,255)"><br></div><=
div style=3D"width:100%;color:rgb(31,73,125);font-family:Calibri,"Slat=
e Pro",sans-serif,sans-serif;background-color:rgb(255,255,255)">If you=
are trying to say"'the author(s) of the graphics library should i=
nstead spend their time on general matrix and vector", well you are fr=
ee to suggest that to them, but we are all volunteers - people tend to work=
on what they feel is important, not what others think is important (rightl=
y or wrongly).</div><div style=3D"width:100%;color:rgb(31,73,125);font-fami=
ly:Calibri,"Slate Pro",sans-serif,sans-serif;background-color:rgb=
(255,255,255)"><br></div><div style=3D"width:100%;color:rgb(31,73,125);font=
-family:Calibri,"Slate Pro",sans-serif,sans-serif;background-colo=
r:rgb(255,255,255)">Tony</div><span><div style=3D"width:100%;color:rgb(31,7=
3,125);font-family:Calibri,"Slate Pro",sans-serif,sans-serif;back=
ground-color:rgb(255,255,255)"><br></div> =
=
<div style=3D"width:100%;color:rgb(31,73,125);font-=
family:Calibri,"Slate Pro",sans-serif,sans-serif;background-color=
:rgb(255,255,255)"><br></div> =
=
<=
div style=3D"color:rgb(31,73,125);font-family:Calibri,"Slate Pro"=
,sans-serif,sans-serif;background-color:rgb(255,255,255)">Sent=C2=A0from=C2=
=A0my=C2=A0BlackBerry=C2=A0<wbr>portable=C2=A0Babbage=C2=A0Device</div> =
=
=
</span><table width=3D"100%" style=3D"border-spacin=
g:0px;background-color:white"> <tbody><tr><td style=3D"background-color:rgb=
(255,255,255)" colspan=3D"2"> <div style=3D"borde=
r-style:solid none none;padding:3pt 0in 0in;font-family:Tahoma,"BB Alp=
ha Sans","Slate Pro";font-size:10pt;border-top-color:rgb(181=
,196,223);border-top-width:1pt"> <div><b>From: </b>Bengt Gustafsson</div><=
div><b>Sent: </b>Saturday, June 10, 2017 2:42 PM</div><div><b>To: </b>ISO C=
++ Standard - Future Proposals</div><div><b>Reply To: </b><a href=3D"mailto=
:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a></=
div><div><b>Subject: </b>Re: [std-proposals] Why do we include a Matrix and=
Vector class into the proposed 2D Graphics Library?</div></div></td></tr><=
/tbody></table><div><div class=3D"h5"><div style=3D"border-style:solid none=
none;border-top-color:rgb(186,188,209);border-top-width:1pt;background-col=
or:rgb(255,255,255)"></div><br><div id=3D"m_3830463018342283576_originalCon=
tent"><div dir=3D"ltr">Here I think you are totally wrong. A lack of common=
vocabulary types is in my view a major deterrant from using C++. By provid=
ing vocabulary types like a (mathematical) vector and matrix we offer the p=
ossibility<div>for third party library vendors to create libraries that can=
be used together seamlessly. If C++ had come with a more complete set of v=
ocabulary types long ago we wouldn't have had CString, QString and wxSt=
ring nor would we have QPoint, wxPoint, eigen::vector2i, osg::vec2d all wit=
h the same contents but incompatible. This would have been very helpful to =
us who use lots of third part libraries to perform complex tasks.</div><div=
><br></div><div>So on this point I say: Better late than never.</div><div><=
br></div><div>As for the graphics2d library I agree that it is too tangenti=
al to be standardized but vectors and matrices (preferrably as one n-dimens=
ional template class) are not. With it third party libraries for 2D graphic=
s, 3D graphics, data analysis, image processing, and what not can be used t=
ogether with less pain, reducing the need to standardize the libraries them=
selves (possibly with separate sets of such vocabulary types).<br><div><br>=
<br>Den l=C3=B6rdag 10 juni 2017 kl. 18:58:13 UTC+2 skrev Nicol Bolas:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left=
:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-s=
tyle:solid"><div dir=3D"ltr">On Saturday, June 10, 2017 at 12:02:46 PM UTC-=
4, Bengt Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bord=
er-left-width:1px;border-left-style:solid"><div dir=3D"ltr">@Jakob: I had t=
he same feeling when reading this proposal: These types should not be part =
of a graphics library, but instances of a general vocabulary matrix type. T=
here are a couple of requirements to bring back from the 2D graphics propos=
al:<div><br></div><div>- A vector/matrix type must be possible to instantia=
te with fixed size.</div><div>- A 2 element vector should have members name=
d x and y.</div></div></blockquote><div><br>The problem with all this is th=
at, from the perspective of the graphics library, generalizing these things=
is essentially irrelevant and pointless. Sure, it makes those types more u=
seful for other things, but it doesn't make them more useful for the gr=
aphics library.<br><br>Having to get a full-fledged vector/matrix library t=
hrough the committee is a lot harder than just saying, "here's a f=
ew types that exist for a narrow purpose". You'd essentially be de=
laying the standardization of the graphics library for things that have not=
hing to do with graphics.<br><br>Now granted, I don't think the graphic=
s library should be standardized <i>at all</i>, but if it's going to ha=
ppen, I'd rather not see it delayed due to issues that are tangential t=
o that library's needs.<br><br>The only generic issues I think need to =
be accounted for is the ability to transform these types into `span`s (and =
therefore defining them explicitly to contain arrays). But that's conti=
ngent on standardizing `span` itself.</div></div></blockquote></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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/d71c480f-bcd2-4051-9f92-523e3e6fc563%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/d71c=
480f-bcd2-4051-<wbr>9f92-523e3e6fc563%40isocpp.org</a><wbr>.<br>
<br></div></div></div></div><div><div class=3D"h5">
<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20170610193134.5132345.14750.31022%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">htt=
ps://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/2017061=
0193134.<wbr>5132345.14750.31022%40gmail.<wbr>com</a>.<br>
</blockquote></div><br></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/CAEfefmwFwB3AoeGmGTCrvMTWxt7rF7V_2ZOw=
Vpy6DVEUQOK1ig%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmwFwB3AoeGm=
GTCrvMTWxt7rF7V_2ZOwVpy6DVEUQOK1ig%40mail.gmail.com</a>.<br />
--001a11443e6ee5faf70551bf789d--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Mon, 12 Jun 2017 04:57:33 -0700 (PDT)
Raw View
------=_Part_2958_1475293883.1497268653794
Content-Type: multipart/alternative;
boundary="----=_Part_2959_2008572411.1497268653795"
------=_Part_2959_2008572411.1497268653795
Content-Type: text/plain; charset="UTF-8"
First of all, thank you for all the feedback on this!
I think we can identify consensus on the following problem statement:
- *Including something like matrix_2d, vector_2d into the Standard (that
is within the namespace std::io2d::*) as proposed by the Graphics 2D
Library Extension is rather undesirable.*
The solution to this problem however has many variations:
1. *Rename **matrix_2d* *to something like **affine_transform **and *
*vector_2d** to something like **point_2d**.*
*Advantages:* Graphics 2D LE (Library Extension) is not withheld to be
standardized, at least not in the discussed sence. Whether it should be
standardized at all is not in scope of this thread.
*Disadvantages:* In case a general purpose Matrix/Vector Library should
be adpoted at later time,
we have a significant amount of redundancy between modules. This of
course is only the case, given that the general purpose matrix/vector
Library
is expected to represent a strikt superset in functionality of what
matrix_2d and vector_2d offer. I think we can expect the latter.
2.
*Leave them in the namespace std::io2d::* and deprecate them when the
'real' matrix/vector types arrive. *I don't think 2D Graphics is that
important that we need to introduce this amount of redundancy even if only
for a limited amount of time (just IMHO).
*Advantages:* We can standardize Graphics 2D as it is (surely only
concerning the contents discussed in this thread).
*Disadvantages: *We need to deprecate and rewrite also all the methods
that now depend upon those types. This is alot of work and a lot of "spam"
in future C++ Standard Drafts.
This also encourages people to use those types. Users should not begin
to use something that is expected to deprecate in the next major revision
of the standard.
3. *Restrict the Graphics 2D LE to the functionality that doesn't depend
on those types.*
Especially vector_2d is tighly coupled with many algorithms and data
structures presented in the proposal. I don't think this makes sence.
*Disadvantages:* Nothing to reasonably standardize...
4. *Restrict the Graphics 2D LE to the functionality that doesn't depend
on matrix_2d.*
Now that could potentially work, but we would need a universal
(algebraic) vector functionality first. *vector_2d is not universal
enough.*
[Note start --
We could potentially resurrect std::valarray for that since it has
pretty similar semantics on its operators. We could give it a purpose again
;-)
We would have to equip it with .x, .y, and .z members and optional fixed
size dimensions. Potential Way to do that:
std::valarray<int> /* becomes shorthand for */ std::valarray<int[]> //
Note implicit/dynamic extent
std::valarray<int[3]> // is a fixed-size valarray
std::valarray<int[3][3]> // could be disallowed by now. Extendable in
the future to be a matrix and so on...
Then we could standardize e.g.
template<typename T>
using point2d = std::valarray<T[2]>;
template<typename T>
using point3d = std::valarray<T[3]>;
-- Note end]
*Advantages: *The 2D Graphics Library can be standardized in the parts
that don't depend upon matrix_2d.
Providing a (algebraic) vector functionality is easier than specifying a
whole matrix library, but
*Disadvantages:* we need to keep open the option to extend this vector
class to matrixes (and tensors?). That also means, only a part of the
Graphics 2D LE can be standardized by now.
5. *Come up with a Matrix/Vector Extension first*
*Advantages: *Consistency at least across modules of the Standard
Library!
*Disadvantages:* This takes time and probably delays the 2D Graphics
Extension significantly.
6.
*Templatize the Graphics Library to use arbitrary
vector_2d/wsPoint/eigen::vector2i/osg::vec2d as long as they provide .x and
.y Templatize the Graphics Library to use arbitrary
matrix_2d/eigen::matrix2i/... with the array_ref (P0009r3
<http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0009r3.html>)
proposal Disadvantages: *Probably a lot of code bloat within the
library? Maybe we want to encourage people to use the C++ standard
vocabular in favor of their own invented wheels, that is something like a
future std::algebraic::matrix/std::algebraic::vector.
*Advantages: *We delay the problem of having to provide a vocabulary
matrix/vector type to a point in time where we can handle it. Graphics 2D
can therefore be partially standardized.
What do you think? Do you want to add something?
I'm personally ok with 5, 6 and 4 (in order of decreasing preference).
Jakob
--
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/4f11ca6c-d24c-4c56-8297-bdbbbc45a517%40isocpp.org.
------=_Part_2959_2008572411.1497268653795
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">First of all, thank you for all the feedback on this!<div>=
<br></div><div>I think we can identify consensus on the following problem s=
tatement:</div><div><ul><li><b>Including something like matrix_2d, vector_2=
d into the Standard (that is within the namespace std::io2d::*) as proposed=
by the Graphics 2D Library Extension is rather undesirable.</b></li></ul>T=
he solution to this problem however has many variations:</div><div><ol><li>=
<b>Rename </b><i style=3D"font-weight: bold;">matrix_2d</i> <b>to something=
like </b><i style=3D"font-weight: bold;">affine_transform </i><b>and </b><=
i style=3D"font-weight: bold;">vector_2d</i><b> to something like </b><i st=
yle=3D"font-weight: bold;">point_2d</i><b>.</b><br><b>Advantages:</b> Graph=
ics 2D LE (Library Extension) is not withheld to be standardized, at least =
not in the discussed sence. Whether it should be standardized at all is not=
in scope of this thread.<br><b>Disadvantages:</b> In case a general purpos=
e Matrix/Vector Library should be adpoted at later time,<br>we have a signi=
ficant amount of redundancy between modules. This of course is only the cas=
e, given that the general purpose matrix/vector Library<br>is expected to r=
epresent a strikt superset in functionality of what matrix_2d and vector_2d=
offer. I think we can expect the latter.<br><br></li><li><b>Leave them in =
the namespace std::io2d::* and deprecate them when the 'real' matri=
x/vector types arrive.<br></b>I don't think 2D Graphics is that importa=
nt that we need to introduce this amount of redundancy even if only for a l=
imited amount of time (just IMHO).<br><b>Advantages:</b> We can standardize=
Graphics 2D as it is (surely only concerning the contents discussed in thi=
s thread).<br><b>Disadvantages: </b>We need to deprecate and rewrite also a=
ll the methods that now depend upon those types. This is alot of work and a=
lot of "spam" in future C++ Standard Drafts.<br>This also encour=
ages people to use those types. Users should not begin to use something tha=
t is expected to deprecate in the next major revision of the standard.<br><=
br></li><li><b>Restrict the Graphics 2D LE to the functionality that doesn&=
#39;t depend on those types.</b><br>Especially vector_2d is tighly coupled =
with many algorithms and data structures presented in the proposal. I don&#=
39;t think this makes sence.<br><b>Disadvantages:</b> Nothing to reasonably=
standardize...<br><br></li><li><b>Restrict the Graphics 2D LE to the funct=
ionality that doesn't depend on matrix_2d.</b><br>Now that could potent=
ially work, but we would need a universal (algebraic) vector functionality =
first. <i>vector_2d is not universal enough.</i><br>[Note start --<br>We co=
uld potentially resurrect std::valarray for that since it has pretty simila=
r semantics on its operators. We could give it a purpose again ;-)<br>We wo=
uld have to equip it with .x, .y, and .z members and optional fixed size di=
mensions. Potential Way to do that:<br><div class=3D"prettyprint" style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">valarray</span><span style=3D"color: #080;" class=3D"styled-by-=
prettify"><int></span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">/* becomes shorthand for */</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">valarray</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[]></sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">// Note implicit/dynami=
c extent</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">valarray</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">3</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">]></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">// is a fixed-size valarray</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>std</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">valarray</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">[</span><span style=3D"color: #066;" class=3D"styled-by-prettify">3</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">][</span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">3</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">]></span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">// could be disallowed by now. Extendable =
in the future to be a matrix and so on...</span></div></code></div>Then we =
could standardize e.g.<br><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled=
-by-prettify">template</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">using</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> point2d </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">valarray</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify"><</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">[</span><span style=3D"color: #066;" class=3D"styled-by-pre=
ttify">2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]&=
gt;;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">template</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span></div></code><span clas=
s=3D"styled-by-prettify" style=3D"font-family: monospace; color: rgb(0, 0, =
136);">using</span><span class=3D"styled-by-prettify" style=3D"font-family:=
monospace; color: rgb(0, 0, 0);">=C2=A0point3d=C2=A0</span><span class=3D"=
styled-by-prettify" style=3D"font-family: monospace; color: rgb(102, 102, 0=
);">=3D</span><span class=3D"styled-by-prettify" style=3D"font-family: mono=
space; color: rgb(0, 0, 0);">=C2=A0std</span><span class=3D"styled-by-prett=
ify" style=3D"font-family: monospace; color: rgb(102, 102, 0);">::</span><s=
pan class=3D"styled-by-prettify" style=3D"font-family: monospace; color: rg=
b(0, 0, 0);">valarray</span><span class=3D"styled-by-prettify" style=3D"fon=
t-family: monospace; color: rgb(102, 102, 0);"><</span><span class=3D"st=
yled-by-prettify" style=3D"font-family: monospace; color: rgb(0, 0, 0);">T<=
/span><span class=3D"styled-by-prettify" style=3D"font-family: monospace; c=
olor: rgb(102, 102, 0);">[</span><span class=3D"styled-by-prettify" style=
=3D"font-family: monospace; color: rgb(0, 102, 102);">3</span><span class=
=3D"styled-by-prettify" style=3D"font-family: monospace; color: rgb(102, 10=
2, 0);">]>;</span></div>-- Note end]<br><b>Advantages:=C2=A0</b>The 2D G=
raphics Library can be standardized in the parts that don't depend upon=
matrix_2d.<br>Providing a (algebraic)=C2=A0vector functionality is easier =
than specifying a whole matrix library, but=C2=A0<br><b>Disadvantages:</b>=
=C2=A0we need to keep open the option to extend this vector class to matrix=
es (and tensors?). That also means, only a part of the Graphics 2D LE can b=
e standardized by now.<br><br></li><li><b>Come up with a Matrix/Vector Exte=
nsion first</b><br><b>Advantages: </b>Consistency at least across modules o=
f the Standard Library!<br><b>Disadvantages:</b> This takes time and probab=
ly delays the 2D Graphics Extension significantly.<br><br></li><li><b>Templ=
atize the Graphics Library to use arbitrary vector_2d/wsPoint/eigen::vector=
2i/osg::vec2d as long as they provide .x and .y<br>Templatize the Graphics =
Library to use arbitrary matrix_2d/eigen::matrix2i/... with the array_ref (=
<a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0009r3.html=
">P0009r3</a>) proposal<br>Disadvantages: </b>Probably a lot of code bloat =
within the library? Maybe we want to encourage people to use the C++ standa=
rd vocabular in favor of their own invented wheels, that is something like =
a future std::algebraic::matrix/std::algebraic::vector.<br><b>Advantages: <=
/b>We delay the problem of having to provide a vocabulary matrix/vector typ=
e to a point in time where we can handle it. Graphics 2D can therefore be p=
artially standardized.</li></ol></div><div>What do you think? Do you want t=
o add something?</div><div>I'm personally ok with 5, 6 and 4 (in order =
of decreasing preference).</div><div><br></div><div>Jakob</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/4f11ca6c-d24c-4c56-8297-bdbbbc45a517%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4f11ca6c-d24c-4c56-8297-bdbbbc45a517=
%40isocpp.org</a>.<br />
------=_Part_2959_2008572411.1497268653795--
------=_Part_2958_1475293883.1497268653794--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 12 Jun 2017 08:59:39 -0700
Raw View
On Monday, 12 June 2017 01:54:52 PDT Dejan Milosavljevic wrote:
> He is one possible vector definition:
>
> namespace std::_space_to_be_named_
> {
> template< class T, std::size_t N>
> using vector = std::array<T,N>; // Fixed length vector
> }
>
> This has to be combined with strong typedefs ( when they arrive ), and
> additional requirements for T ( concepts ).
>
> For matrix things are similar. First we need appropriate container(s) and
> then typedef(s) in same manner.
Where is operator+ for this type going to be defined?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/2818656.ZnHkfKFBaa%40tjmaciei-mobl1.
.
Author: Dejan Milosavljevic <dmilos@gmail.com>
Date: Mon, 12 Jun 2017 22:22:31 +0200
Raw View
--94eb2c12cac81fc3f80551c91412
Content-Type: text/plain; charset="UTF-8"
> Where is operator+ for this type going to be defined?
Global name space. 'string operator+ (const string& lhs, const string&
rhs);' is situated in it.
But this question is for library designers.
My point is: reuse exiting ( or add new if necessary ) containers and make
vector/matrix to be strong typedefs.
On Mon, Jun 12, 2017 at 5:59 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> On Monday, 12 June 2017 01:54:52 PDT Dejan Milosavljevic wrote:
> > He is one possible vector definition:
> >
> > namespace std::_space_to_be_named_
> > {
> > template< class T, std::size_t N>
> > using vector = std::array<T,N>; // Fixed length vector
> > }
> >
> > This has to be combined with strong typedefs ( when they arrive ), and
> > additional requirements for T ( concepts ).
> >
> > For matrix things are similar. First we need appropriate container(s) and
> > then typedef(s) in same manner.
>
> Where is operator+ for this type going to be defined?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>
> --
> 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/2818656.ZnHkfKFBaa%40tjmaciei-mobl1.
>
--
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/CAEfefmxzKZ1cnOneTm5Fekje2c%2BWthrbUQkpLrVJ_hJ%3DkUCP0Q%40mail.gmail.com.
--94eb2c12cac81fc3f80551c91412
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>> Where is operator+ for this type going to be def=
ined?</div><div>Global name space. 'string operator+ (const string&=
lhs, const string& rhs);' is situated in it.</div><div>But this qu=
estion is for library designers.</div><div><br></div><div><div>My point is:=
reuse exiting ( or add new if necessary ) containers and make vector/matri=
x=C2=A0to be=C2=A0strong typedefs.</div></div></div><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote">On Mon, Jun 12, 2017 at 5:59 PM, Thiago =
Macieira <span dir=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" targe=
t=3D"_blank">thiago@macieira.org</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span>On Monday, 12 June 2017 01:54:52 PDT Dejan Milosavljevi=
c wrote:<br>
> He is one possible vector definition:<br>
><br>
>=C2=A0 namespace std::_space_to_be_named_<br>
>=C2=A0 =C2=A0{<br>
>=C2=A0 =C2=A0 =C2=A0template< class T,=C2=A0 std::size_t N><br>
>=C2=A0 =C2=A0 =C2=A0 using vector =3D std::array<T,N>; // Fixed l=
ength vector<br>
>=C2=A0 =C2=A0}<br>
><br>
> This has to be combined with strong typedefs ( when they arrive ), and=
<br>
> additional requirements for T ( concepts ).<br>
><br>
> For matrix things are similar. First we need appropriate container(s) =
and<br>
> then typedef(s) in same manner.<br>
<br>
</span>Where is operator+ for this type going to be defined?<br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank" rel=3D"noreferrer">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" target=3D"_blank" rel=3D"noreferrer">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<span><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 <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/2818656.ZnHkfKFBaa%40tjmaciei-=
mobl1" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/2818656.ZnHkfKFBaa%<wbr>40tjmaciei-=
mobl1</a>.<br>
</blockquote></div><br></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/CAEfefmxzKZ1cnOneTm5Fekje2c%2BWthrbUQ=
kpLrVJ_hJ%3DkUCP0Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmxzKZ1c=
nOneTm5Fekje2c%2BWthrbUQkpLrVJ_hJ%3DkUCP0Q%40mail.gmail.com</a>.<br />
--94eb2c12cac81fc3f80551c91412--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 12 Jun 2017 14:01:30 -0700
Raw View
On Monday, 12 June 2017 13:22:31 PDT Dejan Milosavljevic wrote:
> Global name space. 'string operator+ (const string& lhs, const string&
> rhs);' is situated in it.
> But this question is for library designers.
>
> My point is: reuse exiting ( or add new if necessary ) containers and make
> vector/matrix to be strong typedefs.
Well, we don't have strong typedefs.
I also don't think it should be a typedef. I think it needs to be a concrete
class that provides extra members. For example, a 2D vector should have
members .x() and .y(). Compare:
auto x = v.x();
auto y = v.y();
some_other_lib_function(x, y, ...);
versus:
auto x = v[0];
auto y = v[1];
some_other_lib_function(x, y, ...);
The second case hardcodes that the x coordinate must come first. It may seem
sensible to you, but there were systems in the past that had a y,x order (the
same way that RGB and BGR exist) and it could make sense for the
implementation to be compatible with that.
Another reason is hardware acceleration: a 3D vector could have 4 elements
instead of 3 and just keep one unused. It also facilitates interoperation with
a 4D vector. See [1] for an example of just such a class.
[1] https://codereview.qt-project.org/#/c/190477/1/src/core/transforms/
vector3d_sse_p.h
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/2590723.WdiGE7MqsV%40tjmaciei-mobl1.
.
Author: Vishal Oza <vickoza@gmail.com>
Date: Mon, 12 Jun 2017 19:47:41 -0700 (PDT)
Raw View
------=_Part_3641_1136902530.1497322061672
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I would like to add another point this discussion.
I think we need 2d-vectors and 2d-matrix classes because they simplifies th=
e mathematical operations involved with 2d graphics. While we rename the 2d=
-vector as a point, I think this could lead novice users to add 2 point tog=
ether and get a new point but the mathematical geometry doesn't make sense.=
This should not replace 2d graphics APIs unlike the stream libraries, but =
rather a starting point for new C++ user to program 2d and 3d graphics.
--=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/18ddebc6-e2d8-4465-aa15-8b81493444ef%40isocpp.or=
g.
------=_Part_3641_1136902530.1497322061672--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Tue, 13 Jun 2017 00:57:44 -0700 (PDT)
Raw View
------=_Part_1253_2093923040.1497340664405
Content-Type: multipart/alternative;
boundary="----=_Part_1254_1619542491.1497340664406"
------=_Part_1254_1619542491.1497340664406
Content-Type: text/plain; charset="UTF-8"
Vishal Oza:
> I would like to add another point this discussion.
> I think we need 2d-vectors and 2d-matrix classes because they simplifies
> the mathematical operations involved with 2d graphics.
Yes, this is part of the problem that we face here.
While we rename the 2d-vector as a point, I think this could lead novice
> users to add 2 point together and get a new point but the mathematical
> geometry doesn't make sense.
So do you think renaming vector_2d to point_2d is a bad thing? Please
explain yourself a little more in detail, you are depending on a few
allusions that you don't explicite. Please do so.
> This should not replace 2d graphics APIs unlike the stream libraries, but
> rather a starting point for new C++ user to program 2d and 3d graphics.
Sorry, what has graphics 2D to do with stream libraries, what analogy do
you allude to?
Dejan Milosavljevic:
> This may be considered as off topic!
>
Thiago Macieira:
> Where is operator+ for this type going to be defined?
Yes, I would consider this as off topic... Your part of the conversation
is not relevant to what we should do w.r.t issue "Graphics 2D Library
Extension".
[Note: I'm not saying it is irrelevant in general]
*For me, this thread is about coming up with a set of opinions and
conclusions on what should be done with the discussed part of the Graphics
2D Proposal**,*
*NOT to primarily discuss how a Matrix/Vector Library should be implemented
(for now at least!).*
My Approach is, to first mail the outcomes in this thread to the proposers
of the Graphics 2D LE.
If this is not enough, I will try to write a proposal that suggests to
rethink the Graphics 2D LE.
What I would like to know is, what solution you would prefer of the ones I
proposed 5 messages ago.
Cheers,
Jakob
PS: I know, people - including me - tend to get very creative with the
discussions in a particular thread and hence start proposing many Ideas on
how we could extend C++ in this and that way,
rather than focusing only on the topic discussed in a particular thread.
In this case, I invite you to do the latter.
--
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/89116eeb-c58b-4158-aa52-05735b21f9f5%40isocpp.org.
------=_Part_1254_1619542491.1497340664406
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><span class=3D"_username" style=3D"white-space: =
nowrap;"><span class=3D"IVILX2C-D-a g-hovercard" data-userid=3D"10761222026=
4588323565" data-name=3D"Vishal Oza">Vishal Oza:</span></span><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-l=
eft: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I would like to add =
another point this discussion.<br>I think we need 2d-vectors and 2d-matrix =
classes because they simplifies the mathematical operations involved with 2=
d graphics.</blockquote><div>Yes, this is part of the problem that we face =
here.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-lef=
t: 1ex;">While we rename the 2d-vector as a point, I think this could lead =
novice users to add 2 point together and get a new point but the mathematic=
al geometry doesn't make sense.</blockquote><div>So do you think renami=
ng vector_2d to point_2d is a bad thing? Please explain yourself a little m=
ore in detail, you are depending on a few allusions that you don't expl=
icite. Please do so.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, =
204); padding-left: 1ex;">This should not replace 2d graphics APIs unlike t=
he stream libraries, but rather a starting point for new C++ user to progra=
m 2d and 3d graphics.</blockquote><div>Sorry, what has graphics 2D to do wi=
th stream libraries, what analogy do you allude to?</div></div><div><br></d=
iv><div><span style=3D"font-weight: bold; white-space: nowrap;"><br></span>=
</div><div><span style=3D"font-weight: bold; white-space: nowrap;">Dejan Mi=
losavljevic:</span>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); paddin=
g-left: 1ex;">This may be considered as off topic!<br></blockquote><div><br=
></div><div><span class=3D"_username" style=3D"white-space: nowrap;"><span =
class=3D"IVILX2C-D-a">Thiago Macieira:</span></span><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px s=
olid rgb(204, 204, 204); padding-left: 1ex;">Where is operator+ for this ty=
pe going to be defined?=C2=A0</blockquote><div>=C2=A0</div><div><br></div><=
div>Yes, I would consider this as off topic... =C2=A0Your part of the conve=
rsation is not relevant to what we should do w.r.t issue "Graphics 2D =
Library Extension".</div><div>[Note: I'm not saying it is irreleva=
nt in general]</div><div><br></div><div><br></div><div><b>For me, this thre=
ad is about coming up with a set of opinions and conclusions on what should=
be done with the discussed part of the Graphics 2D Proposal</b><b>,</b></d=
iv><div><b>NOT to primarily discuss how a Matrix/Vector Library should be i=
mplemented (for now at least!).</b></div><div>My Approach is, to first mail=
the outcomes in this thread to the proposers of the Graphics 2D LE.</div><=
div>If this is not enough, I will try to write a proposal that suggests to =
rethink the Graphics 2D LE.</div><div><br></div><div><br></div><div>What I =
would like to know is, what solution you would prefer of the ones I propose=
d 5 messages ago.</div><div><br></div><div>Cheers,</div><div>Jakob</div><di=
v><br></div><div>PS: I know, people - including me - tend to get very creat=
ive with the discussions in a particular thread and hence start proposing m=
any Ideas on how we could extend C++ in this and that way,</div><div>rather=
than focusing only on the topic discussed in a particular thread.</div><di=
v>In this case, I invite you to do the latter.</div><div><br></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/89116eeb-c58b-4158-aa52-05735b21f9f5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/89116eeb-c58b-4158-aa52-05735b21f9f5=
%40isocpp.org</a>.<br />
------=_Part_1254_1619542491.1497340664406--
------=_Part_1253_2093923040.1497340664405--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 13 Jun 2017 10:52:41 -0400
Raw View
On 2017-06-10 12:58, Nicol Bolas wrote:
> Having to get a full-fledged vector/matrix library through the committee is
> a lot harder than just saying, "here's a few types that exist for a narrow
> purpose". You'd essentially be delaying the standardization of the graphics
> library for things that have nothing to do with graphics.
If we standardize the graphics library as-is, then later introduce
general linear algebra types, we'll end up with people wanting to know
'why the ___ doesn't the graphics API use the standard types?!'.
> Now granted, I don't think the graphics library should be standardized *at
> all*
Yeah. That too :-).
--
Matthew
--
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/62b6b525-143e-49c4-b7d0-f137fcd42ed1%40gmail.com.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 13 Jun 2017 10:59:26 -0400
Raw View
On 2017-06-10 21:06, Nicol Bolas wrote:
>> If C++ had come with a more complete set of vocabulary types long
>> ago we wouldn't have had CString, QString and wxString
>
> C++98 had std::string. That stopped precisely *nobody* from making those
> other string types. C++ users have proven that having a "vocabulary type"
> will stop nobody from making their own. No matter how good that type is,
> "not invented here" syndrome is strong among us.
While I don't disagree with that, I think that with std::string there
are mitigating factors. Particularly, that C++ core *still* has very
lacking support for i18n (i.e. Unicode). Certainly a major reason for
QString's creation was to have strong support for multilingual text.
These days with most sane platforms defaulting to UTF-8, the situation
isn't *as* bad as before, but remember that QString was created back in
the bad days of having to care about local character sets (or worse,
people assuming ISO-8859 a.k.a. Latin-1).
> Mandatory XKCD <https://xkcd.com/927/>. Being late never helps.
True, but if the recent churn re: Qt's containers is at all meaningful,
there *is* some automatic pressure to gravitate toward the C++-core
standard.
--
Matthew
--
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/fccdde82-af08-26ae-bc52-f95bdac37419%40gmail.com.
.
Author: Vishal Oza <vickoza@gmail.com>
Date: Tue, 13 Jun 2017 09:55:53 -0700 (PDT)
Raw View
------=_Part_4129_830042268.1497372953601
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Yes I think it is a bad thing rename at least 2dvector to point breaks the =
math. A point in 2d space (but also in 3d space) is simple a set of coordin=
ates. I think that this could lead to garabage models with no type safety l=
ike in C. What does it means to only ad a group of points together without =
diving the them by a total numbers of point added. That is just a garabage =
model.
--=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/f5003a42-2620-42c6-a22a-6e97c16d263a%40isocpp.or=
g.
------=_Part_4129_830042268.1497372953601--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 13 Jun 2017 13:55:41 -0400
Raw View
On 2017-06-12 07:57, Jakob Riedle wrote:
> [Note start --
> We could potentially resurrect std::valarray for that since it has
> pretty similar semantics on its operators. We could give it a purpose again
> ;-)
> We would have to equip it with .x, .y, and .z members and optional fixed
> size dimensions. Potential Way to do that:
> std::valarray<int> /* becomes shorthand for */ std::valarray<int[]> //
> Note implicit/dynamic extent
> std::valarray<int[3]> // is a fixed-size valarray
> std::valarray<int[3][3]> // could be disallowed by now. Extendable in
> the future to be a matrix and so on...
> Then we could standardize e.g.
> template<typename T>
> using point2d = std::valarray<T[2]>;
> template<typename T>
> using point3d = std::valarray<T[3]>;
> -- Note end]
`operator*` for std::valarray is not what you want for linear algebra
types...
> *Templatize the Graphics Library to use arbitrary
> vector_2d/wsPoint/eigen::vector2i/osg::vec2d as long as they provide .x and
> .y
I don't think this would work for Eigen types. Anyway, I'd probably
rather it worked with:
auto [x, y] = vec;
Of course, this means enforcing order, which as some noted we'd rather
not do. (I'm not sure I agree with that, however. First, because a type
*should* be ordered in the order its dimensions are naturally expressed.
For one, this makes it easier to reason about extending or reducing the
type to a different number of dimensions. Note, however, that I don't
think this has any implications how the data is *laid out in memory* if
for some reason that's important. Second, because generic algorithms,
unpacking, etc. are going to implicitly need to make assumptions about
the order, and if we try to avoid that, we make the types less usable.)
--
Matthew
--
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/18d7bd61-8c41-d0e5-9691-6defb0dacb21%40gmail.com.
.
Author: Chet <chet.skolos@gmail.com>
Date: Tue, 13 Jun 2017 12:19:04 -0700 (PDT)
Raw View
------=_Part_1976_141901920.1497381544227
Content-Type: multipart/alternative;
boundary="----=_Part_1977_1964754288.1497381544228"
------=_Part_1977_1964754288.1497381544228
Content-Type: text/plain; charset="UTF-8"
On Tuesday, 13 June 2017 10:55:45 UTC-7, Matthew Woehlke wrote:
>
> On 2017-06-12 07:57, Jakob Riedle wrote:
> > [Note start --
> > We could potentially resurrect std::valarray for that since it has
> > pretty similar semantics on its operators. We could give it a purpose
> again
> > ;-)
> > We would have to equip it with .x, .y, and .z members and optional
> fixed
> > size dimensions. Potential Way to do that:
> > std::valarray<int> /* becomes shorthand for */ std::valarray<int[]>
> //
> > Note implicit/dynamic extent
> > std::valarray<int[3]> // is a fixed-size valarray
> > std::valarray<int[3][3]> // could be disallowed by now. Extendable in
> > the future to be a matrix and so on...
> > Then we could standardize e.g.
> > template<typename T>
> > using point2d = std::valarray<T[2]>;
> > template<typename T>
> > using point3d = std::valarray<T[3]>;
> > -- Note end]
>
> `operator*` for std::valarray is not what you want for linear algebra
> types...
>
> > *Templatize the Graphics Library to use arbitrary
> > vector_2d/wsPoint/eigen::vector2i/osg::vec2d as long as they provide
> .x and
> > .y
>
> I don't think this would work for Eigen types. Anyway, I'd probably
> rather it worked with:
>
> auto [x, y] = vec;
>
> Of course, this means enforcing order, which as some noted we'd rather
> not do. (I'm not sure I agree with that, however. First, because a type
> *should* be ordered in the order its dimensions are naturally expressed.
> For one, this makes it easier to reason about extending or reducing the
> type to a different number of dimensions. Note, however, that I don't
> think this has any implications how the data is *laid out in memory* if
> for some reason that's important. Second, because generic algorithms,
> unpacking, etc. are going to implicitly need to make assumptions about
> the order, and if we try to avoid that, we make the types less usable.)
>
> --
> Matthew
>
Existing practice is inconsistent with the ordering.
Example: Northing and Easting, although sometimes reversed, world
coordinates are often presented with Northing first. Northing being Y and
Easting being X, however this can differ in different geographic regions.
I'm not against standardizing the ordering, but doing so should not be done
lightly.
-- Chet.
--
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/293bb74a-165d-46b2-a567-0561ee0a9dbd%40isocpp.org.
------=_Part_1977_1964754288.1497381544228
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, 13 June 2017 10:55:45 UTC-7, Matthew W=
oehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-06-12 07=
:57, Jakob Riedle wrote:
<br>> =C2=A0 =C2=A0[Note start --
<br>> =C2=A0 =C2=A0We could potentially resurrect std::valarray for that=
since it has=20
<br>> =C2=A0 =C2=A0pretty similar semantics on its operators. We could g=
ive it a purpose again=20
<br>> =C2=A0 =C2=A0;-)
<br>> =C2=A0 =C2=A0We would have to equip it with .x, .y, and .z members=
and optional fixed=20
<br>> =C2=A0 =C2=A0size dimensions. Potential Way to do that:
<br>> =C2=A0 =C2=A0std::valarray<int> /* becomes shorthand for */ =
std::valarray<int[]> //=20
<br>> =C2=A0 =C2=A0Note implicit/dynamic extent
<br>> =C2=A0 =C2=A0std::valarray<int[3]> // is a fixed-size valarr=
ay
<br>> =C2=A0 =C2=A0std::valarray<int[3][3]> // could be disallowed=
by now. Extendable in=20
<br>> =C2=A0 =C2=A0the future to be a matrix and so on...
<br>> =C2=A0 =C2=A0Then we could standardize e.g.
<br>> =C2=A0 =C2=A0template<typename T>
<br>> =C2=A0 =C2=A0using point2d =3D std::valarray<T[2]>;
<br>> =C2=A0 =C2=A0template<typename T>
<br>> =C2=A0 =C2=A0using point3d =3D std::valarray<T[3]>;
<br>> =C2=A0 =C2=A0-- Note end]
<br>
<br>`operator*` for std::valarray is not what you want for linear algebra
<br>types...
<br>
<br>> *Templatize the Graphics Library to use arbitrary=20
<br>> =C2=A0 =C2=A0vector_2d/wsPoint/eigen::<wbr>vector2i/osg::vec2d as =
long as they provide .x and=20
<br>> =C2=A0 =C2=A0.y
<br>
<br>I don't think this would work for Eigen types. Anyway, I'd prob=
ably
<br>rather it worked with:
<br>
<br>=C2=A0 auto [x, y] =3D vec;
<br>
<br>Of course, this means enforcing order, which as some noted we'd rat=
her
<br>not do. (I'm not sure I agree with that, however. First, because a =
type
<br>*should* be ordered in the order its dimensions are naturally expressed=
..
<br>For one, this makes it easier to reason about extending or reducing the
<br>type to a different number of dimensions. Note, however, that I don'=
;t
<br>think this has any implications how the data is *laid out in memory* if
<br>for some reason that's important. Second, because generic algorithm=
s,
<br>unpacking, etc. are going to implicitly need to make assumptions about
<br>the order, and if we try to avoid that, we make the types less usable.)
<br>
<br>--=20
<br>Matthew
<br></blockquote><div><br></div><div><p class=3D"MsoNormal" style=3D"backgr=
ound-image: initial; background-position: initial; background-size: initial=
; background-repeat: initial; background-attachment: initial; background-or=
igin: initial; background-clip: initial;"><span style=3D"font-size: 10pt; f=
ont-family: Arial, sans-serif;">Existing practice is inconsistent
with the ordering.=C2=A0<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"background-image: initial; background-posit=
ion: initial; background-size: initial; background-repeat: initial; backgro=
und-attachment: initial; background-origin: initial; background-clip: initi=
al;"><span style=3D"font-size: 10pt; font-family: Arial, sans-serif;">=C2=
=A0</span></p>
<p class=3D"MsoNormal" style=3D"background-image: initial; background-posit=
ion: initial; background-size: initial; background-repeat: initial; backgro=
und-attachment: initial; background-origin: initial; background-clip: initi=
al;"><span style=3D"font-size: 10pt; font-family: Arial, sans-serif;">Examp=
le: Northing and Easting, although sometimes reversed, world coordinates ar=
e often presented with Northing
first. Northing being Y and Easting being X, however this can differ in
different geographic regions.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"background-image: initial; background-posit=
ion: initial; background-size: initial; background-repeat: initial; backgro=
und-attachment: initial; background-origin: initial; background-clip: initi=
al;"><span style=3D"font-size: 10pt; font-family: Arial, sans-serif;">=C2=
=A0</span></p>
<p class=3D"MsoNormal" style=3D"background-image: initial; background-posit=
ion: initial; background-size: initial; background-repeat: initial; backgro=
und-attachment: initial; background-origin: initial; background-clip: initi=
al;"><span style=3D"font-size: 10pt; font-family: Arial, sans-serif;">I'=
;m not against standardizing the
ordering, but doing so should not be done lightly.<o:p></o:p></span></p><p =
class=3D"MsoNormal" style=3D"background-image: initial; background-position=
: initial; background-size: initial; background-repeat: initial; background=
-attachment: initial; background-origin: initial; background-clip: initial;=
"><span style=3D"font-size: 10pt; font-family: Arial, sans-serif;"><br></sp=
an></p><p class=3D"MsoNormal" style=3D"background-image: initial; backgroun=
d-position: initial; background-size: initial; background-repeat: initial; =
background-attachment: initial; background-origin: initial; background-clip=
: initial;"><span style=3D"font-size: 10pt; font-family: Arial, sans-serif;=
">-- Chet.</span></p></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/293bb74a-165d-46b2-a567-0561ee0a9dbd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/293bb74a-165d-46b2-a567-0561ee0a9dbd=
%40isocpp.org</a>.<br />
------=_Part_1977_1964754288.1497381544228--
------=_Part_1976_141901920.1497381544227--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 13 Jun 2017 16:48:26 -0400
Raw View
On 2017-06-13 15:19, Chet wrote:
> Existing practice is inconsistent with the ordering.
>
> Example: Northing and Easting, although sometimes reversed, world
> coordinates are often presented with Northing first. Northing being Y and
> Easting being X, however this can differ in different geographic regions.
Geodesy is *weird* :-). (And I don't just mean the habit of ordering
point values "backwards".)
On a note of amusing coincidence, I committed
https://github.com/Kitware/kwiver/commit/5680fd16db4349e37f1f94896e385b2ab8a22b32
only 19 days ago. (Executive summary: kwiver::vital::geo_point specifies
Easting, Northing storage.)
The previous geo-point type I wrote was not an array, and had members
"northing" and "easting". (Granted, they were in that order.)
IMO, as soon as you have something that can be accessed like an array,
you're going to have users expecting that `p[0]` is the "x" value.
--
Matthew
--
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/3f730e70-23a7-2654-486f-af9151cbc957%40gmail.com.
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Tue, 13 Jun 2017 21:20:48 -0700 (PDT)
Raw View
------=_Part_4494_167641374.1497414049017
Content-Type: multipart/alternative;
boundary="----=_Part_4495_715982585.1497414049017"
------=_Part_4495_715982585.1497414049017
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2017=E5=B9=B46=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8B=E5=8D=887:57:33=EF=BC=8CJakob Riedle=E5=86=99=E9=81=93=EF=BC=9A
>
>
> I'm personally ok with 5, 6 and 4 (in order of decreasing preference).
>
> Jakob
>
> +1.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/06b3158d-970c-417d-91f0-931fe20f2677%40isocpp.or=
g.
------=_Part_4495_715982585.1497414049017
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B46=E6=9C=8812=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=887:57:33=EF=BC=8CJakob Riedle=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><br><div>I'm personally ok with 5, 6 and 4 (in order of d=
ecreasing preference).</div><div><br></div><div>Jakob</div><div><br></div><=
/div></blockquote><div>+1. <br></div><div><br></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/06b3158d-970c-417d-91f0-931fe20f2677%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/06b3158d-970c-417d-91f0-931fe20f2677=
%40isocpp.org</a>.<br />
------=_Part_4495_715982585.1497414049017--
------=_Part_4494_167641374.1497414049017--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Tue, 13 Jun 2017 21:21:06 -0700 (PDT)
Raw View
------=_Part_4612_848475889.1497414066085
Content-Type: multipart/alternative;
boundary="----=_Part_4613_1045528364.1497414066085"
------=_Part_4613_1045528364.1497414066085
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2017=E5=B9=B46=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8B=E5=8D=887:57:33=EF=BC=8CJakob Riedle=E5=86=99=E9=81=93=EF=BC=9A
>
>
> I'm personally ok with 5, 6 and 4 (in order of decreasing preference).
>
> Jakob
>
> +1.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/06c6a4e7-52ab-4946-a996-167be2a24989%40isocpp.or=
g.
------=_Part_4613_1045528364.1497414066085
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B46=E6=9C=8812=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=887:57:33=EF=BC=8CJakob Riedle=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><br><div>I'm personally ok with 5, 6 and 4 (in order of d=
ecreasing preference).</div><div><br></div><div>Jakob</div><div><br></div><=
/div></blockquote><div>+1. <br></div><div><br></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/06c6a4e7-52ab-4946-a996-167be2a24989%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/06c6a4e7-52ab-4946-a996-167be2a24989=
%40isocpp.org</a>.<br />
------=_Part_4613_1045528364.1497414066085--
------=_Part_4612_848475889.1497414066085--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Tue, 13 Jun 2017 21:34:44 -0700 (PDT)
Raw View
------=_Part_4577_1217275227.1497414884555
Content-Type: multipart/alternative;
boundary="----=_Part_4578_1568238999.1497414884556"
------=_Part_4578_1568238999.1497414884556
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2017=E5=B9=B46=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8A=E5=8D=883:19:04=EF=BC=8CChet=E5=86=99=E9=81=93=EF=BC=9A
>
>
>
> On Tuesday, 13 June 2017 10:55:45 UTC-7, Matthew Woehlke wrote:
>>
>> On 2017-06-12 07:57, Jakob Riedle wrote:=20
>> > [Note start --=20
>> > We could potentially resurrect std::valarray for that since it has=
=20
>> > pretty similar semantics on its operators. We could give it a=20
>> purpose again=20
>> > ;-)=20
>> > We would have to equip it with .x, .y, and .z members and optional=
=20
>> fixed=20
>> > size dimensions. Potential Way to do that:=20
>> > std::valarray<int> /* becomes shorthand for */ std::valarray<int[]>=
=20
>> //=20
>> > Note implicit/dynamic extent=20
>> > std::valarray<int[3]> // is a fixed-size valarray=20
>> > std::valarray<int[3][3]> // could be disallowed by now. Extendable=
=20
>> in=20
>> > the future to be a matrix and so on...=20
>> > Then we could standardize e.g.=20
>> > template<typename T>=20
>> > using point2d =3D std::valarray<T[2]>;=20
>> > template<typename T>=20
>> > using point3d =3D std::valarray<T[3]>;=20
>> > -- Note end]=20
>>
>> `operator*` for std::valarray is not what you want for linear algebra=20
>> types...=20
>>
>> > *Templatize the Graphics Library to use arbitrary=20
>> > vector_2d/wsPoint/eigen::vector2i/osg::vec2d as long as they provid=
e=20
>> .x and=20
>> > .y=20
>>
>> I don't think this would work for Eigen types. Anyway, I'd probably=20
>> rather it worked with:=20
>>
>> auto [x, y] =3D vec;=20
>>
>> Of course, this means enforcing order, which as some noted we'd rather=
=20
>> not do. (I'm not sure I agree with that, however. First, because a type=
=20
>> *should* be ordered in the order its dimensions are naturally expressed.=
=20
>> For one, this makes it easier to reason about extending or reducing the=
=20
>> type to a different number of dimensions. Note, however, that I don't=20
>> think this has any implications how the data is *laid out in memory* if=
=20
>> for some reason that's important. Second, because generic algorithms,=20
>> unpacking, etc. are going to implicitly need to make assumptions about=
=20
>> the order, and if we try to avoid that, we make the types less usable.)=
=20
>>
>> --=20
>> Matthew=20
>>
>
> Existing practice is inconsistent with the ordering.=20
>
> =20
>
> Example: Northing and Easting, although sometimes reversed, world=20
> coordinates are often presented with Northing first. Northing being Y and=
=20
> Easting being X, however this can differ in different geographic regions.
>
> =20
>
It is actually cultural-specific, e.g. in Chinese, Northing almost always=
=20
comes first.
> I'm not against standardizing the ordering, but doing so should not be=20
> done lightly.
>
>
> Or simply prefer standardizing the method to specify the order instead.
-- Chet.
>
--=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/dead421b-0a51-4e21-aa97-6f401bda946a%40isocpp.or=
g.
------=_Part_4578_1568238999.1497414884556
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B46=E6=9C=8814=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=883:19:04=EF=BC=8CChet=E5=86=99=
=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><br><br>On Tuesday, 13 June 2017 10:55:45 UTC-7, Matthew Woehlke 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 2017-06-12 07:57, Jakob Riedle=
wrote:
<br>> =C2=A0 =C2=A0[Note start --
<br>> =C2=A0 =C2=A0We could potentially resurrect std::valarray for that=
since it has=20
<br>> =C2=A0 =C2=A0pretty similar semantics on its operators. We could g=
ive it a purpose again=20
<br>> =C2=A0 =C2=A0;-)
<br>> =C2=A0 =C2=A0We would have to equip it with .x, .y, and .z members=
and optional fixed=20
<br>> =C2=A0 =C2=A0size dimensions. Potential Way to do that:
<br>> =C2=A0 =C2=A0std::valarray<int> /* becomes shorthand for */ =
std::valarray<int[]> //=20
<br>> =C2=A0 =C2=A0Note implicit/dynamic extent
<br>> =C2=A0 =C2=A0std::valarray<int[3]> // is a fixed-size valarr=
ay
<br>> =C2=A0 =C2=A0std::valarray<int[3][3]> // could be disallowed=
by now. Extendable in=20
<br>> =C2=A0 =C2=A0the future to be a matrix and so on...
<br>> =C2=A0 =C2=A0Then we could standardize e.g.
<br>> =C2=A0 =C2=A0template<typename T>
<br>> =C2=A0 =C2=A0using point2d =3D std::valarray<T[2]>;
<br>> =C2=A0 =C2=A0template<typename T>
<br>> =C2=A0 =C2=A0using point3d =3D std::valarray<T[3]>;
<br>> =C2=A0 =C2=A0-- Note end]
<br>
<br>`operator*` for std::valarray is not what you want for linear algebra
<br>types...
<br>
<br>> *Templatize the Graphics Library to use arbitrary=20
<br>> =C2=A0 =C2=A0vector_2d/wsPoint/eigen::<wbr>vector2i/osg::vec2d as =
long as they provide .x and=20
<br>> =C2=A0 =C2=A0.y
<br>
<br>I don't think this would work for Eigen types. Anyway, I'd prob=
ably
<br>rather it worked with:
<br>
<br>=C2=A0 auto [x, y] =3D vec;
<br>
<br>Of course, this means enforcing order, which as some noted we'd rat=
her
<br>not do. (I'm not sure I agree with that, however. First, because a =
type
<br>*should* be ordered in the order its dimensions are naturally expressed=
..
<br>For one, this makes it easier to reason about extending or reducing the
<br>type to a different number of dimensions. Note, however, that I don'=
;t
<br>think this has any implications how the data is *laid out in memory* if
<br>for some reason that's important. Second, because generic algorithm=
s,
<br>unpacking, etc. are going to implicitly need to make assumptions about
<br>the order, and if we try to avoid that, we make the types less usable.)
<br>
<br>--=20
<br>Matthew
<br></blockquote><div><br></div><div><p class=3D"MsoNormal" style=3D"backgr=
ound-image:initial;background-position:initial;background-repeat:initial"><=
span style=3D"font-size:10pt;font-family:Arial,sans-serif">Existing practic=
e is inconsistent
with the ordering.=C2=A0</span></p>
<p class=3D"MsoNormal" style=3D"background-image:initial;background-positio=
n:initial;background-repeat:initial"><span style=3D"font-size:10pt;font-fam=
ily:Arial,sans-serif">=C2=A0</span></p>
<p class=3D"MsoNormal" style=3D"background-image:initial;background-positio=
n:initial;background-repeat:initial"><span style=3D"font-size:10pt;font-fam=
ily:Arial,sans-serif">Example: Northing and Easting, although sometimes rev=
ersed, world coordinates are often presented with Northing
first. Northing being Y and Easting being X, however this can differ in
different geographic regions.</span></p>
<p class=3D"MsoNormal" style=3D"background-image:initial;background-positio=
n:initial;background-repeat:initial"><span style=3D"font-size:10pt;font-fam=
ily:Arial,sans-serif">=C2=A0</span></p></div></div></blockquote><div>It is =
actually cultural-specific, e.g. in Chinese, Northing almost always comes f=
irst.<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div>
<p class=3D"MsoNormal" style=3D"background-image:initial;background-positio=
n:initial;background-repeat:initial"><span style=3D"font-size:10pt;font-fam=
ily:Arial,sans-serif">I'm not against standardizing the
ordering, but doing so should not be done lightly.</span></p><p class=3D"Ms=
oNormal" style=3D"background-image:initial;background-position:initial;back=
ground-repeat:initial"><span style=3D"font-size:10pt;font-family:Arial,sans=
-serif"><br></span></p></div></div></blockquote><div>Or simply prefer stand=
ardizing the method to specify the order instead.</div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><p class=3D"M=
soNormal" style=3D"background-image:initial;background-position:initial;bac=
kground-repeat:initial"><span style=3D"font-size:10pt;font-family:Arial,san=
s-serif"></span></p><p class=3D"MsoNormal" style=3D"background-image:initia=
l;background-position:initial;background-repeat:initial"><span style=3D"fon=
t-size:10pt;font-family:Arial,sans-serif">-- Chet.</span></p></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/dead421b-0a51-4e21-aa97-6f401bda946a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dead421b-0a51-4e21-aa97-6f401bda946a=
%40isocpp.org</a>.<br />
------=_Part_4578_1568238999.1497414884556--
------=_Part_4577_1217275227.1497414884555--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Tue, 13 Jun 2017 21:36:58 -0700 (PDT)
Raw View
------=_Part_4326_1753836790.1497415018995
Content-Type: multipart/alternative;
boundary="----=_Part_4327_1841062024.1497415018995"
------=_Part_4327_1841062024.1497415018995
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2017=E5=B9=B46=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8B=E5=8D=8812:34:44=EF=BC=8CFrankHB1989=E5=86=99=E9=81=93=EF=BC=9A
>
>
> It is actually cultural-specific, e.g. in Chinese, Northing almost always=
=20
> comes first.
>
>> :( typo, I meant almost *never*.
--=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/b23a741a-1561-40d1-842e-8496300c2330%40isocpp.or=
g.
------=_Part_4327_1841062024.1497415018995
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B46=E6=9C=8814=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=8812:34:44=EF=BC=8CFrankHB1989=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><br><div>It is actually cultural-specific, e.g. in Chinese, N=
orthing almost always comes first.<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div>
<p class=3D"MsoNormal" style=3D"background-image:initial;background-positio=
n:initial;background-repeat:initial"><span style=3D"font-size:10pt;font-fam=
ily:Arial,sans-serif"></span></p></div></div></blockquote></div></blockquot=
e><div>:( typo, I meant almost <i>never</i>.</div><div> <br></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/b23a741a-1561-40d1-842e-8496300c2330%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b23a741a-1561-40d1-842e-8496300c2330=
%40isocpp.org</a>.<br />
------=_Part_4327_1841062024.1497415018995--
------=_Part_4326_1753836790.1497415018995--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Wed, 14 Jun 2017 01:22:32 -0700 (PDT)
Raw View
------=_Part_4536_1634087793.1497428552887
Content-Type: multipart/alternative;
boundary="----=_Part_4537_2006964806.1497428552887"
------=_Part_4537_2006964806.1497428552887
Content-Type: text/plain; charset="UTF-8"
>
> `operator*` for std::valarray is not what you want for linear algebra
> types...
>
Yeah, that's true, at least not for matrices. But valarray is TMK expected
to be used with a non-array type T (although not explicitely stated in the
standard).
My Idea was simple to *alter* the semantics of operator* in case type T is
a two-dimensional Array Type (e.g. int[3][3]) to represent matrix
multiplication.
--
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/57b99c6a-73f0-4f28-8887-a7e544198498%40isocpp.org.
------=_Part_4537_2006964806.1497428552887
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">`operator*` f=
or std::valarray is not what you want for linear algebra
<br>types...
<br></blockquote><div><br></div><div>Yeah, that's true, at least not fo=
r matrices. But valarray is TMK expected to be used with a non-array type T=
(although not explicitely stated in the standard).</div><div>My Idea was s=
imple to <i>alter</i> the semantics of operator* in case type T is a two-di=
mensional Array Type (e.g. int[3][3]) to represent matrix multiplication.</=
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/57b99c6a-73f0-4f28-8887-a7e544198498%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/57b99c6a-73f0-4f28-8887-a7e544198498=
%40isocpp.org</a>.<br />
------=_Part_4537_2006964806.1497428552887--
------=_Part_4536_1634087793.1497428552887--
.