220 32727 article Path: news.gmane.org!.POSTED!not-for-mail From: FrankHB1989 Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Why do we include a Matrix and Vector class into the proposed 2D Graphics Library? Date: Sun, 11 Jun 2017 21:15:45 -0700 (PDT) Lines: 182 Approved: news@gmane.org Message-ID: References: <7e3ee19d-f758-4d38-a015-0c474424073d@isocpp.org> <20170609115017.5132345.91153.30981@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_401_1960331645.1497240945150" X-Trace: blaine.gmane.org 1497240949 7460 195.159.176.226 (12 Jun 2017 04:15:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Jun 2017 04:15:49 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCTJVBPG3QIBB4VK7DEQKGQEC3NT36I@isocpp.org Mon Jun 12 06:15:43 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f199.google.com ([209.85.192.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dKGlS-0001ai-U4 for gclcip-std-proposals@m.gmane.org; Mon, 12 Jun 2017 06:15:43 +0200 Original-Received: by mail-pf0-f199.google.com with SMTP id a65sf7723315pfg.11 for ; Sun, 11 Jun 2017 21:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=JXZJ+GDVtTz/eMd3aifftm5befto2zf18UozohkTstU=; b=T9PJOIv0qJoB2RIbHCopPuO4h0OoPH+9gnLaRrQBAph25GIjuWgS5cvyE79JA98+V7 4AyaR0Pzhl+T7H7wNV7m23Cidx9WDayBuLp+B5jg2Yf5QxyNiTtQe205JVE6fn/z/sxC /PWUjU7tT8mth7L9wUxoVqvpx+6Blu1Pqztwj3parxW3dhnq/dfRDg/18qNhgEcy2CjQ h9c6vT/51Ic/H2SZmB7zim7NuUuK89Kk05ZHSRpLQCg/Ak3mcv4a950kcQqWq/c4UHSn lDjj0JuhZ0vwMltYWfEeHRMUEmcaCsTZ7SkhpDciuMj/niS/m1r0Ttr9QvCXSYESnZ+b HZ0Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=JXZJ+GDVtTz/eMd3aifftm5befto2zf18UozohkTstU=; b=amtbY+ag+mCsuY0k4XcWbfq0tqQdBgpYysn8QOK6JCbbqBeWakZI4+5jCTxzVc1jZ2 x5Qv47C6iuL+iMOZCvXI73n1MYE74tYA95OOx8fI/NQ4TXve6dm5W22CoMB6/3bt4Big 6/QtDy1nPZOkI8jzmA8dYOAk6k1puPbISZ928xOiz3qcXoCGWQxo2dEsu+rwm9uBG4o2 N1hj33GST86xJt5Rif0h9Qqnj5y2X6zhdMh99TFn2HrX0nAK04d6vSZxWzeUVrmp3PkA 3g+tjT0QlRPIHPCM27thJvMqjRygHdQ1eg8eMo4WrROr1uh6G0LHY1TXDYRXR/dFgbkj QKlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=JXZJ+GDVtTz/eMd3aifftm5befto2zf18UozohkTstU=; b=emtMqX91zpNIxZd/S5aQtFrjLOpxHmC7XZTU8Wq2bjjuDSp1tv1H6YooyPHgMbMccZ ThXIjNkWss0cjFvhyvGVhp9bfa4B2fLATRlp3R1ykCg2o04akR4r2HE7dv4xO3twdGHH P1mT3KZM+qUH+pHYXBrpP4dZih+sMqGgKO2oiMwtCx8IkkBImw3SIYMKzaT5+Ep+cZqK HgC94F/L4bOGhOFQg7IogKSfJijz8qv0s6VWUx8babMFvMAc0kswsp+dN2HeOlW4++za dCRtQCM84WLt2TlSxcbMYQ50S+VMK74etH1t7cDrYt17wazvHVcEorQ2wQJCscJQZLP+ IfMw== X-Gm-Message-State: AODbwcDITzVJUVflgGGc6V3OI7fgovOvwbk+bq4tzAmuf4HFhlj1VR8a cRxBh/jVuYf6eamw X-Received: by 10.99.143.8 with SMTP id n8mr12337226pgd.64.1497240946734; Sun, 11 Jun 2017 21:15:46 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.5.5 with SMTP id 5ls13208962otw.11.gmail; Sun, 11 Jun 2017 21:15:45 -0700 (PDT) X-Received: by 10.157.51.170 with SMTP id u42mr1251486otc.7.1497240945730; Sun, 11 Jun 2017 21:15:45 -0700 (PDT) In-Reply-To: X-Original-Sender: frankhb1989@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:32727 Archived-At: ------=_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 > .=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


=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 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
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
=
C++98 had std::string. That stopped precisely nobody 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.
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.

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 abused 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.)=

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.

So on this point I say: Better late than never.
<= /div>

Mandatory XKCD. Being late= never helps.

At least, less troubles = to regret, before being widespread.

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.

Yes, that doesn'= ;t mean we shouldn't have them. But we need to have realistic expectati= ons of the results of such things.

=
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.

=
Instead of preventing NIH by adding mandatory types, specify req= uirements of those types may be more appropriate (except for potential code= bloat).

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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.org.
------=_Part_402_297090396.1497240945150-- ------=_Part_401_1960331645.1497240945150-- .