G++ would not allow this, take a look before it drives you nuts (example with QPalette)
-
Well, I tried your code, and it is exactly as I predicted: it does not work. That is: it works if you change the palette before a widget is shown. If you change it after it has already been shown, the label is not redrawn. That is what I was asking:
[quote author="Andre" date="1317662722"]No, I think you read my reply a bit too quickly. That the palette is modified I will believe, but what I am wondering is if the widget is actually redrawn when you do this.[/quote]
Others have already explained why it is not a good idea. Personally, I find hard-to-read const casts more fuss than three clearly readable lines, but that is just me.
-
-
Why are you claiming this is a g++ issue?
I would be surprised if other compilers did not issue a similar error: Modifying a const reference is wrong.
Your "fix" by forcing it to be non-const is rather questionable though: It might or might not work, depending on how the widget is implemented, ruining the encapsulation OO design is all about.
-
->Franzk:
As for my inappropriate tone, let me tell you I am a bit tired of the patronizing
one of the forum' s divas. Now, I just suggested to add a few QWidget
functions allowing in one programming step to modify some palette settings.
It would translate in several function calls behind the scenes but would ease
programmer' s task.->Andre:
I have clearly stated that the label is not yet visible when this palette setting
is modified. Since you have established it does not work if the widget is
already visible, your method is clearly the right one although it remains
quite contrived due to the lack of QWidget functions doing the job in one
programming step.->Others:
Nothing.
-
You gave an opinion, someone else gave an opinion - so what's all this frenzy about here?
You decided to post on a public forum, so- you should be able to ignore or report posts you find improper or
- you should not post on public forums
There is a broad consensuns here at the QDN that rude behaviour and personal insults are not tolerated. Period.
As to your initial post: The compiler warning has been surpressed by an explicit cast. This is the behaviour I would expect. There is a reason const casts should be rarely used.
As to your suggestion: Rejected. The API already provides the requested functionality and the saving of two lines of code (at best) does not justify this redundancy. This would violate Qts API design principles. As already suggested I would create an inline function.
However, feel free to add the requested functionality and submit a merge request. This is how such discussions are usually solved here.
-
->Volker
-> Lukas GeyerInsults ? For a "Got it ?".
Our defintions of this word must be very different.
As for my "rude" behaviour, to quote you Mr Geyer,
it was triggered by the patronizing tone of most
answers to my posts. However I must admit your
last reply' s technical remarks (const_cast and API
design principles)make perfect sense.I just had a peek at your profile:
Congratulaions for having, and for so long, contributed
to such a great toolkit. -
->peppe
Sorry for my unbecoming remark.
-> Tobias Hunger (with some delay)
Mr Hunger,
I a am an Assembly language x64, APL and C programmer
but a newcomer to C++ and its design philosophy.
As for GUI toolkits, the only one I knew about was GTK +.
I dropped it because of its implementation of signals I don' t
like, to the say the least.
So, I was very surprised by g++ (legitimate) reaction
to my attempt to call setColor through a constant reference
to a QPalette. Realizing shortly after that it made sense but
considering I had the "right" to cast this thing. Well, since
g++ stopped complaining I thought it might be appropriate
to inform those likely to run across the same kind of problem
that my trick worked. It was my sole purpose. Now, it does
infringe QT design philosophy as you and Mr Geyer, among
others, pointed out.Congratulations for your continuing contribution to Qt.
-
Hi Quicksort,
[quote author="Quicksort" date="1317767499"]
I a am an Assembly language x64, APL and C programmer
but a newcomer to C++ and its design philosophy.
[/quote]that's an important information which will put your first post in a completely different context. I'm pretty sure, everyone here thought you were quite familiar with C++ and the concepts. So some of the answers could have looked a bit weird to you.
Anyways, if you want to read some good stuff on C++ features, I can recommend you the "C++ FAQs":http://www.parashift.com/c++-faq-lite - it's always a good inspiration. Not to forget to leave behind many of the concepts of assembly language or C (including casts!) when switching to C++ :-)
-
Thank you for your friendly post, Volker.
I will take a close look at these FAQs, I have a lot to learn...
Now, you might be, the case being, interested in Dr Agner Fog' s
manual about C++ optimization (from a programmer viewpoint,
it' s not about compiler writing).
I encourage everyone to visit his great website http://www.agner.org/.
You will find there various manuals and (free) software packages.
This man has an incredible knowledge of microprocessor architectures
and assembly language optimization. I owe him so much.Cheers.