Unsolved Is there any method of referencing each of the controls on a form?
-
@JonB said:
it offends my sensibilities to do 3 separate descents through the tree of 100
Fully agreed. What I meant was that
findChildren
does the tree traversal and casts each object to the type you give it (QWidget
here). It then copies them out to a list and then you traverse it again and do the casting to your target types. What I'm saying is in that case it's better to skip those casts and copying thatfindChildren()
does and traverse the tree yourself without copying and do the target casts directly, without theQWidget
cast mid-step. -
@Chris-Kawa
You're right. I'm too lazy to write the necessary for a recursivechildren()
example (I don't even do C++ these days!), so we'll leave that as an exercise for the potential interested reader ;) -
I'm too lazy to write the necessary for a recursive children() example
<tin foil hat on> Admit it. You're just an alien lizard in disguise trying to drain our batteries so we can't look at cat videos on a long distance bus trips :)
-
<tin foil hat on> Admit it. You're just an alien lizard in disguise trying to drain our batteries so we can't look at cat videos on a long distance bus trips :)
Whatever that is reference to I'm afraid it's completely beyond me? :(
-
@JonB said in Is there any method of referencing each of the controls on a form?:
<tin foil hat on> Admit it. You're just an alien lizard in disguise trying to drain our batteries so we can't look at cat videos on a long distance bus trips :)
Whatever that is reference to I'm afraid it's completely beyond me? :(
- Tin foil hat - The armour of choice for conspiracy theorists.
- Alien (from outer space) - A common subject among conspiracy theorists.
- Drain batteries - A consequence of a smartphone running inefficient code. Interferes with the smartphone's ability to play cat videos.
- Cat videos - One of the top productivity killers in today's society. Often consumed via smartphones.
- Long distance bus trips - A death trap for batteries that power smartphones that play cat videos. Can be counteracted by uber-modern busses that contain built-in phone chargers.
-
@JKSH
Errr, OK, but are you saying using a C-style cast will run out batteries?? ;-) -
@JonB said in:
but are you saying using a C-style cast will run out batteries?? ;-)
Well, to play devil's advocate - kinda yes. A C-style cast in C++ is not the same as a cast in C. The compiler does some logic to determine which type of C++ cast to do underneath, so while the end result in the binary is the same the explicit C++ cast is cheaper in terms of compilation overhead (whatever microscopic amount that is). So if you're compiling on a battery powered laptop - yes, technically C-style casts in C++ will drain your battery more :D
-
@Chris-Kawa
To play devil's advocate back: please give me any (correct) example of where a C-style cast (compared to, say,static_cast<>()
) could lead to battery-drain? Any example would do, I'm truly interested. Assuming you don't mean: a completely incorrect C-cast (like(int)some_struct
or anything like that). Because I can't think of one.... -
@JonB It was a joke. We might end it here :) But I'll play along:
int a = 42; float expensive = (int)a; float cheap = static_cast<int>(a);
The resulting binary and thus runtime performance are exactly the same. I meant compiler performance.
(int)a
makes the compiler check stuff to see which cast - const, static, reinterpret or some combination it needs to apply. Explicit C++ cast skips those checks so it's faster to compile. Again - It's not a difference that matters at all. It's extremely small so treat what I said as an (failed I admit) attempt at being funny. I bet glowing one pixel on your screen for a second takes more power than all the casts in your app. -
@Chris-Kawa
Oh, you mean compile-time battery power? I thought you meant run-time.(int)a
makes the compiler check stuff to see which cast - const, static, reinterpret or some combination it needs to apply.I could be wrong, but I think C-cast like
(int)a
always maps tostatic_cast<>(a)
, not the others.Explicit C++ cast skips those checks so it's faster to compile
I'll make a little bet with you. Compiling a C-style cast in a C compiler will be faster than a
static_cast<>
in a C++ compiler. Not that I'm saying you were comparing against a C-only compiler. Based on nothing other than my suspicions :) But your point taken. -
I'll make a little bet with you. Compiling a C-style cast in a C compiler will be faster than a static_cast<> in a C++ compiler.
I won't take that bet because I agree with you :) C is a lot simpler language to parse in general. Thinking about overload resolution alone leaves me no doubts that compiling the same code in C will always be faster than in C++. Again - talking about compile time performance, not runtime.
I could be wrong, but I think C-cast like (int)a always maps to static_cast<>(a), not the others.
It does in this case, but it needs to do the checklist anyway: explicit cast.
In case of something else, likeconst int foo = (const int)bar
it will map toconst_cast<const int>(bar)
.
I'm saying it's the logic to figure out which cast to use is the slow part.