When I was reading about Linked list, I came to know that the structure for linked list as
Struct node{
Struct node *next;
int value;
}
Why is the Struct node *next? Why cant it just be an integer pointer? Like below
Struct node{
int *next;
int value;
}
why can't this hold the next node's address? Can anyone please give me explanation?
That's actually what a pointer (*next) does. It holds the address of something else. The type definition describes what this something else is (in this case struct node). Otherwise the application would not know how many bytes to read and how to interpret the data.
Read more about pointers.
Btw. int *next would hold the address of an integer.
Why is the Struct node *next? Why cant
it just be an integer pointer?
Because then you would be pointing to the address of the next integer. This could be used to retrieve the value of the next int, but nothing more, so from there on onward, you would be stuck.
By linking nodes together, which hold integer values, you can traverse the nodes and retrieve the int values.
Related
According to Golang source code:
A sudog is simply a goroutine that is waiting on an element. The sudog struct has these elements
type sudog struct{
g *g
isSelect bool
next *sudog
prev *sudog
elem unsafe.Pointer //data element
...
}
I want to know what's the hidden meaning of sudo? what's it short for?
The general consensus is that a sudog is a pseudo-G, as it is used to keep a list of G's. There is some discussion on https://golang.org/cl/20774.
I have a struct with cJSON pointers as in:
struct {
cJSON *myJSON1;
cJSON *myJSON2;
...
} myStruct;
Somewhere in my code I create cJSON items as in myStruct.myJSON1 = cJSON_CreateObject()
At the end of the code, I want to call cJSON_Delete() on those pointers which were assigned. I presume this is the classic C case where there is no way to find out if the pointer was malloced in some way. Of course, I can keep a flag to keep track but I want a simple way. I read...
The cJSON struct is as:
/* The cJSON structure: */
typedef struct cJSON
{
struct cJSON *next;
struct cJSON *prev;
struct cJSON *child;
int type;
char *valuestring;
/* writing to valueint is DEPRECATED, use cJSON_SetNumberValue instead */
int valueint;
double valuedouble;
char *string;
} cJSON;
The function cJSON_Invalid() is available. The documentation states "(check with cJSON_IsInvalid): Represents an invalid item that doesn't contain any value. You automatically have this type if you set the item to all zero bytes." Do I have to memset the structure to 0 or just type?
In other words, my question is: What would be the easiest way to check if a cJSON pointer is malloced without creating an additional variable? Perhaps set "type" to zero? I can try such options but I want a definite answer which works in all situations.
If you just have an uninitialized pointer to a cJSON data structure the behavior is undefined.
I.e. for cJSON *myJSON1;
cJSON_Invalid(myJSON1) might return 0 or 1.
And cJSON_Delete(myJSON1) will probably segfault. Or do nothing if you get lucky.
The solution is to always initialize cJSON data structures to NULL.
Then you can just call cJSON_Delete(). If the pointer is still NULL the call will do nothing. If it was set up at some point in your program it will correctly release all the memory.
Since you have a structure of multiple cJSON pointers you can set the entire data structure to 0 using memset.
You can take a look at the source code.
CJSON_PUBLIC(void) cJSON_Delete(cJSON *item)
{
cJSON *next = NULL;
while (item != NULL)
{
...
}
}
I've begun studying data structures, and the linked list popped up. The idea behind a linked list is simple, but the implementation (I use c++) is a bit confusing, especially regarding the nodes used in linked lists. The way a node is defined for a singly linked list in C++ is as follows
// A linked list node
struct Node {
int data;
struct Node* next;
};
or if we were using classes, then it is defined like this.
class Node {
public:
int data;
Node* next;
};
My confusion arises here. How can one define another struct inside struct Node with the same name? I see that the new struct is a pointer to a node, but how does this implementation actually work? It's really confusing :(
How can one define another struct inside struct Node with the same name?
That's not what's happening. You can omit the struct keyword in the data member declaration struct Node* next; such that it might be easier to digest:
struct Node {
int data;
Node* next;
};
Except access specifier (the public), this is now identical to the class version, and it can become clear that you don't define a new struct Node inside of Node, but instead you declare a data member next that is a pointer to an instance of type Node. A pointer on a 64bit machine will need 64bit, that's why the compiler can work with this definition of Node, as the size it must reserve for Node instances is known.
To declare a pointer to something you do not need definition of the class, only its declaration. Therefore this is not recursive definition and the compiler won't run into problems.
You can think of it this way: The pointer member will be the same size whatever the type of the pointer, it still needs only the capacity to address a place anywhere in memory.
I am going on a project which process some data, I am wondering that if it is better to use pointer in non-primitive typed fields of struct.
What I've found is that the reason of using pointer is that nil can be used as a zero-value, is this the only reason to use pointer?
For example, I am going to store time.Time in my struct and it cannot be nil, then is it better to use non-pointer field?
So is it okay to use
type A struct {
CreatedAt time.Time
}
rather than
type A struct {
CreatedAt *time.Time
}
when Now is not going to be nil?
Not sure I understand the question. In the case of "Now" I would make it a function of the struct i.e.:
type A struct{}
func (a A) Now() time.Time { return time.Now(); }
otherwise what does Now mean? Now is constantly changing.
There are great blogs on when to use pointers
The short would be it doesn't really depend on if the value can be nil, but more on memory and concurrency. Pointers will be passed as references, so less memory, and faster, but also means that changing in one go routine can be very dangerous because the value could be referenced in another go routine and cause race conditions and unexpected behaviors.
I'm not really a professional or know the ins and outs of Go, so take everything I say with some grain of salt.
But as I am understanding it, you should most likely use pointers.
This is because every time you use a non-pointer type, the whole struct will be part of your struct in memory. As a consequence, you can't share a single instance of a struct between multiple structs - every single one gets a copy of your original struct.
Heres a small example:
// This struct has 2x64 bits in size
type MyStruct struct {
A uint64
B uint64
}
// This struct has 32 + 2x64 bits in size
type MyOtherStruct struct {
C uint32
Parent MyStruct
}
// This struct has 32 + the length of an address bits size
type MyPointerStruct struct {
D uint32
Parent *MyStruct
}
But apart from memory concerns, there is also a performance hit if your inner struct is very big. Because every time you set the inner struct the whole memory has to be copied to your instance.
However you have to be careful if your are dealing with interfaces or structs. At runtime, an interface is represented as a type with two fields: A reference to the actual (runtime) type and one with a reference to the actual instance.
So I - with my unprofessional opinion - would recommend to not use pointers if you have interface types because otherwise the CPU has to deference twice (once to get the interface reference, and then again to get the instance of the interface).
I need to store shared array inside a struct in UPC. Is it possible to do?
Struct fields cannot be shared-qualified, for the same reason they cannot be declared with static or extern - a struct field does not carry independent storage-class information (ie because the fields of a struct are always stored contiguously, and could be used for example to declare a stack variable).
However, a struct may contain an array field, and the struct can then be used to define a shared object, eg:
struct S {
int array[100];
int foo;
};
shared struct S data[THREADS];
...
data[MYTHREAD].array[0] = MYTHREAD;
However note the distribution of data in this example is one struct per thread, the array field is not independently distributed across threads.
A struct may also contain a pointer to a shared array, eg:
#include <upc.h>
struct R {
shared int *sa;
int bar;
};
...
struct R r;
r.sa = upc_all_alloc(THREADS, sizeof(int));
r.sa[MYTHREAD] = MYTHREAD;
in this case the shared array is distributed across threads, but the storage is not embedded in the struct - the struct field is just a pointer-to-shared (and thanks to C rules can be accessed with array syntax).