By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,563 Members | 1,307 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,563 IT Pros & Developers. It's quick & easy.

A Stupid Question about Structure

P: n/a
Hi, all,

For pricticing defination of structure in C, I wrote a small code as
follow:

#include<stdio.h>

struct datastruct
{
int data;
struct datastruct *next;
};
typedef struct datastruct dataType;
typedef struct datastruct *dataTypePt;

int main()
{
dataType y;
dataTypePt p;
dataTypePt *Pt;
y.data=1;
p->data=2;

/*Here, compiler says "Segmentation falt" */
(*pt)->data=3;
printf("\n%d\n%d\n%d\n",y.data,p->data,(*pt)->data);

return 0;
}

I'm confusing about the use of structure. Anyone can help me?
Feb 1 '08 #1
Share this Question
Share on Google+
7 Replies


P: n/a
On Feb 1, 4:23*pm, ot_007_2...@hotmail.com wrote:
typedef struct datastruct dataType;
typedef struct datastruct *dataTypePt;
typedefs like these are usually purposeless obfuscations.
* * dataTypePt p;
OK, you've allocated memory for a pointer.
It's automatic, so uninitialized (i.e., garbage).
(If static it would be initialized to NULL.)
* * p->data=2;
"Dereferencing" an uninitialized pointer?
Wrong.
* * /*Here, compiler says "Segmentation falt" */
Whew, you lucked out!
(Some wise-acre will point out, the compiler
"would have been within its rights" to format
your hard disk!)
I'm confusing about the use of structure. Anyone can help me?
Not structures. You're confused about pointers,
or rather the need to give them values.

James

Feb 1 '08 #2

P: n/a
ot*********@hotmail.com wrote:
Hi, all,

For pricticing defination of structure in C, I wrote a small code as
follow:

#include<stdio.h>

struct datastruct
{
int data;
struct datastruct *next;
};
typedef struct datastruct dataType;
typedef struct datastruct *dataTypePt;
You'll probably find many people suggesting that you don't use
typedef for pointers, but you may chose to ignore them...

You've chosen poor names for your structures and types, in my
opinion, by the way.
int main()
{
dataType y;
so y is a structure. OK
dataTypePt p;
So p is a pointer to structure, but hasn't been initialised to point to
a structure...
dataTypePt *Pt;
Pt is a pointer to a pointer to structure and again hasn't been
initialised.
y.data=1;
That's fine.
p->data=2;
So you are trying to follow an unitialised pointer... Not a good idea.
/*Here, compiler says "Segmentation falt" */
I doubt it. I'd worry about a compiler that had a segmentation fault.

It's more likely that your program builds and then fails when you run
it.
(*pt)->data=3;
Similar problems - following an unitialized pointer, trying to use
whatever you find as a pointer to structure.
printf("\n%d\n%d\n%d\n",y.data,p->data,(*pt)->data);

return 0;
}

I'm confusing about the use of structure. Anyone can help me?
Try reading a good textbook (I like Kernighan and Ritchie) and the C FAQ
at www.c-faq.com
Feb 1 '08 #3

P: n/a
Thank you all:)

Now, the biggest problem seems to be the pointer pointing to nothing.

To initialise a struct pointer, should I use the malloc(), or I have
to get it point to a struct variable?

Feb 1 '08 #4

P: n/a
ot*********@hotmail.com wrote:
Thank you all:)

Now, the biggest problem seems to be the pointer pointing to nothing.

To initialise a struct pointer, should I use the malloc(), or I have
to get it point to a struct variable?
It entirely depends on what you are trying to achieve...

I think most of us feel that you need to spend more time with a good
textbook or tutorial (or both) rather than trying to learn by tinkering.
Feb 1 '08 #5

P: n/a
ot*********@hotmail.com writes:
For pricticing defination of structure in C, I wrote a small code as
follow:

#include<stdio.h>

struct datastruct
{
int data;
struct datastruct *next;
};
typedef struct datastruct dataType;
As you've seen in this thread, typedefs for structs are controversial.
Personally, I prefer not to use them; it's simpler to refer to the
type as "struct datastruct" than to invent a new name for it.
Remember that a typedef merely creates an alias for an existing type;
your type "struct datastruct" already has a perfectly good name.

On the other hand, plenty of intelligent people do like typedefs for
structs, so that the type has a simple one-word name and you don't
have to repeat the "struct" keyword every time you refer to it.

But in either case, there's no good reason to use a substantially
different name for the struct tag than for the typedef. You're using
two different names, "datastruct" and "dataType", for the same thing;
you *could* use exactly the same name for both:

