std vector, QVector and fields..

[Chris Kawa]

@JonB said:

I would guess the overhead is in milliseconds

I work in game dev, where we have 16ms (or 8, depending on an FPS target) to do friggin' everything, so with a statement like that you wouldn't get very popular here :) Not every field has those restrictions of course, but just because you don't have to doesn't mean you shouldn't self-impose those restrictions on yourself even in a more relaxed environment.

My point is that it's not about what you or the user can see or touch. We're waaaay past that perception point in simple uis. For all a user cares you can use a QMap with QString keys and tripple pointer indirection and no one would be able to tell (that's kinda what findChildren does actually + some casts and branches). But the CPU does the work none the less. It spins those cycles, it takes that electricity, it eats that battery away, it uses up that cache causing evictions to other processes and causing them to use just a little bit more resources. It makes everything else on the system just a little bit more sluggish every time. Given that a random PC is running dozens or hundreds of processes and threads at any given time if everyone coded like this we would be in a very bad place. I hate that every little update and every little app installed makes my PC just a tiny bit slower. It amounts. Nothing runs in isolation.

no kittens, fluffy or otherwise, are harmed in the course of running my application

that you know of, but if what you're saying is true... they die man, they die ;)

I say this hopefully not to fight with you but because it may relate the situation the OP is asking about.

I hope what I'm saying doesn't come across as fighting. All good here. Just trying to raise awareness of those things because with the rise of the various VMs and interpreted languages performance and battery life are getting destroyed across the board the last few years and it just kills me (along with the kittens) to witness it. I just can't stand that "it doesn't matter, hardware will pick up the slack" programming culture that's on the rise. Don't want to be a silent bystander so I'm bitchn' a bit.

[J.Hilk]

@JonB said in std vector, QVector and fields..:

I need to apply some initial changes to all of them, to do with aligning, coloring. delegating & connecting slots.

You know, if all those operations are constexpr-able you could do them during compile time!
Ha dreams 😥

[JonB]

@J-Hilk
Not sure what you mean. Even if they are, the question we are debating is: how do you apply them across 47 design-time (non-subclassed) separate QSpinBoxes? And maintain for future ones which might be added? I'm not prepared to write it against 47 member variables, if I put them into a list/array/vector I have to write/maintain that which equally I don't want to do, so leaves me with QObject::findChildren<QCheckBox *> as the easiest way to implement. Which @Chris-Kawa has informed me will kill my beloved pussy cat, so I feel terrible :(

[J.Hilk]

@JonB
you said

I need to apply some initial changes to all of them

which means, you know (theoretically) during compile time what your values should be.

Now, if all your functions on QCheckBox were constexpr and find children would be as well, you could create a small constexpr function of your own, that finds all QCheckBox and sets the initial values and call that somewhere early on. The compiler would evaluate those calls during compile time and set the initial values accordingly without runtime overhead.

---

no kittens required to die, in fact you would have more time, due to longer compile times, to pet them

[JonB]

@J-Hilk said in std vector, QVector and fields..:

you could create a small constexpr function of your own, that finds all QCheckBox

Not that I can imagine doing this, but could you give an example of how I would do this, at compile-time? Or is that based on a hypothetical "if all your functions on QCheckBox were constexpr and find children would be as well"? I don't follow how you would get a list at compile-time of all QCheckBoxes I have created in Designer (without my having to type that into the source code manually)?

[J.Hilk]

@JonB it is hypothetical, because I'm pretty sure setupUi is not constexpr

but as example, take this compiletime calculation of fibonacci

constexpr int64_t fibonacci(const int64_t  n)
{
    return n < 1 ? -1 :
        (n == 1 || n == 2 ? 1 : fibonacci(n - 1) + fibonacci(n - 2));
}

int main (int argc, char *argv[])
{
    constexpr auto evaled = fibonacci(25);
        return evaled;
}

actually had to modify the example to force the compiletime evaluation , a little bit finicky the whole system (still)

[JonB]

@J-Hilk
OK, yes, I know about turning the C++ compiler into an interpreter with constexpr :) But that fibonacci function is self-contained. Compiler is not going to be able to execute anything like constexpr QObject::findChildren<QCheckBox *>, it's runtime-only.

Purely BTW. I'm not a great programmer (nor mathematician), so while I develop my code I have a go at:

constexpr int64_t fibonacci(const int64_t  n)
{
    int64_t result = 0;
    while (n > 0)
        result += n;
    return result;
}

Now I compile my code. Does the compilation simply hang??

[jsulm]

@JonB said in std vector, QVector and fields..:

Now I compile my code. Does the compilation simply hang??

No, because you're not calling it :-)
And it would not hang if you would call it with any number as parameter. It could probably slow down compilation if you would pass a huge number :-)

[JonB]

@jsulm
Oh yes I am! In @J-Hilk's code (at least originally) his main() calls fibonacci(10), so assume that, and then tell me what happens while I sit waiting for the compilation to finish?

And it would not hang if you would call it with any number as parameter. It could probably slow down compilation if you would pass a huge number :-)

I think you should look at the code again... :)

[jsulm]

@JonB OK, I see n > 0. You should try :-)

[J.Hilk]

@JonB Add at least a function call to your calculation, then you get an stack overflow(eventually)

[JonB]

@jsulm

You should try :-)

I'm terrified of seizing up my Linux VM :) It already does that if I accidentally debug from Creator when inside a QComboBox clicked slot, and I have to hard-switch-off the whole VM... :(

[J.Hilk]

@JonB

main.cpp:158:18: error: expression is not an integral constant expression
main.cpp:152:13: note: constexpr evaluation hit maximum step limit; possible infinite loop?
main.cpp:158:18: note: in call to 'fibonacci(25)'

smart things these compilers

[JonB]

@J-Hilk said in std vector, QVector and fields..:

@JonB Add at least a function call to your calculation, then you get an stack overflow(eventually)

But I don't want a stackoverflow to terminate! I want to know whether the compiler sits there forever! Which is why I wrote as I did.

OK, I'm off to try....

[JonB]

@J-Hilk said in std vector, QVector and fields..:

note: constexpr evaluation hit maximum step limit; possible infinite loop?

Ah ha! So..... this C++ constexpr has what "maximum step limit`? Where is that in the spec? :)

[J.Hilk]

@JonB up to you with the compiler option -fconstexpr-steps

[JonB]

@J-Hilk
Wow! They think of everything! I wonder if that would accept -fconstexpr-steps fibonacci(25) ;-)

OK, enough now, thanks!