Question on structs

P

phaedrus

Hi guys,

I've got so far as structs in re-learning C and have hit a bit of a
wall. The online resources on the subject seem to contradict each
other in a way that I've not seen before. There's just ONE point I'd
like clarified, please.

This is my assertion:

A 'struct' in C is not actually a modularised cluster of disparate
data. It's simply a *template* for a complex variable of type struct,
and it is this *variable* which actually forms the modularised cluster
of disparate data. The struct itself is just an empty shell; merely a
*specification* for a data object. This data object is what we call a
variable of type struct. A struct alone therefore doesn't hold any
data; it is not like an array. Arrays can store data, structs by
themselves don't.

Have I got that right?

Thanks.
 
B

bert

Hi guys,

I've got so far as structs in re-learning C and have hit a bit of a
wall. The online resources on the subject seem to contradict each
other in a way that I've not seen before. There's just ONE point I'd
like clarified, please.

This is my assertion:

A 'struct' in C is not actually a modularised cluster of disparate
data. It's simply a *template* for a complex variable of type struct,
and it is this *variable* which actually forms the modularised cluster
of disparate data. The struct itself is just an empty shell; merely a
*specification* for a data object. This data object is what we call a
variable of type struct. A struct alone therefore doesn't hold any
data; it is not like an array. Arrays can store data, structs by
themselves don't.

Have I got that right?

Thanks.

No, I don't think that's right. An array can't store data; the
data is stored in its individual ELEMENTS. A struct can't store
data; the data is stored in its individual FIELDS. The elements
of the array are referenced by their subscripts; the fields of
the struct are referenced by their names. There's a difference,
but I think it's a much smaller difference than you think it is.
--
 
T

Tim Streater

phaedrus said:
OK, point taken. Let me clarify, then.

The data in an array is stored in its elements.
The data for a struct is stored in the member fields of a structure
VARIABLE.

Is that correct?

As I recall, if I do:

struct wiggy
{
int a;
int b;
}

Then I've reserved some actual space (two ints-worth). But you can also
do:

typedef struct wiggy
{
int a;
int b;
}

which just defines a new type, wiggy, and reserves no space. It's not
until later that I do:

int p;
int q;
wiggy diggy;

that I've now reserved space for 4 ints.

I *think* that's what I used to do.
 
P

phaedrus

No, I don't think that's right.  An array can't store data; the
data is stored in its individual ELEMENTS.  A struct can't store
data; the data is stored in its individual FIELDS.  The elements
of the array are referenced by their subscripts; the fields of
the struct are referenced by their names.  There's a difference,
but I think it's a much smaller difference than you think it is.
--

OK, point taken. Let me clarify, then.

The data in an array is stored in its elements.
The data for a struct is stored in the member fields of a structure
VARIABLE.

Is that correct?
 
N

Nick Keighley

the struct declaration declares a type
OK, point taken. Let me clarify, then.

The data in an array is stored in its elements.
The data for a struct is stored in the member fields of a structure
VARIABLE.

Is that correct?

arrays are variables too...

There are types
int, struct S {float f}

there are declarations, which describe what something is but without
setting aside storage
extern int i;
extern int a[];
extern struct S s;

and there are definitions which set aside store
int i;
int a [10];
struct S s;

the slight confusion is that "naked" array types are hardly used (i'm
not even sure if they exist).

typedefs add an additional layer of confusing as despite their name
they don't define types but type aliases.
 
P

phaedrus

I've come across this in one of the online tutorials and it seems to
explain the concept better than anything else I've yet seen:

[begins...]
A structure is declared by making a blank template for a variable
package. This is most easily seen with the help of an example. The
following statement is actually a declaration, so it belongs with
other declarations, either at the head of a program or at the start of
a block.

struct PersonalData

{
char name[namesize];
char address[addresssize];
int YearOfBirth;
int MonthOfBirth;
int DayOfBirth;
};