struct dataType
{
int data;
struct dataType *next;
};
typedef struct dataType dataType;

or even:

typedef struct dataType
{
int data;
struct dataType *next;
} dataType;

The latter is a very common idiom. There's no ambiguity; the name
"datastruct" is interpreted as a struct tag if and only if it
immediately follows the "struct" keyword.
typedef struct datastruct *dataTypePt;
Typedefs for pointer types are less controversial; they're widely
considered to be a bad idea. For any use of the name dataTypePt, it's
important to know that it's a pointer type, so don't hide that
information behind a typedef (even if it ends in "Pt"). Just refer to
the type as "struct datastruct*" or "dataType*".
int main()
Better: "int main(void)".
{
dataType y;
dataTypePt p;
dataTypePt *Pt;
y.data=1;
p->data=2;
A bit of whitespace around the "=" operator would make this easier to
read:

y.data = 1;
p->data = 2;
/*Here, compiler says "Segmentation falt" */
No, the compiler doesn't say that. (At least I *hope* it doesn't.)
The compiler is the component that translates your C program into
executable code; once you have an executable file, the compiler's job
is done. You got that message when you ran your program. The message
came from your program, or from the runtime environment, or from the
operating system.

And as you know by now, it happened because "p" had not been
initialized. In this particular case, that means the value of "p" is
arbitrary garbage. You're lucky that the error was detected; if "p"
had happened, by chance, to point to some valid chunk of memory, you
could have silently stored the value 2 anywhere. It's not uncommon for
programs with errors like this to *appear* to work correctly, or to
fail in ways that don't obviously relate to the actual cause.
(*pt)->data=3;
printf("\n%d\n%d\n%d\n",y.data,p->data,(*pt)->data);
Spaces after the commas would make this more readable.

There's a delicate balance between too much whitespace and too little.
Consider running your code through a source code formatter; you'll
need to play with the settings to get results that you like. Look at
some existing well-written code, such as the examples in K&R2.
return 0;
Thank you for remembering to return a value from main; too many people
neglect this. Strictly speaking, this may or may not be necessary,
depending on some details I won't go into here, but it's never wrong
to return 0. [Numerous nit-picking examples where it would be wrong
to return 0 deleted.]
}

I'm confusing about the use of structure. Anyone can help me?
I've probably created more confusion. The more you know, the more you
know you don't know.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Feb 1 '08 #6

P: n/a
James Dow Allen wrote:
>
On Feb 1, 4:23 pm, ot_007_2...@hotmail.com wrote:
[...]
p->data=2;

"Dereferencing" an uninitialized pointer?
Wrong.
/*Here, compiler says "Segmentation falt" */

Whew, you lucked out!
(Some wise-acre will point out, the compiler
"would have been within its rights" to format
your hard disk!)
[...]

Consider a system without memory protection (real-mode MS-DOS comes
to mind). Consider the possible ramifications of storing a "2" in
some random memory location. Reformatting your hard drive, possibly
two days later, while very unlikely, is not impossible. (And, as
far as the C standard is concerned, it's a perfectly legal outcome.)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Feb 1 '08 #7

P: n/a
Keith Thompson <ks***@mib.orgwrites:
[...]
But in either case, there's no good reason to use a substantially
different name for the struct tag than for the typedef. You're using
two different names, "datastruct" and "dataType", for the same thing;
you *could* use exactly the same name for both:

struct dataType
{
int data;
struct dataType *next;
};
typedef struct dataType dataType;

or even:

typedef struct dataType
{
int data;
struct dataType *next;
} dataType;

The latter is a very common idiom. There's no ambiguity; the name
"datastruct" is interpreted as a struct tag if and only if it
immediately follows the "struct" keyword.
[...]

One thing I forgot to mention: there's no ambiguity to the compiler,
but some development environments provide a command to show or jump to
the definition of an identifier when you click on it or otherwise
indicate it. Such environments might not necessarily know the
difference between a typedef and a struct tag (though they *could*
look for a preceding "struct" keyword). In such an environment, *if*
you choose to use typedefs for structs, there might be some advantage
in using distinct identifiers for the struct tag and for the typedef.
But in that case it's still a good idea to have a simple convention
for deriving one from the other. For example, since you're presumably
going to be using the typedef name much more often than the struct
tag, you might append a "_s" suffix to the tag:

typedef struct dataType_s
{
int data;
struct dataType_s *next;
} dataType;

Or even just a single underscore.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Feb 1 '08 #8

This discussion thread is closed

Replies have been disabled for this discussion.