Store data from a struct on another struct - c

Im doing something like a supermarket simulator using C. I have a struct that keeps data from hundreds of fictional clients like so:
typedef struct clients {
int ID;
char Name[50];
}Clients;
I imported a .txt file containing these clients. It basically looks like this:
1234 Peter Parker
4724 Barack Obama
3851 John Wick
9428 Donald Trump
...
So now I have to simulate a supermarket, i have a timer that updates itself, picking random clients from the struct and put them inside the supermarket, i need to keep track how many of them and which of them are inside the supermarket. The thing is, i don't know how to like put the clients inside the market and store the data of those clients. For example, imagine client A and B enter the supermarket, how do I store those specific clients in the market, so that like i could search which of them are inside the market? Should I make a struct containing data from the struct Clients? I have no idea. Glad if you could help me.

You can create an array of your clients struct.
Here are some resources I found.
http://www.asic-world.com/scripting/structs_c.html
http://www.c4learn.com/c-programming/c-array-structure/

The answer is that there are many ways to do this, with pros and cons to each. If you care about performance and your data gets larger than hundreds and into the upper thousands then you probably start worrying about what type of data structure you're using, which then becomes a question about data structures and how you'll be searching for the names. If you're not so worried about performance, you can go for an array implementation where you create an array of Clients like so: which declares an array of 200 clients that you can assign values to.
Clients array[200];
The down side of this is if you get more Clients than you've allocated memory for, you'll have to either malloc more memory to fit it.
Alternatively you can go with the linked list implementation and create some sort of struct that represents a node with corresponding functions to manipulate it.
typedef struct {
Client *client;
node *next;
node *prev;
} node;
But this would require writing more code to add and remove nodes at minimum.
So, its really question of what YOU want.
EDIT:
If you just want to add a way of knowing if some client is in the super market why not create an enum and add it into the client struct? I prefer this over bool because then if you want to put someone in another place in the future, then you have the option to just add it to the enum.
enum place {
supermarket,
none
};

First thing that comes to mind is to use some kind of directed (or bidirected) list containing references to your Client structure. For instance,
typedef struct {
Client *client;
Visitor *next;
Visitor *prev;
} Visitor;
may be one of the nodes of that list. In the case of head or tail of the list, you can specify NULL values to distinguish different corner cases, but that depends on realization.
The list itself:
typedef struct {
Visitor *head;
Visitor *tail;
} VisitorList;
The drawback of such structure is that getting number of visitors has linear complexity which may be not that you want.

Related

Reason for using linked list implementations on stack vs heap

