Thread: Struct members's access

Hello fellas;
Im new on world of programming and I just started off learning C language as first hand to our world of programming.
I learnt structs and there's something confusing me alot about access members of structs.

when I'm not dealing with structs, and I write

Code:

int x=6

then if I want to access x, I just write x; but the confusing comes when I want to access structs and its members, lets assume I have

Code:

struct trajectory
{
int x=6;
int y=3;
}

if I want to access the member x , then I should write trajectory.x which it means accessing the variable x. what's not comfortable with me is the syntax of writing the accessing of member x, i.e it should once I write trajectory.x then it means for me trajectory.6 because we called the variable x after the "." point of accessing the struct, so as we learnt the "return of reading variable" will return to its calling i.e we called the variable x after we write "trajectory. ", so the value of x should back to where we call the variable x which it should be like this trajectory.5 (trajectory.x) ... but apparently Im wrong because in my book mentioned something else that "trajectory.x" is implicitly like calling the variable x .. it doesn't make sense for me and I don't know why it's like that and not like what I said above .. so that's why Im posting here my question/confusion and hope you guys help me to think about it in another aspect that could help me to understand the concept of accessing members of structs ...


Appreciate your effort guys to help me to visualize accessing of struct members in a good manner that could help me while coding! thanks in advance.

Originally Posted by Brian_Teir

if I want to access the member x , then I should write trajectory.x which it means accessing the variable x.

Unfortunately, that is not correct. In C, the struct declaration (you will also see it called a struct definition to differentiate it from a forward declaration of the struct) does not create an object of the struct unless you also immediately declare objects (or pointers, etc) of the struct type following its declaration. Furthermore, you cannot initialise the members of the struct in the way that you used. So, I would expect a struct declaration like this:

Code:

struct trajectory
{
    int x;
    int y;
};

Notice the terminating semi-colon for the declaration. Note that we would refer to this struct type as struct trajectory, not just trajectory. Given this struct declaration, we could declare an object of the type and initialise it as you intended:

Code:

struct trajectory bullet_trajectory = {6, 3};

Now, if you want to access the member x of the bullet_trajectory object, you would write bullet_trajectory.x, e.g.,

Code:

printf("%d\n", bullet_trajectory.x);

Originally Posted by Brian_Teir

what's not comfortable with me is the syntax of writing the accessing of member x, i.e it should once I write trajectory.x then it means for me trajectory.6 because we called the variable x after the "." point of accessing the struct, so as we learnt the "return of reading variable" will return to its calling i.e we called the variable x after we write "trajectory. ", so the value of x should back to where we call the variable x which it should be like this trajectory.5 (trajectory.x) ... but apparently Im wrong because in my book mentioned something else that "trajectory.x" is implicitly like calling the variable x ..

Because the struct trajectory object is named bullet_trajectory and the member is named x, the int object that you're accessing is named bullet_trajectory.x. The initial value of this int object named bullet_trajectory.x is 6. bullet_trajectory.6 wouldn't make sense because 6 is not the name of a member of the struct; it happens to be the value of bullet_trajectory.x.

Originally Posted by laserlight

Because the struct trajectory object is named bullet_trajectory and the member is named x, the int object that you're accessing is named bullet_trajectory.x. The initial value of this int object named bullet_trajectory.x is 6. bullet_trajectory.6 wouldn't make sense because 6 is not the name of a member of the struct; it happens to be the value of bullet_trajectory.x.

Thanks for your effort.

but doesn't it mean bullet_trajectory.x in aspect of PC: go to bullet_trajectory, and then go into x variable? if so, then how bullet_trajectory.x is the name of object int? Im totally satisfied that object int is x, the name "bullet_trajectory" is struct name and not member name ... still confused .. lets make it more easy, if "bullet_trajectory.x" is the name of object int, then the PC will immediately go to that name (to that address), but actually once the PC read "bullet_trajectory.x" , then first he goes to bullet_trajectory address, and then afterwards he goes to address of x ... so how we authorized to say "bullet_trajectory.x" is the name of object int? if it's a name, then pc must directly access it and not first go to bullet_trajectory and then access x , he should go directly to bulet_trajectory.x's address ..

