[Qt-interest] Configure QtDesigner ui.h

[Scott Aron Bloom]

When C++0x is standardized we plan on changing towards that...

Boost is unacceptable to many of them, and unique_ptr isn't standardized
enough :(  

Scott



-----Original Message-----
From: Danny Price [mailto:deepblue842 at googlemail.com] 
Sent: Friday, September 02, 2011 11:24 AM
To: Scott Aron Bloom
Cc: qt-interest at qt.nokia.com
Subject: Re: [Qt-interest] Configure QtDesigner ui.h

Then you've been giving your clients very bad advice indeed. auto_ptr is
deprecated in C++0x and a failed design. Do not use it.

Use boost::scoped_ptr, std::unique_ptr or a similar managed pointer.


On 2 Sep 2011, at 19:17, Scott Aron Bloom wrote:
> 
> What I have been promoting with my clients, is to use
std::auto_pointer.
> 
> -----Original Message-----
> From: qt-interest-bounces+scott.bloom=onshorecs.com at qt.nokia.com
> [mailto:qt-interest-bounces+scott.bloom=onshorecs.com at qt.nokia.com] On

> Behalf Of Bo Thorsen
> Sent: Friday, September 02, 2011 9:58 AM
> To: qt-interest at qt.nokia.com
> Subject: Re: [Qt-interest] Configure QtDesigner ui.h
> 
> I hope you will allow me to elaborate a bit on this answer. It's all 
> correct, but a little more explanation could be helpful.
> 
> As John wrote, it's very convenient to inherit from the UI class 
> (private inheritance FTW).
> 
> But I almost always use the d-pointer idiom to get my class 
> definitions as small as possible. This is to avoid the recompile 
> explosion from changing stuff that is included by the header file. And

> if you are building a library, then you should keep binary 
> compatibility when possible, and that includes the size in bytes of 
> the class, so you can't have the UI file change - the fix again is to 
> use a pointer to the UI contents.
> 
> I have tried letting my private class inherit the UI class, but I have

> dropped it again. The reason is one that also works for the original
> question:
> 
> I want to separate the names from the UI file from the names. 
> Pollution of namespaces and scopes is something I take seriously. And 
> it's for some reason a lot more difficult to stay disciplined with 
> naming the objects in a UI file.
> 
> Also, the OP said that it is bad form to do code in the .h file. I 
> actually agree with this, and including the ui_xyz.h file in the cpp 
> file fixes this problem.
> 
> If I'm doing code that's just a quick fire and forget problem, I don't

> have any problems using private inheritance from the UI class - a book

> example would qualify for this. But with all non-trivial code or for 
> any of the above reasons, I won't do it.
> 
> There isn't a single reason that says "this why you absolutely have to

> avoid that", but put all the reasons together, and there is only a bit

> of convenience in the pro list (which quickly isn't convenience 
> because you get used to writing d->ui->...) and a lot of good reasons
against.
> To me that makes it an easy choice.
> 
> Bo.
> 
> Den 02-09-2011 18:15, Ian Thomson skrev:
>> You can do it but it can be a bit of a pain if you do it that way.
>> 
>> There a few reasons why but the best one is this: If you make a 
>> library with a widget using ui through inheritance, when you include 
>> the header for the library in another project that project also has 
>> to
> 
>> have access to the produced ui_whatever.h file to be able to compile.

>> As the ui_whatever.h file is merely a side-effect of the build 
>> process, it should not be part of the library's headers. If that file

>> is cleaned up with a build-clean then your project which includes the

>> library header will no longer compile. That's not a very nice
> side-effect.
>> 
>> Ian.
>> 
>> John Weeks wrote:
>>> Sorry, Bo. I always forget to change the To: field to send to the
> list...
>>> 
>>> On Sep 1, 2011, at 10:27 PM, Bo Thorsen wrote:
>>> 
>>>> Just remember to make the ui a pointer in the class and do a "new 
>>>> MyUIThing" in the constructor. Don't let your class inherit the UI
> class.
>>> 
>>> This caught my eye. Why do you say that? C++ GUI Programming with Qt

>>> 4, second edition, page 27 shows their simple example dialog doing 
>>> exactly that. I rather like the readability of simply naming the 
>>> widgets instead of lots of "ui->..." stuff.
>>> 
>>> Regards, John Weeks
>>> 
>>> 
>>> --------------------------------------------------------------------
>>> -
>>> ---
>>> 
>>> _______________________________________________
>>> Qt-interest mailing list
>>> Qt-interest at qt.nokia.com
>>> http://lists.qt.nokia.com/mailman/listinfo/qt-interest
>> 
>> _______________________________________________
>> Qt-interest mailing list
>> Qt-interest at qt.nokia.com
>> http://lists.qt.nokia.com/mailman/listinfo/qt-interest
> 
> 
> Bo Thorsen,
> Fionia Software.
> 
> --
> 
> Expert Qt and C++ developer for hire
> Contact me if you need expert Qt help
> http://www.fioniasoftware.dk
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-interest
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-interest