Printable View
I have a structure with 10 plus items. For simplified purposes im just going to use 2.
I am trying to read the items from the structure using a variable and a loop.
is there any way of reading it like this?Code:for (unsigned i=0);i<2;i++) {
std::cout << structname->item + i << std::endl;
}
You mean you have something like this:
And now you want to read all the different fields using a loop?Code:struct blah {
char name[20];
int something;
double someother;
....
};
That's not trivial, and if they are different types (e.g. a mix of integer, char array, C++ strings, floating point), you are going to struggle to get the language to understand what you are doing.
If you describe a bit more what your structure looks like, maybe we can suggest something.
--
Mats
The structure is going to be all std::strings. Yes i know it can be used in a array, but in this case i must use a structure.
Code:struct blah {
std::string item1;
std::string item2;
std::string item3;
std::string item4;
std::string item5;
....
};
Realisticly, if you use a structure, then you have to read each item by itself. There are ways that you could for example build a list of offsets to the data in your structrure, and use a pointer to get the address of each element, but that would really make for some hard reading in the code, and it probably won't really help you do anything useful.
Of course, you could put an array inside the struct, if that's what is meaningfull to your code.
--
Mats
Thanks, i can't do it the way that i wish. I have to come up with something else.
One way, of course is something like this:
Does that make sense to you?Code:struct blah {
std::string item1;
std::string item2;
std::string item3;
std::string item4;
std::string item5;
....
};
...
blah var;
std::string *arr[] =
{
&var.item1,
&var.item2,
&var.item3,
&var.item4,
&var.item5,
...
};
...
for(i = 0; i < N; i++)
cin >> *arr[i];
...
--
Mats
Why not
?Code:struct blah
{
std::string item[5];
} mystruct;
for (int i = 0; i < 5; i++)
mystruct->item[i];
It IS possible to access each member of a struct not by its name, if all members are the same size and type, but that involves tricky memory manipulation and pointers.
And it relies on platform characteristics. It's not guaranteed by the standard to work.
Why is it that you cannot use an array within the structure? Otherwise we're just beating around the bush.
This is beating around the bush:
Code:struct bush
{
std::string item1, item2, item3, item4;
std::string & beat_around(unsigned short index) //we'll base it at zero, like an *cough* array
{
if(index > 4) throw SUX0R;
switch(index)
{
case 0: return item1;
case 1: return item2;
case 2: return item3;
case 4: return item4;
default: std::assert(no_way);
}
}
};
int main()
{
bush george;
fill_items(george);
std::cout << "Bush's third item: " << george.beat_around(2) << std::endl;
return 0;
}
I can't see how it's that. The compiler will create the structure and the compiler will keep track of where the members are positioned and the compiler will generate correct code to access them all. Otherwise arrays are useless.Quote:
Originally Posted by CornedBee
Perhaps
then later on, you can do things likeCode:std::map< std::string, std::string > thing;
Of course, both things can also be other string variables if you want.Code:thing["item1"] = "Barney";
Which post is this referring to, and in what way do you mean that it's not guaranteed.Quote:
Originally Posted by CornedBee
--
Mats
To the one by Elysia, directly above mine. She says something about accessing struct members by pointer instead of by name. That doesn't work portably, because the compiler may insert any amount of padding between the members.
Ah, it's tricky, but it can be done. Usually, the compiler pads to 4-byte boundaries, but you can force it to not to do that. And if you know that it aligns them to 4-byte boundaries, then it's still possible to do it with pointers given the type is 4 bytes, or you read X bytes, then skip Y bytes = 4 bytes.Quote:
Originally Posted by CornedBee
But arrays are different. They should work wherever.
That's what CornedBee meant. You can't do it portably; you have to assume things like structure padding. You shouldn't be writing code that relies on this sort of thing, unless you're doing something pretty unusual.Quote:
Ah, it's tricky, but it can be done. Usually, the compiler pads to 4-byte boundaries, but you can force it to not to do that. And if you know that it aligns them to 4-byte boundaries, then it's still possible to do it with pointers given the type is 4 bytes, or you read X bytes, then skip Y bytes = 4 bytes.
Indeed. Array elements have to occupy contiguous positions in memory.Quote:
But arrays are different. They should work wherever.
If you have a structure like this:
then it's easiest to use an array:Code:struct tag {
int x1, x2, x3;
};
On the other hand, if the members are of different types, then you can't create an array out of them. You could create a container to hold the different types, but whatever you're passing them off to has to be able to handle the different types of the members.Code:struct tag {
int x[3];
};
Anyway, just try an array and see how things go.
If I'm not mistaken, the compiler is responsible for the padding, not something else. You can force a compiler or set it in the options to set padding. Or you can just write a mechanism to parse memory and figure it out. Either way, it does become portable.Quote:
Originally Posted by dwks
And actually, I have once written something "unusual" that does something like this...
I was writing a small library for DirectInput w/ action feedback or whatever it's called. The program registered what keys it wanted to intercept and passed along a struct of bool values and the number of keys it has registered, that were set to true if key was pressed down and false if not.
Since the library had no idea of the contents of the struct, I used a raw memory approach. If key 4 was pressed, set beginning_of_struct + 4 to true, and so on.
Why did I do this? Why not an array or something? The approach to this is that the calling program can define the structure however they want as long as there's one member for each key. Then you can name the members whatever instead of a generic "bool key4;"
That's right -- "the compiler is responsible for padding". So any code you write that assumes something like this will be unportable, reliant on compiler settings. Sure, on practically any compiler you can set this sort of thing, but it's an extra step involved. Your code doesn't compile out of the box on a new compiler.Quote:
If I'm not mistaken, the compiler is responsible for the padding, not something else. You can force a compiler or set it in the options to set padding. Or you can just write a mechanism to parse memory and figure it out. Either way, it does become portable.
As far as I can see, it didn't help any. You'll have to explain a bit more, but I think you were using something like thisQuote:
And actually, I have once written something "unusual" that does something like this...
I was writing a small library for DirectInput w/ action feedback or whatever it's called. The program registered what keys it wanted to intercept and passed along a struct of bool values and the number of keys it has registered, that were set to true if key was pressed down and false if not.
Since the library had no idea of the contents of the struct, I used a raw memory approach. If key 4 was pressed, set beginning_of_struct + 4 to true, and so on.
Why did I do this? Why not an array or something? The approach to this is that the calling program can define the structure however they want as long as there's one member for each key. Then you can name the members whatever instead of a generic "bool key4;"
I'd guess you did that so that the mystery members could be named whatever the user wanted, right? Well, it still restricts the user to a data type that could fit into 4 bytes (or whatever the padding is).Code:struct something {
bool mystery_member_1;
bool mystery_member_2;
bool mystery_member_3;
};
something s;
*(&s + 4) = 2; /* to set mystery_member_2 */
Plus, if you just wanted custom names, then you should probably be using an interface to access the data. Abstract away the names.
Or if you really really wanted to do it, then you could have done something like this:
In other words, use the preprocessor to map some custom name to whatever the real name is. I've seen this done before. And while it's not the best programming practise, I would certainly consider it better than code that relies on fixed structure padding.Code:struct something {
bool _something_1;
bool _something_2;
};
#define _something_1 nonmystery
[edit] Another alternative would be to use unions to define custom names, possibly in conjunction with the preprocessor or whatever.
[/edit]Code:struct something {
union { bool key1, num1, one; }
union { bool key2, num2, two; }
};
[edit=2] Besides, let's take a step back here. You're already restricting the user to a specific order of members. How much more difficult is it to do this?
Then the user can useCode:struct something {
bool data[4];
};
or something of the like. Why should you care what they call the variables? You've given them one name: data[2]. If they don't like it, well, then they can change it.Code:#define nonmystery data[2]
By your argument, if the user hated your names so much, and they were restricted to a certain order and type of arguments, it wouldn't be difficult to do this.
[/edit]Code:struct their_names {
bool data[3];
};
struct my_names {
bool one;
bool two;
bool three;
};
struct their_names theirs = their_function();
struct my_names mine = (struct my_names)theirs;
bool one = ((struct my_names)theirs).one;
bool two = mine.two;
Boost.Fusion has mapping mechanisms from user structs.
But there should also be a way to force padding by a pragma. Though I'm not sure such a pragma exists on all compilers, or even if it's part of the standard.Quote:
Originally Posted by dwks
But then again, many project modify compiler options and requires them to be changed to compile so setting padding in those projects isn't that much of a problem, but I do agree that it isn't usual practice and might be avoided.
Here is an example:
And there you go, showing how appropriate it sometimes can be. Of course it's also possible to declare a struct with one bool array, it's just a matter of preferance.Code:struct KeyStruct
{
bool bKeyStart;
bool bKeySelect;
bool bKeyDoSomething1;
bool bKeyDoSomething2;
};
int main() // Some function in your app calls the library
{
KeyStruct Keys;
// Register all your keys here...
GetKeys(&Keys, 4); // Also pass along how many keys you would have registered in this example
// Do something with your new information
}
void GetKeys(BYTE* pStruct, int keys)
{
// Get data somehow
bool bSet = true, bCleared = false;
/* If key 1 was pressed */ memcpy(pStruct, &bSet, 1); else memcpy(pStruct, &bCleared, 1);
/* If key 2 was pressed */ memcpy(pStruct + 1, &bSet, 1); else memcpy(pStruct + 1, &bCleared, 1);
/* If key 3 was pressed */ memcpy(pStruct + 2, &bSet, 1); else memcpy(pStruct + 2, &bCleared, 1);
/* If key 4 was pressed */ memcpy(pStruct + 3, &bSet, 1); else memcpy(pStruct + 3, &bCleared, 1);
}
But your other solution - to pass a struct and then copy it would be a waste of memory and time IMO, since I don't like copying memory when possible. Also, passing a predefined struct, you'd have to have a dynamically created array in it since the amount of keys can vary.
So either we use a pointer and new or we could use a class like CArray or something.
#pragma is, by definition, compiler-specific. I don't think there are many, if any, #pragmas that are defined by the standard, and structure padding certainly isn't one of them.Quote:
But there should also be a way to force padding by a pragma. Though I'm not sure such a pragma exists on all compilers, or even if it's part of the standard.
But then again, many project modify compiler options and requires them to be changed to compile so setting padding in those projects isn't that much of a problem, but I do agree that it isn't usual practice and might be avoided.
Use the cast version, then. Unless you think that looks ugly, in which case use this.Quote:
But your other solution - to pass a struct and then copy it would be a waste of memory and time IMO, since I don't like copying memory when possible.
I mean, come on. There are so many ways to do it. You shouldn't need to use undefined structure behaviour to get it done.Code:struct their_names {
bool data[3];
};
struct my_names {
bool one;
bool two;
bool three;
};
#define mine(theirs) ((struct my_names)theirs)
#define reallymine ((struct my_names)theirs)
struct their_names theirs = their_function();
struct my_names minep = (struct my_names *)&theirs;
bool one = mine(theirs).one;
bool two = reallymine.two;
bool two2 = minep->two;
... so how is the original user, who defines their own structure, supposed to go about things? Do they dynamically create a different structure definition depending on which members they want to use?Quote:
Also, passing a predefined struct, you'd have to have a dynamically created array in it since the amount of keys can vary.
[edit] Aha, I have it! C++-only, but what the heck.
[/edit]Code:struct their_names theirs = their_function();
struct my_names &mine = (struct their_names)theirs;
Ah, that's sad...Quote:
Originally Posted by dwks
Yes, I suppose it's possible, but it still relies on the same trick: memory manipulation.Quote:
Use the cast version, then. Unless you think that looks ugly, in which case use this.
I mean, come on. There are so many ways to do it. You shouldn't need to use undefined structure behaviour to get it done.Code:struct their_names {
bool data[3];
};
struct my_names {
bool one;
bool two;
bool three;
};
#define mine(theirs) ((struct my_names)theirs)
#define reallymine ((struct my_names)theirs)
struct their_names theirs = their_function();
struct my_names minep = (struct my_names *)&theirs;
bool one = mine(theirs).one;
bool two = reallymine.two;
bool two2 = minep->two;
Thinking on it, I believe it's possible with another approach, such as a map.
But the point is to show it's possible to interate through member variables in a struct without using the member names.
They create on struct and use it. Because you only register what keys you want to capture once. Your app creates a struct like you want it to look like, with one member for each key. It's a dynamic structure to the library. Knowing how many keys there are, it can fill out the struct for you.Quote:
... so how is the original user, who defines their own structure, supposed to go about things? Do they dynamically create a different structure definition depending on which members they want to use?
(Did that make sense?)
But in this case, as long as the members of the structure are of the same type, it's reasonably well defined memory manipulation.Quote:
Yes, I suppose it's possible, but it still relies on the same trick: memory manipulation.
Sure, but that's going to kill your efficiency pretty quickly. Copying a structure would take a fraction of effort. (You'd have to store the names of the structure members as strings or at the very least enumerated values of a sort . . . .)Quote:
Thinking on it, I believe it's possible with another approach, such as a map.
Unless you don't mean a standard std::map. But in any case you'd need some sort of lookup system.
Actually, the best way that I can think of to implement a lookup system of this sort would be to use something like this. :)
Efficiently, that is.Code:struct something {
bool data[3];
};
#define nonmystery 2
void get_data(struct something &s, int array_element);
Sure, it's possible. But I'm saying that it's an exceedingly bad idea almost all of the time.Quote:
But the point is to show it's possible to interate through member variables in a struct without using the member names.
Not really. It sounds like you have, say, 256 keys, and the user says "I want to handle 65, 66, and 32."Quote:
They create on struct and use it. Because you only register what keys you want to capture once. Your app creates a struct like you want it to look like, with one member for each key. It's a dynamic structure to the library. Knowing how many keys there are, it can fill out the struct for you.
(Did that make sense?)
If that's the case, I'd consider using something like this:
[edit] In other words, here's why I think you shouldn't use integral offsets from the beginning of a structure to allow the user to name the members of the structure however they like.Code:struct something {
bool data[256];
};
struct mine {
bool one, a;
};
struct something internal_something;
void register_key(bool *b, int n) {
*b = &internal_something.data[n];
}
register_key(&mine.one, '0');
register_key(&mine.a, 'a');
[/edit]
- The user probably won't mind using your names, as long as you pick them well.
- If they want to use their own names, they can copy their own structure;
- or, if they're concerned about memory efficiency, use #defines, or references.
Yes, such as that. Though I tend to use CMap.Quote:
Originally Posted by dwks
But you can't rename the members, which was the point.Quote:
Actually, the best way that I can think of to implement a lookup system of this sort would be to use something like this. :)
Efficiently, that is.Code:struct something {
bool data[3];
};
#define nonmystery 2
void get_data(struct something &s, int array_element);
Yes, bad it may be, but it's possible :pQuote:
Sure, it's possible. But I'm saying that it's an exceedingly bad idea almost all of the time.
That's not necessary since that's what action feedback is for. You tell DI what keys you want to capture and it reports only events when the those keys are pressed and released.Quote:
Not really. It sounds like you have, say, 256 keys, and the user says "I want to handle 65, 66, and 32."...
So a user can create a struct like
...That is used all throughout the app. Another app might use a different struct:Code:struct KeyStruct1
{
bool bKeyStart;
bool bKeySelect;
bool bKeyDoSomething1;
bool bKeyDoSomething2;
};
...But it will still work just fine.Code:struct KeyStruct2
{
bool bKeyStart;
bool bKeySelect;
bool bKeyDoSomething1;
bool bKeyDoSomething2;
bool bKeyDoSomething3;
};
The app can create the struct to look however it wants. It can even merge two or more keys into a WORD or an UINT. The library won't care and plot one byte for each key.
And the app can even change struct abruptly if it wants (like from KeyStruct1 to KeyStruct2) without negative effects.
And if an app doesn't want all that data captured all the time, it can just ignore those member variables which contain their state.
Another unportable construction? ;)Quote:
Originally Posted by Elysia
I never said it wasn't. Or if I did I didn't mean to.Quote:
Yes, bad it may be, but it's possible :p
See below.Quote:
That's not necessary since that's what action feedback is for. You tell DI what keys you want to capture and it reports only events when the those keys are pressed and released.
So a user can create a struct like
...That is used all throughout the app. Another app might use a different struct:Code:struct KeyStruct1
{
bool bKeyStart;
bool bKeySelect;
bool bKeyDoSomething1;
bool bKeyDoSomething2;
};
...But it will still work just fine.Code:struct KeyStruct2
{
bool bKeyStart;
bool bKeySelect;
bool bKeyDoSomething1;
bool bKeyDoSomething2;
bool bKeyDoSomething3;
};
The app can create the struct to look however it wants. It can even merge two or more keys into a WORD or an UINT. The library won't care and plot one byte for each key.
And the app can even change struct abruptly if it wants (like from KeyStruct1 to KeyStruct2) without negative effects.
And if an app doesn't want all that data captured all the time, it can just ignore those member variables which contain their state.
Why would you want to rename structure members anyway?Quote:
But you can't rename the members, which was the point.
Here's what I think. You want to create something so that the user can name the members of their structure. You don't want to create references to the members or copy a structure or use a lookup table or one of the many other valid solutions. You want to let the user name their own structure members. Very well. What's wrong with this?
It lets the user create their own structure. It doesn't take much extra memory (one reference, which can probably be optimised away). It doesn't rely on undefined practises -- it's defined for any and all standards-compliant compilers. It doesn't use the preprocessor.Code:struct my_names {
bool one, a;
};
struct internal {
bool _internal_data_0;
bool _internal_data_1;
};
void process_structure(void *p) {
struct internal &data = *(struct internal *)p;
data._internal_data_0 = 0;
}
struct my_names mine;
process_structure(&mine);
print_int(mine.one);
Its only drawback is that you can't access the members of the internal structure as an array. You could use this
but I think that's just as bad as your code, assuming that there's no structure padding at all.Code:struct internal {
bool _internal_data[2];
};
But wait a minute here. Why not just use an array in the first place?
Then, if the user wants to use their own names, they can make up constants like ONE=0. This is quite a few advantages. It will use less memory, unless with you're structure you're using every possible byte and thus have in effect no padding. It's easy for you to handle. It's easy for the user to handle, with your names, constants, or their names.Code:bool array[2];
If you need more data then you can stuff into an array, use a structure.
We've come in a full circle . . .Code:struct data {
bool x;
};
struct everything {
struct data data[2];
int other;
};
Please, tell me. Why would you be willing to risk portability to let the user use their own names? It's your library. If they don't like your names, they can deal with it, with #defines or structures or maps or references. And if you want to allow the user to create their own names, you can use these techniques yourself. There's no reason that I can see to use a possibly shady coding style when alternatives exist.Code:struct something {
bool data[256];
};
Besides, your method isn't perfect either. The user is restricted to the order of their variables.
You can do this without involving structures.Quote:
The app can create the struct to look however it wants. It can even merge two or more keys into a WORD or an UINT. The library won't care and plot one byte for each key.
And you can't do it in your example. You know why? Because of structure padding. If you translate thisCode:char x = 1, y = 2;
short both = x | y << CHAR_BIT;
to thisCode:struct x {
small one, two;
};
then both has to contain x + x's-padding + y + y's-padding. And part of it will be undefined, 'cause you don't set every byte, do you? Just every fourth, or whatever. (Easily fixed with a memset, of course.)Code:struct y {
large both;
};
If you're just setting a bunch of values of the same type, use an array. That's what they're for.
If I saw a library like yours, I'd think "What was this designer thinking?" It's just complicated, unreasonably so. But if I saw a library that stored keypresses in an array, I'd know exactly how to handle it.
I may be repeating myself, but... I did mention there may be other ways to do it. You've mentioned several. And very good ones, too. My initial spark argument was that it can be done, not about how to do it :p
As for the question of why doing it, it's because it will make the code more readable. That's the whole point! And also, to avoid thinking "WTF? What did data[6] do?" ;)
Right, okay. It can be done. It might be a bad idea, it might be unportable, there might be better ways to do it -- but it can be done.
I don't think arrays would be less readable. You wouldn't use data[6], you'd use data[SDLK_RIGHT]. ;)
Arrays with a generic name might be "unreadable" since you have no idea what data is stored in them :pQuote:
Originally Posted by dwks
But you're right that you can sidestep the problem!
And remember, the reason why we don't name variables everywhere a, b, c, etc is because we want to know what they're used for so a fitting description is a good or else we may be come confused!
Right, so you say that "right" is more readable than 4. I agree. But there's no reason you can't use an enum or something to give it the name "right". If you do this, you still get all of the advantages of using an array -- little memory usage, ease of handling with standard functions like memmove(), iteration with a for loop if you choose.
In other words, you can let the user go "left, right, up, down", which might be more readable in many cases. But in others, using array[0] ... array[3] would be better, for loops or transferring all the data at once. Or whatever. If you use an array, the user can use either method (iteration or naming). If you use naming, they're stuck with it.
Your argument, of course, would be that you've designed it so that the user can use "int left, int right, int up" or "int array[3]" -- so they get to choose. It's just as good as using an array, because you can use an array if you want or names if you don't.
But that argument falls apart, because the only way you can declare an array in a structure and have it work is to take into account structure padding. For example,
with 4-byte padding and 4-byte longs. You're wasting memory. Plus you're not using the data type you were looking for.Code:struct everything {
long data[4];
};
Okay, so then do this.
But you're still wasting memory. ;)Code:struct omnibus {
struct data {
bool x;
} array[4];
};
So I think this: an array is better than a structure, in general, if you could use either -- for these reasons:
- Arrays might use less memory, and certainly not more.
- A structure might involve undefined structure padding issues.
- You can iterate over arrays, while to do this with a structure you need an array anyway.
- You can access array elements by name easily, with defined constants or maps. It's certainly not much harder than using structure members.
- Arrays are more traditional for this sort of thing. You have a bunch of variables of the same type. What do you use? An array. So this is what other programmers would expect.
At least in this case.
I suppose it all comes down to this. How badly do you want to use structure.member as opposed to array[element]?
If you're really fanatic, create a class.
There are so many possibilities . . . :)Code:class data {
public:
int array[4];
};
class mine : public data {
public:
int one() { return array[0]; }
};
I don't care! :p My argument has finished... and all it was was that it was possible to enumerate members of a structure without knowing their names or even if they have different names in a loop, which we've also concluded is bad and unsafe.
If anything, I'd use a map. Probably map string to pointer, with each "key name" pointing to a local (or global, or whatever) variable.
Right, argument over. Oh well. I haven't had one like that for a while, it was interesting. :)
But that would be inefficient compared to <forcibly stops typing> :DQuote:
If anything, I'd use a map. Probably map string to pointer, with each "key name" pointing to a local (or global, or whatever) variable.
A map has other advantages over other methods. For example, the keys can be dynamically generated, by reading from a file for example.
What you use depends on what you want to do. And how portable you want your program to be. :)
[edit] 5,300th post! [/edit]
Yes, it quite certainly was!Quote:
Originally Posted by dwks
I don't care! :p It's allows whatever-you-like variable names and it's safe to use, and portable too (or should be anyway).Quote:
But that would be inefficient compared to <forcibly stops typing> :D
Yes, very portable, safe, and good. :)
Maybe you could lend some of your structure-member-accessing-by-offset expertise here . . . http://cboard.cprogramming.com/showthread.php?t=94972
Unfortunately, I think most about the structures has been said already... I can't think of a portable solution right now, either... Unless it's possible to use unions to group together chars, but I'm not too knowledgable about them.
Sorry, it's not.
Basically, as far as the standard is concerned, the ground rule is that if you access anything through a different type than it actually is, it's undefined. The only two exceptions are where
1) we're talking about base and derived class pointers/references and
2) we're talking about the extremely elusive structural conformance concept. Which is really still about the type being the same, but as members of different structures. And there are very stringent restrictions on these structures.
I'm thinking of the unions that are usually declared (and used by) Windows API in its headers:
If it's possible to declare all the members are char, then you might be able to avoid padding (at least until the end), while still being able to access the data through members with other type. Dunno if it's possible. Otherwise I can't think of another solution than to force padding.Code:typedef union _ULARGE_INTEGER {
struct {
DWORD LowPart;
DWORD HighPart;
};
struct {
DWORD LowPart;
DWORD HighPart;
} u;
ULONGLONG QuadPart;
} ULARGE_INTEGER,
*PULARGE_INTEGER;
That union is fine as long as two DWORDs does not require a different alignment than a ULONGLONG. Which holds true as long as the machine can handle DWORD without it being aligned to anything bigger - which again holds true for all machines that currently can (or in the past have been able to) run Windows. By the way, unportable constructions are VERY common in header files that belong to the OS - because they can rely on the OS and the compiler having to adhere to certain standards.Quote:
Originally Posted by Elysia
--
Mats