[Development] Common base class for all socket types
Alfonso Chartier
alfonso.chartier at gmail.com
Mon Nov 5 23:30:24 CET 2012
Hello,
What is the likelihood that QTBUG-27635 (
https://bugreports.qt-project.org/browse/QTBUG-27635) will be fixed for Qt
5? The idea here is for all socket classes to inherit from a common base
class (for instance, QAbstractSocket). The current design, where different
concrete socket classes derive from different classes, is not very logical
and does not allow client code to take advantage of a common API. Since
making these changes would require breaking backwards compatibility, they
would need to be done for the initial Qt 5 release.
Best,
Alfonso
On Mon, Nov 5, 2012 at 3:00 AM, <development-request at qt-project.org> wrote:
> Send Development mailing list submissions to
> development at qt-project.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.qt-project.org/mailman/listinfo/development
> or, via email, send a message with subject or body 'help' to
> development-request at qt-project.org
>
> You can reach the person managing the list at
> development-owner at qt-project.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Development digest..."
>
>
> Today's Topics:
>
> 1. Re: Danger when excluding auto tests with pre-processor
> macro. (Thiago Macieira)
> 2. Re: Consistency in Qt headers (extends: 'renaming all QWindow
> properties that have "window" in them') (Sze Howe Koh)
> 3. Re: Proposal: virtual method of QtNetwork interfaces (Yang Fan)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 04 Nov 2012 12:26:12 +0100
> From: Thiago Macieira <thiago.macieira at intel.com>
> Subject: Re: [Development] Danger when excluding auto tests with
> pre-processor macro.
> To: development at qt-project.org
> Message-ID: <3486413.Fa6hFUMDpd at tjmaciei-mobl2>
> Content-Type: text/plain; charset="us-ascii"
>
> On domingo, 4 de novembro de 2012 10.42.39, Olivier Goffart wrote:
> > > At some point Jason McDonald was going over all the tests and fixing
> > > this, but maybe someone needs to take a second round now...
> >
> > I already let Jason know at that time, and he fixed most of them
> > (commit a8fd0c3654f8352773638633778cd8003680cbc7 )
> >
> > But since Jason has left (AFAIK?), the history repeat again
>
> There have been a series of commits doing it in the other direction.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 190 bytes
> Desc: This is a digitally signed message part.
> Url :
> http://lists.qt-project.org/pipermail/development/attachments/20121104/f262e5d7/attachment-0001.bin
>
> ------------------------------
>
> Message: 2
> Date: Sun, 4 Nov 2012 23:04:41 +0800
> From: Sze Howe Koh <szehowe.koh at gmail.com>
> Subject: Re: [Development] Consistency in Qt headers (extends:
> 'renaming all QWindow properties that have "window" in them')
> To: "development at qt-project.org" <development at qt-project.org>
> Message-ID:
> <CALW8pfVbQaOoUXYCW0dVL=2vC5Mi_B6p=
> 45VpM4f8FCBUS8kxA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Oct 30, 2012 at 7:45 PM, Sze Howe Koh <szehowe.koh at gmail.com>
> wrote:
> > I'll begin cleaning up the selected Qt 5.0 modules first, then move on
> > to the others later.
>
> The renaming of QtMultimedia and QtMultimedia::MetaData has been
> submitted for review:
> https://codereview.qt-project.org/38564
> https://codereview.qt-project.org/38573
> https://codereview.qt-project.org/38574
> https://codereview.qt-project.org/38575
>
>
> Next up: QtConcurrent
>
> Right now, the usage and documentation of the QtConcurrent namespace
> is very different from the rest of Qt. Its functions are split between
> 3 different headers (function parameters omitted below):
>
> #include <QtConcurrentFilter>
> QtConcurrent::blockingFilter()
> QtConcurrent::blockingFiltered()
> QtConcurrent::blockingFilteredReduced()
> QtConcurrent::filter()
> QtConcurrent::filtered()
> QtConcurrent::filteredReduced()
>
> #include <QtConcurrentMap>
> QtConcurrent::blockingMap()
> QtConcurrent::blockingMapped()
> QtConcurrent::blockingMappedReduced()
> QtConcurrent::map()
> QtConcurrent::mapped()
> QtConcurrent::mappedReduced()
>
> #include <QtConcurrentRun>
> QtConcurrent::run()
>
>
> Elsewhere in Qt, devs would #include the name of the namespace or
> class (or even the overarching module) as the camel-case header, in
> order to use its functions/enums:
>
> #include <QNamespace>
> ...
> int result = QNamespace::someFunc();
>
>
> However, the QtConcurrent headerse don't follow this pattern --
> QtConcurrent[Filter|Map|Run] do not correspond to any well-defined
> part of Qt's class hierarchy.
>
> Furthermore, each of the other namespaces have all their
> functions/enums documented together under one page, but QtConcurrent
> is split across 4 pages.
>
> Thus, in combination with the other points mentioned in this thread, I
> propose:
>
> 1) Deprecate the "QtConcurrent" namespace, in favour of "QConcurrent"
> 2) Expose all Q(t)Concurrent functions under one camel-case header
> ("#include <QConcurrent>") for new code, while preserving the old
> header files for compatibility
> 3) Merge the (significantly overlapping) doc pages of the
> Q(t)Concurrent functions [1-3] into the (currently very bare)
> namespace page [4].
>
> Is this ok? If so, I'll start making the changes.
>
>
> Regards,
> Sze-Howe
>
> [1] http://doc-snapshot.qt-project.org/5.0/qtconcurrentfilter.html
> [2] http://doc-snapshot.qt-project.org/5.0/qtconcurrentmap.html
> [3] http://doc-snapshot.qt-project.org/5.0/qtconcurrentrun.html
> [4] http://doc-snapshot.qt-project.org/5.0/qtconcurrent.html
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 5 Nov 2012 17:25:11 +0800
> From: Yang Fan <missdeer at gmail.com>
> Subject: Re: [Development] Proposal: virtual method of QtNetwork
> interfaces
> To: Robert Knight <robertknight at gmail.com>
> Cc: "development at qt-project.org" <development at qt-project.org>
> Message-ID:
> <CAHf7+KoediGoTrAGDEEoDU6TQS5bv=
> p4_L-Zv8Na4NgGXAAqzQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Thanks a lot.
>
>
> On Sat, Nov 3, 2012 at 8:46 PM, Robert Knight <robertknight at gmail.com
> >wrote:
>
> > > I wonder if your guys could modify the QNetworkAccessManager's method
> > declaration(get, post, put...), make them be virtual,
> > > so that I can derive a subclass and modify the implementation
> >
> > You can already do this. Re-implement the protected createRequest()
> > method.
> >
> > Regards,
> > Rob.
> >
> > On 3 November 2012 12:42, Yang Fan <missdeer at gmail.com> wrote:
> > > Hi list,
> > >
> > > I'm writing a network program which runs on MS Windows, Linux and Mac
> OS
> > X.
> > > All things look good but it seems that the network performance needs
> > > improving. I see the QtNetwork module especially the
> > QNetworkAccessManager
> > > class which I'm mainly using in my program is implemented using cross
> > > platform select model, this model is designed for easy using but not
> for
> > > good performance such as low latency and high throughout, every
> Operating
> > > System provide a special socket/IO model to let applications have good
> > > performance, for example, MS Windows provides IO completion port model,
> > > Linux (>= 2.6 kernel) provides epoll/AIO model, BSD/Mac OSX provide
> > kqueue
> > > etc. So I want to provide my customized NetworkAccessManager class,
> but
> > I
> > > don't want to modify the Qt's source code since I will use Boost.asio
> > > library which depends on Boost library, a very big library that is not
> > > suitable to include in Qt as a 3rd party library. I wonder if your guys
> > > could modify the QNetworkAccessManager's method declaration(get, post,
> > > put...), make them be virtual, so that I can derive a subclass and
> modify
> > > the implementation. The reason I need a subclass of
> QNetworkAccessManager
> > > not a new class is, I also want my class could be set as the network
> > engine
> > > of QtWebkit.
> > > Feel free to reply if you have any other good idea.
> > >
> > > Regards,
> > > Fan Yang
> > >
> > >
> > > _______________________________________________
> > > Development mailing list
> > > Development at qt-project.org
> > > http://lists.qt-project.org/mailman/listinfo/development
> > >
> >
>
>
>
> --
> Regards,
> Fan Yang
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.qt-project.org/pipermail/development/attachments/20121105/b7c2982e/attachment-0001.html
>
> ------------------------------
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
> End of Development Digest, Vol 14, Issue 13
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121105/a65bef67/attachment.html>
More information about the Development
mailing list