Qt-interest Archive, October 1998
GUI component construction
Message 1 in thread
Hi all,
Constructors in QT are responsible for both C++ object and GUI object
construction, How do I know the constructor has done its work
successfully?
MFC use two-phase construction, it let you construct a C++ object
first, then you call Create to create GUI object.
Because constructor can not return a value like normal function, if you
let it do something that may fail, you can either throw out a exception
or modify data member. but which one does QT use?
Thanks.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Message 2 in thread
"Scott Guo" <xsguo@hotmail.com>
> Hi all,
> Constructors in QT are responsible for both C++ object and GUI object
> construction, How do I know the constructor has done its work
> successfully?
It must. That is a postcondition of the constructor. In other words,
we place that burden on the widget's designer, so as to make widgets
simpler to use.
> MFC use two-phase construction, it let you construct a C++ object
> first, then you call Create to create GUI object.
I would be very interested in hearing how many per cent of the Create
calls in Microsoft's MFC example programs are used "properly": the
return value is tested, the code does something reasonable no matter
what the return value is, and what the code does in case of errors is
not likely to fail for the same reasons.
<soapbox>
Mostly-ignored error codes are very bad. An error is
something important, and an API should not be so full of
possible "error" returns that the users of that API get used
to ignoring error codes.
</soapbox>
--Arnt
Message 3 in thread
Thank you for your response, but I can't agree with you.
Let's put those stupid MFC examples aside, they are created for
tutorial, not real world applications. because it's possible that the
caller of a constructor pass a wrong parameter, it's definitly helpful
to have either a return value or an exception. at least it will make
debug much easier.
I guess there must be some reason that Troll implement QT this way,
makeing it easy to use? I don't think portablility is a reasonable
explaination.
Thanks.
>From: Arnt Gulbrandsen <agulbra@troll.no>
>I would be very interested in hearing how many per cent of the Create
>calls in Microsoft's MFC example programs are used "properly": the
>return value is tested, the code does something reasonable no matter
>what the return value is, and what the code does in case of errors is
>not likely to fail for the same reasons.
>
> Mostly-ignored error codes are very bad. An error is
> something important, and an API should not be so full of
> possible "error" returns that the users of that API get used
> to ignoring error codes.
></soapbox>
>
>--Arnt
>
>--
>List archive and information: http://www.troll.no/qt-interest/
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Message 4 in thread
"Scott Guo" <xsguo@hotmail.com>
> Thank you for your response, but I can't agree with you.
>
> Let's put those stupid MFC examples aside, they are created for
> tutorial, not real world applications.
If the tutorials (as you say they are) teach people to use the API in
the "wrong" manner, what reason is there to think that people will do
it the "right" manner?
> because it's possible that the
> caller of a constructor pass a wrong parameter, it's definitly helpful
> to have either a return value or an exception. at least it will make
> debug much easier.
Does this mean that you want to use factories instead of constructors?
Or are you saying that we should just drop support for compilers that
don't support exceptions?
> I guess there must be some reason that Troll implement QT this way,
> makeing it easy to use? I don't think portablility is a reasonable
> explaination.
Portability is a good reason to avoid throwing exceptions; simplicity
of API is a good reason to avoid multi-step object construction.
--Arnt
Message 5 in thread
On Tue, Oct 27, 1998 at 01:14:16AM +0100, Arnt Gulbrandsen wrote:
> Does this mean that you want to use factories instead of constructors?
> Or are you saying that we should just drop support for compilers that
> don't support exceptions?
Will Qt 2.0 target for the same common divisor C++ reference compiler?
Or will it need newer features that you did not use earlier on? Or maybe
is it just to early to comment on that?
cu bart
--
[ signature omitted ]
Message 6 in thread
Bart Vanhauwaert <jafar@kotnet.org>
> Will Qt 2.0 target for the same common divisor C++ reference compiler?
> Or will it need newer features that you did not use earlier on? Or maybe
> is it just to early to comment on that?
It's not too early. 2.0 requires about the same C++ feature set.
There is one significant change, however.
An important new header file is best used with compilers that support
static const reference member objects. Like this:
class A {
static const QImage & b;
};
All that is #define'd so that it will compile on other compilers too,
of course. But it is an important change, because it means that at
least one of the compilers you use for should support this syntax, or
you will not get the "correct" error and warning messages.
--Arnt
Message 7 in thread
Bart Vanhauwaert wrote:
>Will Qt 2.0 target for the same common divisor C++ reference compiler?
>Or will it need newer features that you did not use earlier on? Or maybe
>is it just to early to comment on that?
In general, Qt slowly tracks compilers. Eventually compilers drop off the
edge - cygwin32 is out until it gets OLE (personally I'm kind of glad that
kruft isn't in their libraries, but we needed it for Windows DND).
No-one seemed to notice when Qt started to require templates. We hope to
keep to that pace.
--
[ signature omitted ]
Message 8 in thread
On Mon, Oct 26, 1998 at 04:06:19PM -0800, Scott Guo wrote:
> Let's put those stupid MFC examples aside, they are created for
> tutorial, not real world applications. because it's possible that the
> caller of a constructor pass a wrong parameter, it's definitly helpful
> to have either a return value or an exception. at least it will make
> debug much easier.
It's really difficult to pass bad parameters in the constructors of
widgets in Qt. As such it is nearly impossible for a widget creation
to fail (maybe when the underlying system has not enough resources
to create another window, but that's a borderline case anyway).
And if one of the Qt developers say that a post condition of a Widget
constructor is that it has created a valid widget, then you should
believe him. :)
> I guess there must be some reason that Troll implement QT this way,
> makeing it easy to use? I don't think portablility is a reasonable
> explaination.
Portability is a very good reason in the Troll book to do things the
way they are.
cu bart
--
[ signature omitted ]
Message 9 in thread
Bart Vanhauwaert wrote:
>
> On Mon, Oct 26, 1998 at 04:06:19PM -0800, Scott Guo wrote:
> > Let's put those stupid MFC examples aside, they are created for
> > tutorial, not real world applications. because it's possible that the
> > caller of a constructor pass a wrong parameter, it's definitly helpful
> > to have either a return value or an exception. at least it will make
> > debug much easier.
>
> It's really difficult to pass bad parameters in the constructors of
> widgets in Qt. As such it is nearly impossible for a widget creation
> to fail (maybe when the underlying system has not enough resources
> to create another window, but that's a borderline case anyway).
> And if one of the Qt developers say that a post condition of a Widget
> constructor is that it has created a valid widget, then you should
> believe him. :)
Just a note: QGLWidget does have an error code (check the isValid() method)
for cases when the QGLFormat specified wasn't available. I believe it is the
only widget that has this "feature".
But you can bypass it somewhat. I try to create a format, in decreasing order
of quality, and when I get a valid one I use it to create the viewport and
assert the isValid flag. This way, I don't have to call "new QGLViewport",
check isValid, delete if not and recreate...
e.g.
QGLFormat& View::findFormat( void )
{
if ( viewGLFormat_init == false )
{
viewGLFormat_init = true ;
// Use decent format for creating viewport
QList<QGLFormat> rgFormats ;
rgFormats.setAutoDelete( true ) ;
QGLFormat* format ;
// Setup different formats to try, in order of decreasing quality
format = new QGLFormat ;
format->setRgba( true ) ;
format->setDoubleBuffer( true ) ;
format->setDepth( true ) ;
format->setAlpha( true ) ; // should be true
rgFormats.append( format ) ;
format = new QGLFormat ;
format->setRgba( true ) ;
format->setDoubleBuffer( false ) ;
format->setDepth( true ) ;
format->setAlpha( true ) ; // should be true
rgFormats.append( format ) ;
format = new QGLFormat ;
format->setRgba( true ) ;
format->setDoubleBuffer( false ) ;
format->setDepth( true ) ;
format->setAlpha( false ) ;
rgFormats.append( format ) ;
format = new QGLFormat ;
format->setRgba( true ) ;
format->setDoubleBuffer( false ) ;
format->setDepth( false ) ;
format->setAlpha( false ) ;
rgFormats.append( format ) ;
QListIterator<QGLFormat> it(rgFormats);
QGLContext ctx( QGLFormat::defaultFormat(), this ) ;
for ( ; it.current(); ++it )
{
format = it.current();
ctx.setFormat( *format ) ;
if ( ctx.create() == true )
break ;
}
// Default in case everything else fails.
if ( format != 0 )
viewGLFormat = *format ;
else
viewGLFormat = QGLFormat::defaultFormat() ;
}
return viewGLFormat ;
}
--
[ signature omitted ]