This purpose of this statement is to create a model or template to
define what a variable of type struct PersonalData will look like. It
says: define a type of variable which collectively holds a string
called name, a string called address and three integers called
YearOfBirth, MonthOfBirth and DayOfBirth. Any variable which is
declared to be of type struct PersonalData will be collectively made
up of parts like these. The list of variable components which make up
the structure are called the members of the structure: the names of
the members are not the names of variables, but are a way of naming
the parts which make up a structure variable. (Note: a variable which
has been declared to be of type struct something is usually called
just a structure rather than a structure variable. The distinction is
maintained here in places where confusion might arise.) The names of
members are held separate from the names of other identifiers in C, so
it is quite possible to have variable names and struct member names
which are the same. Older compilers did not support this luxury.

At this stage, no storage has been given over to a variable, nor has
any variable been declared: only a type has been defined. Having
defined this type of structure, however, the programmer can declare
variables to be of this type. For example:

struct PersonalData x;


declares a variable called x to be of type struct PersonalData.
 
T

Tim Streater

Richard said:
Why is everything "as you recall"?

Because I haven't used C for 20 years, as I've pointed out before. Sit
up straight etc etc.
Why would you offer advice in group of C specialists if you only "think"
that's what you used to do?

Why shouldn't I? If I'm wrong, (certainly not excluded, see above) then
I expect I'll be corrected by those who know better.

Happy now?
 
T

Tim Streater

Richard Heathfield said:
You recall incorrectly. The above is just a type definition. It
reserves no storage. If you'd done this:

struct wiggy
{
int a;
int b;
} earwig;

you'd have reserved (at least) two ints'-worth of storage. Or you
could do it like this:

struct wiggy
{
int a;
int b;
};

struct wiggy earwig;


No, it defines a new type, struct wiggy, and then gives (or rather, in
your case, fails to give) that type a synonym.

Ha! Richard - thanks for the correction.
 
S

Seebs

I've got so far as structs in re-learning C and have hit a bit of a
wall. The online resources on the subject seem to contradict each
other in a way that I've not seen before. There's just ONE point I'd
like clarified, please.

This is my assertion:

A 'struct' in C is not actually a modularised cluster of disparate
data. It's simply a *template* for a complex variable of type struct,
and it is this *variable* which actually forms the modularised cluster
of disparate data. The struct itself is just an empty shell; merely a
*specification* for a data object. This data object is what we call a
variable of type struct. A struct alone therefore doesn't hold any
data; it is not like an array. Arrays can store data, structs by
themselves don't.

Have I got that right?

I don't think so. Except I think you do, but you are using the terminology
in a surprising way.

IMHO, "a struct" refers both to the object of the type and to the type.

Consider:
"long int" is a type. "long int x;" declares an object of that type.
"struct foo" is a type. "struct foo x;" declares an object of that type.

But I would say that x is "a struct foo", and is "the struct itself" just
as much as the type declaration is.

-s
 
S

Seebs

The data in an array is stored in its elements.
The data for a struct is stored in the member fields of a structure
VARIABLE.

Is that correct?

No.

struct foo { ... };

void *v = malloc(10 * sizeof(struct foo));

struct foo *p = v;

p[3] <-- a struct, but not a struct variable.

The only variables there are p and v. Neither is a struct. p is a pointer,
not a struct.

-s
 
S

Seebs

Why shouldn't I? If I'm wrong, (certainly not excluded, see above) then
I expect I'll be corrected by those who know better.

And this is why the status-weenies are idiots. They actually can't
conceive of you doing something in order to learn or develop, but which
could result in a temporary decline in other peoples' perception of you.

Scary, huh?

-s
 
M

Morris Keesan

When you write

struct foo { int bar; int baz; };

you're declaring a type, which is named "struct foo".

When you write

typedef struct { int bar; int baz; } foo;

you're declaring a type, which is named "foo".

When you write

struct { int bar; int baz; } foo;

you're declaring a variable named foo, which is a struct.

I think your confusion comes from the fact that struct types are often
declared as types, separate from declarations of variables.
 
S

Seebs

Why would making a mistake result in a temporary decline in other
people's perception of you? I don't see that at all.

That's a fascinating question, and frankly, I'm not sure I could answer it.

BUT!

