[prosv5]C++ global variables create sequential problems

C++ global variables create sequential problems.
And it will cause some strange mistakes.
For example:
the motor does not rotate.
Unexpected runaway.
After the field control, the motor will shake.
In the field control mode, the robot will be out of control at random after the game.

Creating classes in autonomous () or opcontrol () can cost a little time to build and is not convenient.

My current solution plan is:

1.png

But the class coming out of NEW will run a little slower. I don’t know how much it will affect.
When there is no operating system, the stack is located at xdata, low speed access.
Do you have a better way?

Motors and other PROS objects are supported for global initialization on the latest kernel version. What version of the PROS kernel are you on?

Also, I notice you have a


main ()

function, which is not a supported construct.

1: version:
I have once shown that the system is a new version of the kernel, but the actual kernel is the experience of the old version.

1.png

2:This is just one of my implementation test procedures. He is the console program.

3 If I use new, how much slower will he be?

You are totally right that C++ has a huge issue with the order of static initializers. The issue isn’t limited to class instances, the issue (undefined order of initialization of static variables) is quite general.

As @edjubuh claims, PROS motor objects are implemented in a way to prevent initialization order issues, though that is primarily because they avoid keeping state, and that wasn’t always the case - PROS used to crash under some scenarios with global initializers.

Your approach of using pointers and initializing them explicitly under your control is sound (as long as you don’t try to access them before your init runs, but you have full control over that). Even better would be to avoid global state altogether (keeping everything owned by some kind of context object, say “class Robot”, which would abstract away the robot internals) - that isn’t necessary for the level of programming robotics student do, but is good to learn and instill better programming practices for life.

Using dynamically allocated objects (“using new”) has two associated costs, to allocate and to dereference. Both are totally negligible in given usage, but let’s look into them.

First, OS or not, the memory access speed is the same, no matter whether the memory is taken from stack (local variables), data section (global, static variables) or heap (allocated using new).

The allocation cost differs - global/static gets the memory reserved by the compiler at the compile time, no cost to get the memory, but still the same price to populate the memory with the data (constructor code).
Local variables get “allocated” pretty much by a single instruction (decrementing the stack pointer by the object size), while heap allocated objects could get a little longer to allocate, since there is quite some code running managing the heap - we’re still talking in fractions of a microsecond per allocated object though, and you’re allocating them only once at the start of the program anyway.

As for the access, the CPU has to access memory twice to start doing something with an object through a pointer (read the memory cell containing the pointer, then use that pointer to reach the object internals), while with globals, it typically needs only one access. But once you’re inside a member function, everything is the same. That is what makes the difference completely immaterial - the cost to traverse a pointer is much lower that the cost of the rest of a single function call.

Thank you very much for your professional and detailed answers.