Is there any method of referencing each of the controls on a form?

[Chris Kawa]

@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 that findChildren() does and traverse the tree yourself without copying and do the target casts directly, without the QWidget cast mid-step.

[JonB]

@Chris-Kawa
You're right. I'm too lazy to write the necessary for a recursive children() example (I don't even do C++ these days!), so we'll leave that as an exercise for the potential interested reader ;)

[Chris Kawa]

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 :)

[JonB]

@Chris-Kawa

<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? :(

[JKSH]

@JonB said in Is there any method of referencing each of the controls on a form?:

@Chris-Kawa

<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.

[JonB]

@JKSH
Errr, OK, but are you saying using a C-style cast will run out batteries?? ;-)

[Chris Kawa]

@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

[JonB]

@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....

[Chris Kawa]

@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.

[JonB]

@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 to static_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.

[Chris Kawa]

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, like const int foo = (const int)bar it will map to const_cast<const int>(bar).
I'm saying it's the logic to figure out which cast to use is the slow part.