Copying one struct to another

VEX V5 Technical Support UNOFFICIAL Tech Support
1

I have code which lets me “queue” a bunch of drive functions in a non-blocking way. I can add to the queue fine, but unexpected stuff happens when I try to shuffle the queue down (after a move has been completed). The unexpected stuff is that only the


type

is copied, while the


speed

and


distance

are left behind. Copying each variable in each struct fixes this.

This sets up the queue


// has everything the task needs to do one move
typedef struct _autoDriveMove {
    TautoDriveFunction type;
    int speed;
    float distance;
} TautoDriveMove;
TautoDriveMove autoDriveQueue[10];

This doesn’t work (only the type gets copied):


// shuffle queue down one
for (i = 0; i < autoDriveQueueLimit - 1; i++) {
    //autoDriveQueue* = autoDriveQueue*;
}

This works:


// shuffle queue down one
for (i = 0; i < autoDriveQueueLimit - 1; i++) {
    autoDriveQueue*.type = autoDriveQueue*.type;
    autoDriveQueue*.distance = autoDriveQueue*.distance;
    autoDriveQueue*.speed = autoDriveQueue*.speed;
}

And after searching more, this also works:


// shuffle queue down one
for (i = 0; i < autoDriveQueueLimit - 1; i++) {
    memcpy(&autoDriveQueue*, &autoDriveQueue*, sizeof(autoDriveQueue*));
}

Is this how it is supposed to work? These links say the first way should work: source1**********, source2, source3 (which gave me the


memcpy

option). *

2

RobotC ≠ ANSI C

Lots of things work in ANSI C that don’t in RobotC, especially with things like structs that newer programmers are unlikely to even remotely touch.

I would advise switching to PROS for serious struct usage, but, as you found, RobotC will often cooperate as long as you don’t mind less elegant code.

Edit: I just realized that was your thread that I linked…

3

Using memcpy is an acceptable method to achieve this. Like the poster above suggests RobotC isn’t real C and if you’re starting to manipulate memory directly then PROS or ConVEX are a better choice.
You could also perform the shuffle in 1 memcpy too provided the struct was declared packed so you can guarantee sequential bytes in memory are used. attribute((packed)) which I don’t believe is a robotC feature although jpearman may well enlighten us.
Another approach is using pointers to make a linked list then keep track of the head and tail with pointers (I’m assuming you don’t need random access to the sequence, just add and remove). Linked lists - Learn C - Free Interactive C Tutorial for a quick overview of linked lists although it is storing data in the heap rather that statically but you’ll get the idea.

4

Yea, that’s not a ROBOTC feature, I’m not even sure it’s a standard C feature.

You have to remember that ROBOTC is similar to C but is really its own language. It also has some C++ style features, for example, function overriding is not standard C but is supported in ROBOTC.

Have a read through the old programming tips thread for more insight. Some of this thread was written before all of the existing functionality was implemented, so ignore any discussion about lack of pointers etc.
https://vexforum.com/t/sprocket-and-chain/14951/1

5

You could also keep a separate array of different, ordered integers. You use the numbers in that array to tell you which of your autoDriveQueue to go to. You just reorder that array of integers. This also had a huge advantage when it comes to large things. If each autoDriveQueue has a lot of information, you’re copying a lot of stuff every time. If you just change one array of integers (or short if you’re really worried about tiny bits), there isn’t much to move around.

(Basically, just an alternative to pointers if you’re avoiding them.)

6

Can you even do linked lists in ROBOTC? I’m quite happy with just


memcopy

ing my struct (because it’s really small, and will be shuffled less than once every 10 secs). Linked lists - Learn C - Free Interactive C Tutorial gives examples using


malloc

, which isn’t available in ROBOTC.

7

ROBOTC has pointers so you can [probably] do a linked list but tbh I wouldn’t recommend spending time on that. Rather than using dynamic memory allocation with malloc (no that’s not a ROBOTC feature as you say) just allocate memory at compile time with an array of structs like you’re doing now except you’d need to initialize the NEXT pointers at run time before using the linked list. Not exactly slick but possible and from an actual code execution perspective identical to the normal approach since ultimately we’re just addressing memory locations. Investigate PROS and ConVEX since they’re using a real C (and potentially other languages too) compiler rather than the sand boxed ROBOTC interpreter. Check carefully what the heap memory allocation is though since the EDR Cortex is somewhat limited. There’s nothing wrong with ROBOTC but less constrained compiler options are available once you start hitting sand box edges.

8

Here’s a linked list example I posted about 5 years ago when pointers were first available in ROBOTC.
https://vexforum.com/index.php/conversation/post/76768

9