Connecting structs/lists

[Romyo2]

I've made a struct with two different variable names, and I want to connect those two different struct with eachother, so I've done a code that's logically applying what I have wanted, here it's:

#include<stdio.h>
#include<string.h>
struct Line2D{
    Line2D *next;
};
int main()
{
    struct Line2D line01,line02;
    line01.next=&line02;
}

All things are fine, just line 9 which I'm still confused about it, why I must write in line 9 the syntax

line01.next

and not this syntax

line01.*next

like what's written in the struct itself..., does the operator "*" in this statement :

 Line2D *next

just acting like telling me that there's an address called next which its type Line2D? and it's(the *) not having any else purposes?

[talahin]

Hi,

As you post this in the C forum, you should leave out C++-isms in your code. in C you need to include the struct keyword when refering to a struct. So it should be:

struct Line2D{
    struct Line2D * next;
};

also your main() should have a return statement.

Your declaration of struct Line2D * next; means you are declaring a variable that is a pointer to a struct Line2D. Remember the * is not part of the variable name, it's part of the type definition.
It's easier to remember if you put a space between the '*' and the variable name.

As for

line01.next = & line02;

you are assigning the address of line02 ( & line02) to a pointer.

line01.*next = & line02;

your assingning an address to what next is pointing to, which is a structure.
You can only assign a value to a member of a structure. Like:

line01.(*next).next = & line02;

Cheers

[Romyo2]

Hi,

As you post this in the C forum, you should leave out C++-isms in your code. in C you need to include the struct keyword when refering to a struct. So it should be:

struct Line2D{
    struct Line2D * next;
};

also your main() should have a return statement.

Your declaration of struct Line2D * next; means you are declaring a variable that is a pointer to a struct Line2D. Remember the * is not part of the variable name, it's part of the type definition.
It's easier to remember if you put a space between the '*' and the variable name.

Alright as far as C++ and C programming are approximately the same so no problem

what do you mean with this sentence "Remember the * is not part of the variable name, it's part of the type definition.", are we in other words forgotten of the operator "*" ? which it's just for informing me that I'm using a pointer called next..

[Nominal Animal]

Alright as far as C++ and C programming are approximately the same so no problem

C and C++ are two totally different programming languages. They have some similarities, but they are not "approximately the same". Unless you consider for example humans and bananas approximately the same -- after all, 50% of our genes are the same.

[MutantJohn]

Well, all valid C is valid C++.

[talahin]

Yes, but not all valid C++ is valid C.

[Matticus]

Well, all valid C is valid C++.

Not really, no. For starters, C allows variable names that are keywords in C++, which if used, would automatically invalidate it when using a C++ compiler.

More such restrictions can be found online, such as here: Incompatibilities Between ISO C and ISO C++

[Nominal Animal]

Well, all valid C is valid C++.

Are you trolling?

As you well know, the two are different languages, with different reserved words and so on. Consider the following code:

int new(const int class, const int namespace)
{
    return class * namespace + 1;
}

It's perfectly valid in C (C89, C99, C11), but will stop any C++ compiler dead in its tracks, even if you wrap it in extern "C".

I expected more from you, MutantJohn. Well, one more name to the ignore list..

[Matticus]

I expected more from you, MutantJohn. Well, one more name to the ignore list..

I thought you were "cool"

[MutantJohn]

Man, Nominal, dropping the hammer!

[Alpo]

Unless you consider for example humans and bananas approximately the same -- after all, 50% of our genes are the same.

I am offensive and I found this banana. :P

line01.(*next).next = & line02;

It's probably easier to user the arrow dereference:

line01.next->next = & line02;

int new(const int class, const int namespace)
{
    return class * namespace + 1;
}

I have to admit, I thought the same as MutantJohn. IIRC, a few books on C speak of using the C++ compiler for its stricter type checking, plus I can't think of code which violates the idea except for the reserved words which you demonstrated. Basically my thoughts were that most (almost all) C, was valid C++, but the reverse is definitely not true.

However the paradigms the languages support are varied enough that the way I accomplish things in C++ are far different than what the equivalent C code would be. I don't think using this logic is accurate though, as it seems like C++11 could be argued to be a different language than C++11 because the lamba's allow easier functional programming (which could be the case, I don't know).

In truth it's only an intellectual curiosity to me, the ease of use of language features and APIs has become the important factors that I look at when starting something new. Many of the API's I know can be used by both compilers, so I usually just look at the complexity of the project and whether the extra effort of OOP will benefit it (more than the time cost). In any case it's only tangentially related to linked lists lol.

[laserlight]

You might want to read Stroustrup's answer to the FAQ: Is C a subset of C++?

I don't think using this logic is accurate though, as it seems like C++11 could be argued to be a different language than C++11 because the lamba's allow easier functional programming (which could be the case, I don't know).

Looks like you have a typo error: anyone trying to argue that C++11 is a different language from C++11 must be insane or trolling.

Many of the API's I know can be used by both compilers, so I usually just look at the complexity of the project and whether the extra effort of OOP will benefit it (more than the time cost).

C++ is suitable for simple projects too, and built-in object-oriented programming support is just one aspect of C++, albeit a major one.

[Romyo2]

Alright, so I'm sorry for posing C++ code pattern over here, and what about the question that I asked it over post #4, any assistance?

ty.

[laserlight]

what about the question that I asked it over post #4, any assistance?

I think you meant post #3:

what do you mean with this sentence "Remember the * is not part of the variable name, it's part of the type definition.", are we in other words forgotten of the operator "*" ? which it's just for informing me that I'm using a pointer called next..

If you understand that the member pointer is named next rather than *next, then you already got what talahin was trying to say.

That said...

It's easier to remember if you put a space between the '*' and the variable name.

Then it looks like multiplication

While it is true that the asterisk is not part of the identifier, it does bind to the identifier in the grammar, so visually placing it next to the identifier makes sense. On the other hand, the type of the member is struct Line2D*, so it also makes sense to visually place it next to the type name. Putting spaces in between both would be a compromise, but whether it really is better than the other options is a matter of subjective style. I certainly do not think that it is common convention.

[Alpo]

You might want to read Stroustrup's answer to the FAQ: Is C a subset of C++?

Oh, implicit conversions of void*, that's right! I actually have had problems before compiling C code with a C++ compiler because of this, I just didn't think of it.

Looks like you have a typo error: anyone trying to argue that C++11 is a different language from C++11 must be insane or trolling.

All I need to do is disprove with identity principal, once I do that you'll all be as crazy as me...