No an integral constant-expression error when creating a union data

Using Arduino Programming Questions
#1

I try to make a subfunction which can write any data formation (int, float etc) into eeprom so that one doesn't need to worry about low level operation such as creating union data formats when they call this subfunction.

As a result, I create a union data format in this subfunction, but the legnth of this union data can't be a int variable. cause when I do this variable.B[lengthOfData], it shows an error, saying lengthOfData is not an integral constant-expression. When I replace the lengthOfData with 2, it works fine.

Is there a way around this?

#2

What’s wrong with the EEPROM library’s get and put methods?

#3

I try to learn to write something usefull, and also contribute some day, instead of just include libs made by others, so I guess it is not reinventing the wheel...

#4

joedodo:
As a result, I create a union data format in this subfunction, but the legnth of this union data can't be a int variable.

The compiler needs to know the size at compile time and it cannot change during run-time.

You can define the size with a constant like this

constant byte arrayLen = 10;
int myArray[arrayLen];
byte myBytearray[sizeof(myArray)];

...R

#5

joedodo:
I try to learn to write something usefull, and also contribute some day, instead of just include libs made by others, so I guess it is not reinventing the wheel…

Reinventing an invisble wheel, it seems.

#6

joedodo:
I try to learn to write something usefull, and also contribute some day, instead of just include libs made by others, so I guess it is not reinventing the wheel...

It IS re-inventing the wheel, and replacing it with something inferior. A union is NOT the right solution.

#7

RayLivingston:
It IS re-inventing the wheel, and replacing it with something inferior. A union is NOT the right solution.

It may help the OP to explain what the right solution is ? ?

...R

#8

Robin2:
It may help the OP to explain what the right solution is ? ?

…R

see reply #1

#9

TheMemberFormerlyKnownAsAWOL:
see reply #1

I doubt that an inexperienced programmer would make that connection with Reply #5. Personally I assumed that @RayLivingston had some other solution in mind.

...R

#10

Robin2:
I doubt that an inexperienced programmer would make that connection with Reply #5. Personally I assumed that @RayLivingston had some other solution in mind.

...R

Nope. Get() and Put() are as good as it gets, do not need "improvement", work with any data type, don't waste resources on unions, and won't create processor-dependant problems unions will.

#11

RayLivingston:
Nope. Get() and Put() are as good as it gets,

My comment was not about the solution - I know nothing about the matter.

I was commenting in Reply #5 about the style of your Reply which seems to me to leave the OP dangling in mid air when it might have said " .... A union is NOT the right solution - see Reply #1"

...R

#12