Look at all the times the status weenies assert variously that people are
afraid to talk about things they don't know, afraid to answer questions,
afraid to post code for fear it might be criticized, and so on. There is
clearly a general pattern they presume, that demonstrating less-than-perfect
ability makes you look bad, so obviously, people ought to avoid doing this.

It's one of those epiphany things to realize that they genuinely think this
is a plausible motivation to ascribe to people. They really think stuff works
this way! (Perhaps more terrifying, there are large hunks of the world in
which it does to a greater or lesser extent...)

-s
 
K

Keith Thompson

phaedrus said:
I've got so far as structs in re-learning C and have hit a bit of a
wall. The online resources on the subject seem to contradict each
other in a way that I've not seen before. There's just ONE point I'd
like clarified, please.

This is my assertion:

A 'struct' in C is not actually a modularised cluster of disparate
data. It's simply a *template* for a complex variable of type struct,
and it is this *variable* which actually forms the modularised cluster
of disparate data. The struct itself is just an empty shell; merely a
*specification* for a data object. This data object is what we call a
variable of type struct. A struct alone therefore doesn't hold any
data; it is not like an array. Arrays can store data, structs by
themselves don't.

Have I got that right?

Not really.

I think you're getting hung up on the distinction between a *type* and
an *object* (variable) of that type.

Does the phrase "a struct" refer to a type or an object? Does the
phrase "an array" refer to a type or an object? Or, in either case,
does it refer to a value, which is yet another different thing?

I'm not going to give you a definite answer to any of those questions;
rather, I'm going to argue that they're not particularly important
questions.

Think of "array" and "struct" as adjectives, not nouns. You can have
an array type, an array object, an array value, a struct type, a
struct object, a struct value. And likewise for integers, pointers,
unions, et cetera.

(Note: I use the word "object" rather than "variable" because
it's more precise. An object is, by definition, a "region of
data storage in the execution environment, the contents of which
can represent values"; it typically, but not always, has a type
associated with it. The word "variable" is more ambiguous.
Is an object declared with "const" a variable? It can't vary,
can it? Is an object created by a call to malloc() a variable?
We don't have a name for it; some people would call it a variable,
some wouldn't. It's another way we can get hung up on terminology,
when it's the underlying concepts that are important.)

This:

struct foo { int x; int y; };

is a type declaration; it creates a struct type. This:

struct foo obj = { 10, 20 };

is an object definition; it creates an object of that type. The
*value* of that object (until you change it) is a composite value
consisting of the values of its members, 10 and 20.

Once you think of it this way, I suggest that the answers to all your
questions become fairly obvious. A struct type can be thought of
as a "template" (using the word in the English sense, not the C++
sense). As a type, it holds no data. It's a specification for a
data object; you can create arbitrarily many objects of that type.
A struct object (an object of a struct type) occupies some amount
of storage and holds some value, which may or may not change as
the program executes. And exactly the same applies to array types,
objects, and values.

Having said all that, people commonly do use "struct" and "array"
without qualification, as nouns. The phrase "a struct" can refer
to a struct object or a struct object, or even a struct value.
Likewise for "an array", though I suppose that refers more commonly
to an object rather than a type for some reason.

Most of the time, either the meaning is fairly obvious from the
context, or it doesn't matter much. If you find the unqualified
word "struct" or "array" confusing, just be more explicit, and
if someone else uses it in an unclear manner, just ask.
 
K

Kenny McCormack

Seebs said:
It's one of those epiphany things to realize that they genuinely think this
is a plausible motivation to ascribe to people. They really think stuff works
this way!

Two words: Drama Queen
(Perhaps more terrifying, there are large hunks of the world in
which it does to a greater or lesser extent...)

Hmmm. That kinda disproves your whole thesis, don't it?
 
S

Seebs

Two words: Drama Queen

I'd agree that those words are perhaps accurate, but I was trying to be more
charitable. While thinking about relationships in terms of status does
generally lead to drama, I don't think it's usually intentional.
Hmmm. That kinda disproves your whole thesis, don't it?

Nope.

My thesis is that not everyone is completely driven by status -- in
particular, that especially among engineering sorts, you're likely to see
a lot of people who are totally unconcerned about status.

It's like culture. Cultural norms vary. That's fine. Lots of different
cultures work. What doesn't work is insisting on interpreting people's
behavior according to the rules of another culture, because that's crazy.
Imposing a status narrative on many of the posters in comp.lang.c is every
bit as stupid as trying to describe a Japanese business meeting in terms
of what the behaviors and speech acts in question would mean if they'd
been performed at a business meeting involving a bunch of Texans.

I'm not disputing that status relationships do exist in some contexts, or
that some people care about them. It's quite obvious that some people
care very deeply about them. I'm just disputing the assertion that every
relationship anywhere is necessarily about status, or even has a status
component to it. Not all do. It's only one of the many ways humans interact,
and some people don't do it. Autism's the obvious extreme case, but there
are plenty of people who are physically capable of experiencing status
relationships, but who still don't view status as a significant priority.

In short, there are a lot of people out there who would rather look bad
being right than look good being wrong. I know it may sound strange or
mysterious, but trust me, the opposite sounds just as strange to them.

But again: I've never claimed that *no* status relationships existed -- only
that not *everything* is a status relationship. If you think that
acknowledging the existence of status relationships undermines this, you
really do need to work on your basic reading comprehension skills. Maybe
you could start with the Sesame Street episode that introduces "some
of the monsters, all of the monsters, none of the monsters".

-s
 
S

Seebs

Look at all the times the status weenies assert [...]
Well, no thanks - I have better ways to spend my time.

I've found that a couple of hours spent saying "wait, they think WHAT?"
has been really rewarding in helping me deal with them when I have to.

It's like portability. Pays off eventually even if it's not obvious
why it should matter for a given project. :)

