...how we are able to access them using G->var...
It seems you don't understand clearly what a pointer is. A pointer is a simple variable you can read and write as any other. But you can do one more operation on a pointer: dereference it (using * or ->). In order to do this particular operation, the value of the pointer must be valid: a pointer contains an address and, if that address is not valid, an error happens. Think at a pointer as an envelope, written or not. You can read what is written ON the envelope; you can also wipe and write on it. But when you read the address written on the envelope, you want that address exists, otherwise you could go around searching an address which does not exist, and get angry.
The particular value of a pointer can be thought similar to that of an integer. You can take any integer and perform calculations with it but, if you want to divide for it, your integer must be different from 0, otherwise an error happens. So is a pointer: you can read it and write it with any value but, if you want to use its value as what should normally be, i.e. an address in memory, that value must point to a suitable address. malloc() and calloc() return values which are valid and suitable to be assigned to a pointer, and can be safely used (in normal circustances) when you try to dereference the pointer.
EDIT after comments below.
One normally thinks that, if a program is not guaranteed to behave correctly, it is an error. For the program to always behave correctly, many precautions must be taken. Two of these are 1) Don't use unknown values, and 2) Don't dereference invalid pointers. Errors can be divided finely further, by nomenclature, style, or the effect they produce or can produce. Undefined behavior is the name given by the C language specification to indicate that the compiler (or the target machine) can do whatever they want, because the specification does not mandate anything precise about. Of course, nobody wants "undefined behavior", so making it happen is just an error. And back to dereferencing wrong pointers, the specification says it invokes undefined behavior. Precisely, depending on the target machine and OS, one or more of the following can happen: 1) nothing, apart from reading unknown values; 2) nothing, apart from writing to unknown memory zones; 3) segment faults or other traps/exceptions and so on; 4) CPU overheating, maybe explosion, or other unspecified things.
Now we take a step ahead. If your pointer variable is not a "normal", global variable, but instead resides in dynamic - non allocated - memory, your variable does not exist yet. It is a concept, not a real variable. So, first you create that variable; then you can use it as said before.
In your example, "Struct Graph" is a declaration of a bunch of variables which do not exist until you allocate them. Once you do it, via "Graph *G = malloc(sizeof(*G));", they come to life; but this does not mean they have valid values. In fact, just below creating the struct, in you code fragment, they are accessed. The only legal access to them, in this moment, is to assign them some value. As said before, they could also be read - they actually exist, but their value could (well, IS) illegal.
If the values in the Struct Graph, just created, were simple integers instead of pointers, the matter would be the same: the variables exist, but their content is unknown and hence invalid. Note that you could allocate a Struct Graph using calloc(): in this case the value of the variables inside would not be unknown but, for a pointer, still would be invalid to be dereferenced - like an integer known to be zero and hence invalid to be used as a divisor. But the variables ARE there, ready to be tested against 0 (in case of an integer), or against NULL (or 0) in the case of pointers, or ready to be written with meaningful values.
Hope I've been clear enough to help.
malloc, you can't even accessG -> anything. It creates the variables inside thestruct. Without that,Gis just a pointer pointing to nowhere. - SpikatrixEdge *next;Edge is not a defined type. In C, this should be a syntax error. - wildplasser