I guess if you could give more realistic and senseable example on accessing struct's members and why we use (the name of struct . member's name ) as accessing its members would be more satisfied and convinced about ......

what Im trying to do is to look on it in another aspect, it's hard for me to visualize bulet_trajectory.x is just treated as x (object int) ...actually here's my complexity.

It is the compiler, not the computer at run time, that determines what object bullet_trajectory.x refers to. The name bullet_trajectory refers to some region of memory having a value of type struct trajectory: that's what we call an "object" (although strictly speaking, if an object is small enough, never gets its address taken, and is sufficiently short-lived, it could possibly be stored in a register and never in memory). The name x in this context refers to a particular struct trajectory member. That's why for this particular struct trajectory object, the subobject is referred to as bullet_trajectory.x. If you prefer, you can simply say x when the context is understood, but there could be multiple struct trajectory objects, each with their own x member.

Originally Posted by Brian_Tier

for instance I can do my own compiler and then say(define in my compiler) that bullet_trajectory.x isn't an int object?

Well, if you are writing a compiler for your own programming language, you can do whatever you want

But if you're writing a C compiler, that would be non-conforming: C doesn't allow monkey-patching, so the fact that struct trajectory was declared as having x as an int member means that all struct trajectory objects have x as an int member, so if bullet_trajectory is a struct trajectory object, then bullet_trajectory.x must be an int, unless you change the declaration of struct trajectory itself.

Originally Posted by Brian_Tier

in other words isn't the value of x that's a member of its struct?

No, x is a member of the struct; the value of x is not a member of the struct.

Let me put it this way: suppose you are a member of your local C programming club. Let's also suppose that you are carrying $100 with you. So, can I conclude that $100 is a member of your local C programming club?

Originally Posted by Brian_Teir

just on the same aspect, so for example in C++/javascript we can use functions inside structs/classes, for instance when we say this :
system.out.print("Hello world"), what actually it means like print("Hello world") .. but analogy to structs, we first enter the system "struct" then we enter the struct "out", and then we do "print" ..so it sounds for me like PC is just doing its last step .. what he finds/does at end then he does it without carrying out to the pre-processes that he does in order to do his last/final functionality .. in my case he does "print" in his last functionality so we just say this function system.out.print is printing something .. so what determines what the instruction means is just its last step/operation .. so can I claim that PC works accordingly to its last operation? I mean with that lets assume there was instruction system.out.pepo then the PC will do pepo function and we can determine that this instruction is implicitly a pepo function ..

To sum up, is it a good way to take a "lemma" (lemma is just a proposal that's true) PC works as his final step and its determines what the instruction does without carrying out to what he done before arriving to that last operation?!

Are you aware that your C program is typically compiled into machine code (possibly via assembly language), and the computer executes the machine code, not your C program? Furthermore, this is not the only model by which programs can be translated: other programming languages might have code that is typically interpreted at run time and hence executed by the interpreter, others might take a hybrid approach with just-in-time compilation, and then we can throw into the mix the notion of virtual machines and hence compilation to bytecode to be executed by a virtual machine rather than to machine code to be executed directly by the computer.

To answer your question though: no, what needs to be done at run time depends on various factors. You cannot always say that the compiler can determine "the last operation" at compile time, not in C, and certainly not across the myriad of programming languages out there. For example, since you mentioned C++, one common example is the virtual call mechanism in C++: if a virtual function is invoked using a pointer to the base class object, it may be the case that the compiler cannot determine which derived class override of the virtual function is to be invoked, i.e., this is really something that can only be determined at run time, hence "the PC" must do the work to execute the code that works out which function to invoke at run time. On the other hand, if you just call the virtual function with an object of a derived class, the compiler can determine what function is to be invoked at compile time, and so it can arrange for that function to be called, i.e., "the PC" doesn't need to be involved in determining what function to call.