-s
 
P

Peter Nilsson

Seebs said:
And this is why the status-weenies are idiots. They
actually can't conceive of you doing something in order
to learn or develop,

Of course, we all learn through intelligent discourse,
but it's not particularly productive, educationally or
professionally, to be sloppy because you _expect_ others
to clean up after you.

'If I'm wrong people will correct me' is an attitude
that invariably places a burden on others to actually
do so. At the very least it is taking people for granted.

Asking questions is more conducive to development
than giving careless answers, whether qualified as
recollections or not.
 
S

Seebs

Of course, we all learn through intelligent discourse,
but it's not particularly productive, educationally or
professionally, to be sloppy because you _expect_ others
to clean up after you.

Not in general.
'If I'm wrong people will correct me' is an attitude
that invariably places a burden on others to actually
do so. At the very least it is taking people for granted.

In general, I might agree, but as it was already pointed out, Tim
went out of his way to highlight that his memory might be unreliable
in this matter.
Asking questions is more conducive to development
than giving careless answers, whether qualified as
recollections or not.

If the only people giving answers are the ones who are totally certain
that they're right, we'll get a lot of very poor answers.

-s
 
B

Barry Schwarz

Hi guys,

I've got so far as structs in re-learning C and have hit a bit of a
wall. The online resources on the subject seem to contradict each
other in a way that I've not seen before. There's just ONE point I'd
like clarified, please.

This is my assertion:

A 'struct' in C is not actually a modularised cluster of disparate
data. It's simply a *template* for a complex variable of type struct,
and it is this *variable* which actually forms the modularised cluster
of disparate data. The struct itself is just an empty shell; merely a
*specification* for a data object. This data object is what we call a
variable of type struct. A struct alone therefore doesn't hold any
data; it is not like an array. Arrays can store data, structs by
themselves don't.

By that reasoning, an int does not hold a value either, only an object
of type int can hold the value.

The phrase "int" can refer to the type or to an object of that type,
depending on the context of the discussion. The same is true of
struct y.

If you want to argue that after the definition
int x;
it is incorrect to say "x is an int" but rather "x is an object of
type int", then you would be consistent saying a struct y does not
hold data, only an object of type struct y does.

I would guess that the distinction is unnecessary in 99%+ of normal
discussions.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,770
Messages
2,569,583
Members
45,075
Latest member
MakersCBDBloodSupport

Latest Threads

Top