220 9006 <8a29e404-8218-4853-9db9-d4030709ab43@isocpp.org> article Path: news.gmane.org!not-for-mail From: Bengt Gustafsson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Comments on 2d api for c++ N3888.pdf Date: Sun, 2 Feb 2014 20:14:20 -0800 (PST) Lines: 253 Approved: news@gmane.org Message-ID: <8a29e404-8218-4853-9db9-d4030709ab43@isocpp.org> References: <9105f9b2-e15d-4bf8-a4a1-65ebc3657eb0@isocpp.org> <1499411.eehuFWK7Yv@tjmaciei-mobl2> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4105_21131894.1391400860372" X-Trace: ger.gmane.org 1391400854 31354 80.91.229.3 (3 Feb 2014 04:14:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Feb 2014 04:14:14 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCRIRSPDTQIRBHNPXSLQKGQEQOII2JY@isocpp.org Mon Feb 03 05:14:23 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f200.google.com ([209.85.214.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WAAvO-00044G-F4 for gclcip-std-proposals@m.gmane.org; Mon, 03 Feb 2014 05:14:22 +0100 Original-Received: by mail-ob0-f200.google.com with SMTP id wo20sf26327317obc.3 for ; Sun, 02 Feb 2014 20:14:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=I9tKGocSIOFlPMwog9ExvvzolkwD/HdkEa8lD8CmYVU=; b=X4MDkUqFSXLg+xQlWcA8pnPiEIAFtMSHcEK25lEEMfEp88XbK/DQMUGvOZlNEcvbrp DeRZ2Ojrn94EoiwmfNoEuWoU0LHQP5SkUCfX5Pzn26Gchsep5fRVYlkl+W+dfUMvmqdM mGm+yJFkiluB6TEhGdfCF3WFjig99ZKseK0mreZ+L24PDKpiuR7K2Uog0mMGwJ4WIUrp MNA28ivzGEnj5VcdKMnVxl4LOMnSXtkqGDrBTtwNwSaZygtK9Ov4rASTXDw4JTH7uAX7 cog+jInyDha+nZQxgsQXtnMZACZ0k3eckp1RSIphpWRPL4kX7RLT4Di2H6tVR8V27HCU JzKg== X-Gm-Message-State: ALoCoQmE+J38HoQVsAGWQftWRCZ3ENBAg6z8WhGg5Wb2+XfT0atgMSHQQrsrgJgnGepzyxONWvp8 X-Received: by 10.182.216.200 with SMTP id os8mr13230542obc.0.1391400861462; Sun, 02 Feb 2014 20:14:21 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.86.212 with SMTP id p78ls1709762qgd.10.gmail; Sun, 02 Feb 2014 20:14:20 -0800 (PST) X-Received: by 10.140.48.200 with SMTP id o66mr9568qga.15.1391400860884; Sun, 02 Feb 2014 20:14:20 -0800 (PST) In-Reply-To: <1499411.eehuFWK7Yv@tjmaciei-mobl2> X-Original-Sender: bengt.gustafsson@beamways.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:9006 Archived-At: ------=_Part_4105_21131894.1391400860372 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable About method overloads that take point or rect types. I now came to the=20 conclusion that we should have a template overload to cater for "all" types of point classes the user of the library may have on hand. Can this be=20 done? Yes: Using the same principles as std::begin() and std::end() it can,= =20 even if x and y are not named so, for instance. template decltype(typename T::x) get_x(const T& src) { return= =20 src.x; } // But now, oops, MyPoint didn't have an x member as it has a double=20 data[2] instead to store the coordinates (it may be part of a matrix=20 library). This is easily fixed: double get_x(const MyPoint& src) { return src.data[0]; } // Functions taking points inside std::drawing classes then have this style= =20 signature: template void DrawLine(const P& from, const P& to) { DrawLine(get_x(from), get_y(from), get_x(to), get_y(to)); } // Which of course calls the non-template (virtual?) DrawLine() that does= =20 the job. // The get_x() returns decltype(T::x) to handle the possibility that there= =20 are overloaded DrawLine for double and int parameters. Aside: I think that the logical thing to do is to actually make such=20 methods virtual. Any drawing operation is going to be very heavy compared= =20 to a virtual call. Forcing users to make templates out of all their drawing= =20 code in order to draw on different devices is just not practical. Firstly= =20 you don't want to have that type of code in header files, and secondly you may not even know at the call site what= =20 you are drawing on (for instance different types of printers or vector file= =20 generators). Similar reasoning applies to image memory handling, where the= =20 runtime file format of a loaded image file may cause different memory=20 layouts etc. C++ provides many tools, we must try to use all of them appropriately! Den tisdagen den 28:e januari 2014 kl. 22:49:19 UTC+1 skrev Thiago Macieira= : > > On ter=C3=A7a-feira, 28 de janeiro de 2014 23:28:55, Ville Voutilainen wr= ote:=20 > > > that the user may need? What if an implementation supports multiple,= =20 > > > runtime-selectable engines with different handle types?)=20 > >=20 > > Then these handles need to be separately extracted from the native=20 > handle.=20 > > That is, of course, not going to end up achieving the avoidance of=20 > > boilerplate in the previous part.=20 > > FYI=20 > > This is exactly the case now in Qt 5 (especially on Unix), since the=20 > backend=20 > is selected at runtime and there are no macros you can #ifdef on.=20 > > There's a function that can return the name of the backend at runtime and= =20 > you=20 > have to make your decision then. That means the user application needs to= =20 > guess ahead of time which backends it might need to integrate. This is=20 > especially the case for Linux, where the backend might be "xcb",=20 > "wayland",=20 > "eglfs" or other things.=20 > > The integration is done with a series of QPlatformXXXX classes, especiall= y=20 > QPlatformNativeInterface:=20 > > virtual void *nativeResourceForIntegration(const QByteArray=20 > &resource);=20 > virtual void *nativeResourceForContext(const QByteArray &resource,=20 > QOpenGLContext *context);=20 > virtual void *nativeResourceForScreen(const QByteArray &resource,=20 > QScreen=20 > *screen);=20 > virtual void *nativeResourceForWindow(const QByteArray &resource,=20 > QWindow=20 > *window);=20 > virtual void *nativeResourceForBackingStore(const QByteArray=20 > &resource,=20 > QBackingStore *backingStore);=20 > > Used, for example, like:=20 > > // xcb:=20 > xcb_connection_t *d =3D=20 > qApp->nativeInterface()->nativeResourceForWindow("connection", w)= ;=20 > > --=20 > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20 > Software Architect - Intel Open Source Technology Center=20 > PGP/GPG: 0x6EF45358; fingerprint:=20 > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358=20 > --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_4105_21131894.1391400860372 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
About method overloads that take point or rect types. I no= w came to the conclusion that we should have a template overload to cater f= or "all" types
of point classes the user of the library may have on han= d. Can this be done? Yes: Using the same principles as std::begin() and std= ::end() it can, even if x and y are not named so, for instance.
<= br>
template <typename T> decltype(typename T::x) = ;get_x(const T& src) { return src.x; }

