I have a struct of doubles like so:
I want to be able to store it anywhere on the stack instead of using malloc or dynamic allocation on the heap (don't ask). I wish to know what would be the best datatype to use? It doesn't have to be the precise size, only larger, because it will be used for scratching using memcpy().Code:struct data { double x; double y; double z; } data;
Could I do this (?):
Code:char scratch[32]; data inst; memcpy(&scratch, &inst, sizeof(data));
When you define inst you are already assigning memory for it in the stack. There's no need to do anything else.Code:typedef struct data { double x; double y; double z; } t_data; #include <stdio.h> int main(void) { t_data inst; inst.x = 3.14; inst.y = 6.28; //.... printf("Values %f %f\n", inst.x, inst.y); return (0); }
> Could I do this (?):
Why, when you could do this.
No messy memcpy to get the size wrong.Code:data scratch; data inst; scratch = inst;
No guessing the size of the scratch buffer.
> I want to be able to store it anywhere on the stack instead of using
> malloc or dynamic allocation on the heap (don't ask)
So you prefer crashes without warning because you blew the stack because 'arbitrary large' got too large?
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Point is, I want to leave scratch as arbitrary storage variable instead of assuming to cast it as data from the outset.
But you can't have arbitrary large without some reference to all the kinds of data you might have.
If you start with this
That's all well and good.Code:struct data { double x; double y; double z; } data; char scratch[32]; data inst; memcpy(&scratch, &inst, sizeof(data));
But if you change things and forget the hidden dependency, you're screwed.
Sure, you can do this, which make sure scratch follows the size of data.Code:struct data { double x[2]; double y[2]; double z[2]; } data; char scratch[32]; // oops, this isn't big enough any more data inst; memcpy(&scratch, &inst, sizeof(data));
But that's just a complete hack over the much simpler.Code:struct data { double x; double y; double z; } data; char scratch[sizeof(data)]; data inst; memcpy(&scratch, &inst, sizeof(data));
Code:struct data { double x; double y; double z; } data; data scratch; data inst; scratch = inst;
I'm guessing you have many 'data' that you're not telling us about.
Consider
Code:struct data { double x; double y; double z; } data; struct data2 .... struct data3 .... etc // A union of all the possible things in your scratch will be // big enough to store any of them. union { unsigned char any[1]; data d0; data1 d1; data2 d2; } scratch; data inst; // do either of these scratch.d0 = inst; memcpy(scratch.any,&inst,sizeof(inst));
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
For an embedded application (or for any application for that matter) you have to make predetermined assumptions about variable sizes. For example fixed char sizes to store strings etc, which my program is also full of.
Incidently this particular example is for a temporary scratching buffer used in a bubble sort algorithm. Yes you are hardcoding the size of scratch in advance. I don't want to assume the exact type of storage in the algorithm because I may want to use it in other parts of the program (with other types). The idea was to look for a solution such that the variable would be local (on the stack) and easily discardable but at the same time be big enough to hold the anticipated data.
Thanks all for your replies.
OK, so let's start with qsort - C++ Reference as an example
Internally, qsort may call malloc to allocate it's scratch space (which I guess is why you don't want to use it).Code:T data[N]; // an array of N elements of T qsort(data,N,sizeof(T),compareFunc);
Perhaps revising the interface to allow a pointer to temp storage.
This storage will be the right size based on the known instance of what needs to be sorted.
Bubble sort is horrible to begin with, and worse still in an embedded environment.Code:T data[N]; // an array of N elements of T T temp; mysort(data,N,sizeof(T),&temp,compareFunc);
Sorting algorithm - Wikipedia
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
qsort is part of the C std. lib.
It doesn't use malloc(). It uses a similar type approach I described above.
I would prefer to reuse a pre-existing library if I could. But I am not using qsort because qsort only accepts an array of data, and I want to sort an array of structs instead according to data in specific locations of the structs.
There is nothing wrong with bubble sort nor an embedded environment.
So, you are ignorant of how qsort works!Originally Posted by wiqxlzxsxj
I suggest you find out if your embedded platform has qsort and then if it does find examples of using qsort of structures.
Tim S.
"...a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are,in short, a perfect match.." Bill Bryson
Oh dear oh dear oh dear.
My young apprentice still has much to learn.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Why are you babbling about things you obviously know absolutely nothing about? Are you a troll or just retarded?
A little inaccuracy saves tons of explanation. - H.H. Munro
There is plenty of evidence of retardation in this thread already.
How is this at all related to the original question? You could work around to fit in qsort(). But that isn't the priority here!
With all due respect I am not your apprentice. If you consider yourself to be in a teaching position then all you've done is to suggest workarounds to the original problem. This isn't an exercise to take a most polar opposite position possible regardless. The most effective solutions I hope you'll agree are the keep it simple stupid solutions. Now when I repeatedly said that I don't wish to specify a datatype for the storage explicitly, why am I going to make things more complicated and bundle a whole load them in a union instead?
Well for starters, you've never actually said what the real problem is.
Further, anyone who hasn't figured out that qsort can be used to sort anything, and also thinks there is no problem with a home baked bubble sort, definitely deserves the moniker of apprentice.
Meh, I've lost interest in your problem now.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