I was reviewing some libraries in C for a systems programming class, and I noticed their implementation of a doubly linked list did not require dynamically allocated data. Instead a list of a potentially dynamically allocated struct required an embedded list element, which with a list_entry macro would convert any list element back to the stored structure. For example given a struct foo:
struct list_elem
{
struct list_elem *prev;
struct list_elem *next;
};
struct list
{
struct list_elem head;
struct list_elem tail;
};
struct list foo_list;
list_init(&foo_list);
...
struct list_elem *e = list_begin(&foo_list);
struct foo *f = list_entry(e, struct foo, sharedelem); // Where sharedelem is of list_elem in struct foo
My question, is this advantageous and/or applicable outside of systems programming? Or would using an ambiguous type implementation of a linked list be preferable (wherein the linked list itself is malloc'ed and points to void elements).
There are two cases:
The program/library/service owns the data, and is not sharing it. In this case, altering the internal data structures to support different types of access/traversing (linked list, tree etc) can be advantageous, for speed and memory footprint reasons. However, this data should not leak to a client of the program/library/service, because the client code can mess with the internals (and eventually screwing it for all potential clients).
The program/library/service handles client's data on behalf of the client, so it shares it with the client code. In this case, the structures for accessing/traversing the client's data must "wrap" around it, without altering client's data. This is because the client code assumes data persistency from containers, e.g. "I gave you an int, I expect an int with the same value back".
I hope that these two cases explain why both approaches have merits, depending on the business case.

How to maintain a struct in which its fields will be changed or added between different platforms and versions

I am doing embedded programming. The fields declared in the struct may be extendable or changed between different platform. Lets assume if I have the following struct to save the input data from the device:
At beginning, I have a struct to fill in data from a LG Phone device. Let's call this code Version 1.
struct GPURequest{
int deviceID;
StreamInfo inputInfo; //StreamInfo is another pre-defined struct
}
Later in future, I will need to support the Samsung Pad. The new platform will provide more info to fill the GPURequest struct, the struct will be different and look as following, let's version 2:
struct GPURequest{
unsigned int deviceID;
StreamInfo inputInfo; //StreamInfo is another pre-defined struct
unsigned int frames; //a new introduced field
RegionInfo regionINfo; //RegionInfo is a new introduced struct that is unique to Samsung Pad
}
Here is my problem: If I create a new GPURequest struct for every new platform I am going to support, the struct will be growing too large and have lots of similar duplicated code that won't be used by other platforms. I want to maintain just one basic struct and find a smart and flexible solution to add new field members or change the existing field types based different platform input, so that my code can be used across multiple platforms without redundant code.
Any help is appreciated.

Linked list node with pointer to struct in C

I am new to C programming. Familiarising muself with struct pointers and linekd lists. I came across concept of linked list node with pointer to struct.
typedef struct
{
string name, surname;
int matriculation_num;
}Student_typedef;
typedef struct
{
Tstudent* student;
Node_typedef* next;
} Node_typedef;
Can anyone tell me what exactly is the purpose of Node_typedef. Where are such implementations usefull ?
Any useful link is much appreciated.
The two shown struct type definitions separate the stored data from the storing mechanism.
You can see that Student_typedef has only members which relate to information to store, but none relating to storing. The goal is to have a mechanism which can store a multitude of this data structure.
On the other hand Node_typedef does not contain any of the information to store, only a single pointer to the complete data. If the structure of the inforamtion to store would change (though still be reflected by the same type identifier Student_typedef), then nothing about this storage mechanism would have to be changed.
Or to describe it from a different angle, two developers working on a student database would only have to agree that all the needed information for each student is inside Student_typedef. Then one developer could handle programming functions to enter or edit a given struct (based on a pointer to the struct provided by the storage), while the other developer could handle storage aspects, like adding a new struct to fill, deleting, optimising memory, etc.
Such methods of interface definition and abstraction of code parts are necessary for efficiently handling large projects.

Is there a more efficient way to store an n-ary tree in a file in C?

Say I'm writing an adventure game. The map is built of tiles of different types. I have tiles that form paths, and tiles that form doors, and so on.
I will use a struct to describe the type and content of a tile, and to which other tiles it connects.
Then I'll make a quadruple-linked list to connect them all together.
But a struct that will describe a room will have far more elements than one that will describe a door, so many elements in a door struct will be redundant. I could make a smaller door struct, but structs can only point to structs of the same type*, so I couldn't connect a room struct to a door struct. The redundancy may be negligible but I wondered if there's another way.
Another option is using an array of structs, but then I'd have lots of 'padding' structs wasting even more space. However an array would make reading and re-building a map from file much easier.
Is there any way around the limitation that a struct can only point to a struct of the same type? Or is there another common solution to this problem that I haven't mentioned?
One idea I had was that each tile could have pointers for every other type of tile. Some would be redundant, but it would be a lesser redundancy that the option above.
*By this I mean that typically in a linked list, structs contain pointers to struct of the same type that they're in.
You really don't have to have a uniform struct describing everything. Instead, you could do the following (this is somewhat like writing your own C++ virtual tables in C, and is very widely used).
Your basic tile struct can look like this:
struct tile
{
// common tile stuff
...
enum tile_type type;
void *type_info;
};
So in this struct you store stuff that's common to every tile type. Then you make other structs for other types: one for a room, one for a path, etc. Within an object of tile, you make the enum describe the actual type, and store a pointer to the concrete type within the void *.
There are many links describing variations of this technique. Here's one.
Instead of storing elements in a tile, store only a pointer to the linked list of elements.

How should I go about storing resources in C

What system should I use to store resources (Images, SoundEffects etc) in C?
One example would be storing them in a struct type system:
struct _Resource {
struct _Image {
SDL_Surface *MenuButton;
} Image;
struct _SoundEffect {
Mix_Chunk *MenuButtonSound;
} SoundEffect;
} Resource;
Another example would be storing them in an array:
SDL_Surface *Image[5];
Mix_Chunk *SoundEffect[5];
What are your thoughts?
There are millions of ways of doing it. Asking about what is the best way is not really constructive. You may want to see how others do it (if not re-using those components/libraries to avoid re-inventing a wheel):
GTK Resource Files
Qt Resource System
OS X bundle
Windows resource files
This question is very general, so here's the general answer:
First, you should know that struct an array are orthogonal concepts. You don't need to choose between them, you can have both.
Now usually, when you decide to have a struct, it's because the data are somehow related. For example, if you have resource that is clickable and has a position, a struct such as the following
typedef struct Resource
{
int x, y;
SDL_Surface MenuBotton;
void (*click_callback)(struct Resource *);
} Resource;
makes sense. However, if you have two unrelated concepts, such as image and sound, it absolutely doesn't make sense to put them together in one struct (unless for special cases, such as sending the pointer to a thread!)
So what you need to do is, divide different concepts and group information that are relevant to each other. Make structs out of the relevant information and create arrays of them if you have many instances of them.
In the end, you may want to have one big struct containing everything worked on by a manager of some sort, but that certainly depends on your application.

Resources