// But = now, oops, MyPoint didn't have an x member as it has a double data[2] inste= ad to store the coordinates (it may be part of a matrix library). This is e= asily fixed:

double get_x(const MyPoint& src) = { return src.data[0]; }


// Function= s taking points inside std::drawing classes then have this style signature:=

template<typename P> void DrawLine(const P&= amp; from, const P& to) {
    DrawLine(get_x(from),= get_y(from), get_x(to), get_y(to));
}

/= / Which of course calls the non-template (virtual?) DrawLine() that does th= e job.

// The get_x() returns decltype(T::x) to ha= ndle the possibility that there are overloaded DrawLine for double and int = parameters.

Aside: I think that the logical thing = to do is to actually make such methods virtual. Any drawing operation is go= ing to be very heavy compared to a virtual call. Forcing users to make temp= lates out of all their drawing code in order to draw on different devices i= s just not practical. Firstly you don't want to have that type of code
in header files, and secondly you may not even know at the call site = what you are drawing on (for instance different types of printers or vector= file generators). Similar reasoning applies to image memory handling, wher= e the runtime file format of a loaded image file may cause different memory= layouts etc.

C++ provides many tools, we must try= to use all of them appropriately!


Den tisdagen den 28:e = januari 2014 kl. 22:49:19 UTC+1 skrev Thiago Macieira:
On ter=C3=A7a-feira, 28 de janeiro de 2014 23:28:55= , Ville Voutilainen wrote:
> > that the user may need? What if an implementation supports mu= ltiple,
> > runtime-selectable engines with different handle types?)
>=20
> Then these handles need to be separately extracted from the native= handle.
> That is, of course, not going to end up achieving the avoidance of
> boilerplate in the previous part.

FYI

This is exactly the case now in Qt 5 (especially on Unix), since the ba= ckend=20
is selected at runtime and there are no macros you can #ifdef on.

There's a function that can return the name of the backend at runtime a= nd you=20
have to make your decision then. That means the user application needs = to=20
guess ahead of time which backends it might need to integrate. This is= =20
especially the case for Linux, where the backend might be "xcb", "wayla= nd",=20
"eglfs" or other things.

The integration is done with a series of QPlatformXXXX classes, especia= lly=20
QPlatformNativeInterface:

    virtual void *nativeResourceForIntegration(const QBy= teArray &resource);
    virtual void *nativeResourceForContext(const QByteAr= ray &resource,=20
QOpenGLContext *context);
    virtual void *nativeResourceForScreen(const QByteArray &a= mp;resource, QScreen=20
*screen);
    virtual void *nativeResourceForWindow(const QByteArray &a= mp;resource, QWindow=20
*window);
    virtual void *nativeResourceForBackingStore(con= st QByteArray &resource,=20
QBackingStore *backingStore);

Used, for example, like:

// xcb:
xcb_connection_t *d =3D=20
        qApp->nativeInterfac= e()->nativeResourceForWindow("connection", w);

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4= 5358

--
 
---
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_4105_21131894.1391400860372-- .