Agfdhyk

I am trying to learn how to send data properly. Currently the way I do it is by creating a new array for each command.

unsigned char data0{ 0x00, 0x00 };

CommandSEND(handle, 0x01, 0x31, 0, 0, 2, data0);

CommandSEND(handle, 0x01, 0x31, 0, 0, 2, data0);

CommandSEND(handle, 0x01, 0x31, 0, 0, 2, data0);



unsigned char data1{ 0x01 };

CommandSEND(handle, 0x01, 0x31, 0, 0, 1, data1);



unsigned char data2{ 0x00,0x00 };

CommandSEND(handle, 0x01, 0x45, 0, 0, 2, data2);



// and so on... (i have data# variable going to data20)

I was thinking of using vectors, but the library that I am using, only accepts unsigned char arrays. Also whenever you change the size of the vector, it deletes the previous memory and copies it to a new location (Is what I believe is happening behind the scenes). Which I feel like is no different than me having many variables.

I have also been thinking of making my own class that would accept a char array. If I give it a different char array it would delete the previous array and add a new one. In this case would I need to call delete before assigning a new array to that same variable each time? Or should I call delete after I am done using that variable all together? (My guess is that I would need to call delete every single time, because I believe it would find new pointer each time I call syntax new)

I hope to have my code to run as fast as possible, hence I feel like if I keep deleting and assigning this would take time and that there might be a better, a more optimized way of doing it.

I want to learn to be able to keep my code well optimized.

Thank you, any tips and criticism is welcome.
Also wasn't sure whats the best title for this question would be.

Assuming that your code fragment is inside a function, you're already doing things almost quickly as possible. Your unsigned char array variables data0, data1 and data2 are automatic, which means they're "allocated" (and "freed") simply by adjusting the stack pointer on entry to (and exit from) the function -- there's no heap action happening.

Since the arrays have initializers, the compiler must have arranged for the arrays' initial contents to be stored in static memory somewhere, and on entry to the function, those initializers are copied to the appropriate areas on the stack where the automatic variables live. This copy is the only thing you might possibly optimize (somehow), but I don't see how you'd do it unless the last argument to CommandSEND was a const unsigned char *. If CommandSEND modifies that argument, then you'll have to re-initialize the arrays every time you enter the function.

Actually, although your comment says that CommandSEND modifies its last argument, you're calling it three times in the first stanza without re-initializing data0. So either you intend to send three (possibly) different commands in those three CommandSEND calls, or CommandSEND doesn't really change its last argument. Perhaps the library (and its header file) should be improved to offer better constness guarantees on its function prototypes. This is an example of where that might be important -- if the library could promise that the last argument to CommandSEND was const, then you could pass a static const unsigned char data0 as the argument. That would eliminate the initializing copy, and if there are no other automatic variables, then it's possible that the function entry and exit would be slightly faster. If all the commands you send are just a few bytes long, you could even write them as (const unsigned char *)"x12x34x56x78". Or, for clearer expression and better maintainability, you could define constants or preprocessor macros for the commands, and then say:

CommandSEND( handle, 0x01, 0x31, 0, 0, 2, FIRST_COMMAND );

CommandSEND( handle, 0x01, 0x31, 0, 0, 2, SECOND_COMMAND );

CommandSEND( handle, 0x01, 0x31, 0, 0, 2, THIRD_COMMAND );

Altogether, I don't think there's much opportunity for code-size or execution-speed optimization in this part of your program. You could certainly do some human-directed optimization, to make it easier to read or understand, but there's not much else you can do to help the compiler make it run faster. (And you shouldn't try to do that anyway until you've profiled the code and determined that this really is where your speed bottleneck is -- premature optimization is the square root of all evil!)