Array managed by preprocessor

[/* frank */]

My teacher said that array in C is managed by preprocessor.

Preprocesser replace all array occurences (i.e. int a[10] ) with
something that I don't understand/remember well.

What's exactly happens with array during preprocessing/compiling stage?

Thanks in advance

 

[Artie Gold]

My teacher said that array in C is managed by preprocessor.

Preprocesser replace all array occurences (i.e. int a[10] ) with
something that I don't understand/remember well.

What's exactly happens with array during preprocessing/compiling stage?

Thanks in advance

Well, there are two possibilities here:

1) You misunderstood what your teacher said.
2) Your teacher is horribly, horribly wrong.

I suspect you need to revisit the subject; why not *ask your teacher*?

HTH,
--ag

 

[/* frank */]

Artie Gold ha scritto:

1) You misunderstood what your teacher said.

If I have this array:

a

the preprocessor translate it, into *(a+i)

a is translated as costant.


Thanks

 

[Joona I Palaste]

Artie Gold ha scritto:

If I have this array:

a

the preprocessor translate it, into *(a+i)

a is translated as costant.

The preprocessor doesn't translate it into anything. Its job is done at
that stage and it has exited stage left. [] is a full-blown operator in
C. Its behaviour is defined as the * (indirection) and + (addition)
operators combined so that a means *(a+i). Also, i[a] means the same
thing as a.

 

[Emmanuel Delahaye]

My teacher said that array in C is managed by preprocessor.

Get a better teacher, and read your C-book about arrays. Do exercices.

 

[Case -]

My teacher said that array in C is managed by preprocessor.

Preprocesser replace all array occurences (i.e. int a[10] ) with
something that I don't understand/remember well.

Was it perhaps that a[10] is equivalent with 10[a], because
a compiler may transform a[10] into *(a + 10) and 10[a] in
*(10 + a)?

What's exactly happens with array during preprocessing/compiling stage?

The preprocessor is a kind of simple text processor with commands
that start with (and use) #. The preprocessing 'stage' is a
purely textual one; the meaning of C constructs like a[10] is
not know there. So only when 'a' would have been #defined, the
preprocessor will modify it textually (i.e., replace it with
what 'a' was #defined to be).

The compiler deals with the meaning of the (preprocessed C) code.
In differerent stages (using different internal representations),
the compiler transforms the C code into machine code. Often the
compiler generates assembly code, which is transformed into the
actual machine code by the assembler program.

 

[Malcolm]

If I have this array:

a

the preprocessor translate it, into *(a+i)

a is translated as costant.

You can often get a preprocessor as a standalone program (cpp or something
similar). Why not run it on some C source and see what happens?

 

[Paul Mensonides]

What's exactly happens with array during preprocessing/compiling stage?

The preprocessor is a kind of simple text processor with commands
that start with (and use) #. The preprocessing 'stage' is a
purely textual one; the meaning of C constructs like a[10] is
not know there. So only when 'a' would have been #defined, the
preprocessor will modify it textually (i.e., replace it with
what 'a' was #defined to be).

The preprocessor operates on preprocessing tokens. It is not a text processor
except during initial tokenization. Otherwise, you're right. The preprocessor
does not transform "a[10]". In fact, even if 'a' was defined as a macro, there
is no way that macro expansion can extract the '10'.

Regards,
Paul Mensonides

 

[Peter Ammon]

My teacher said that array in C is managed by preprocessor.

Preprocesser replace all array occurences (i.e. int a[10] ) with
something that I don't understand/remember well.

What's exactly happens with array during preprocessing/compiling stage?

Thanks in advance

Let's find out.

peter ) cat test.c
void function(void) {
int array[10];
array[1]=2;
array[5]=array[1];
}
peter ) cc -E test.c
# 1 "test.c"
#pragma GCC set_debug_pwd "/Users/peter"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "test.c"
void function(void) {
int array[10];
array[1]=2;
array[5]=array[1];
}

Looks like nothing at all!

 

[/* frank */]

Emmanuel Delahaye ha scritto:

Get a better teacher, and read your C-book about arrays. Do exercices.

K&R 2nd ed. writes that C compiler transform the expression
a in *(a+i) so some kind of "conversion" happen, during
preprocessing stage?
Tks

 

[Martin Ambuhl]

Emmanuel Delahaye ha scritto:

Get a better teacher, and read your C-book about arrays. Do exercices.

K&R 2nd ed. writes that C compiler transform the expression
a in *(a+i) so some kind of "conversion" happen, during
preprocessing stage?

The compiler does many things other than in the preprocessing stage.
The compiler also emits some sort of code. Do you think the
preprocessor does that, too?

 

[Case]

What's exactly happens with array during preprocessing/compiling stage?

The preprocessor is a kind of simple text processor with commands
that start with (and use) #. The preprocessing 'stage' is a
purely textual one; the meaning of C constructs like a[10] is
not know there. So only when 'a' would have been #defined, the
preprocessor will modify it textually (i.e., replace it with
what 'a' was #defined to be).

The preprocessor operates on preprocessing tokens. It is not a text processor
except during initial tokenization.

Yes it is, CPP processes a text file (which happens to be C code),
it's as simple as that. You use 'initial tokenization' without
supplying the context (do you mean as part of C compilation, are
you talking about the internals of CPP, or ...). What do you mean?

Case

 

[Dan Pop]

My teacher said that array in C is managed by preprocessor.

Find another teacher. If this is not an option, learn C from K&R2: your
teacher doesn't know what he's talking about.

Dan

 

[Dan Pop]

What's exactly happens with array during preprocessing/compiling stage?

The preprocessor is a kind of simple text processor with commands
that start with (and use) #. The preprocessing 'stage' is a
purely textual one; the meaning of C constructs like a[10] is
not know there. So only when 'a' would have been #defined, the
preprocessor will modify it textually (i.e., replace it with
what 'a' was #defined to be).

The preprocessor operates on preprocessing tokens. It is not a text processor ^^^^^^^^^^^^^^^^^^^^
except during initial tokenization.

Yes it is, CPP processes a text file (which happens to be C code),
it's as simple as that.

Nope, it isn't. Try avoiding topic you don't have any clue about.

You use 'initial tokenization' without
supplying the context (do you mean as part of C compilation, are
you talking about the internals of CPP, or ...). What do you mean?

He means what he says: preprocessing tokens, as described by the C
language definition, which is the implicit context in this newsgroup.

If you still don't get it, consider the following example:

#if 0
That's all
#endif

and compare it with

/* That's all */

The first commenting method is valid only for correct C code, or, at least
sequences of valid C preprocessing tokens.

Dan

 

[Chris Dollin]

Artie Gold ha scritto:

1) You misunderstood what your teacher said.

If I have this array:

a

You mean, if you have this subscript expression. a isn't
an array unless a is an array of arrays.

the preprocessor translate it, into *(a+i)

No, it doesn't. "Preprocessing" is a very specific stage in C
translation, and it doesn't do anything with expressions a
(unless they're in a preprocessing expression).

a *means* *(a+i), but that's nothing to do with the C
preprocessor.

a is translated as costant.

That statement is too vague to be wrong.

 

[Case -]

What's exactly happens with array during preprocessing/compiling stage?

The preprocessor is a kind of simple text processor with commands
that start with (and use) #. The preprocessing 'stage' is a
purely textual one; the meaning of C constructs like a[10] is
not know there. So only when 'a' would have been #defined, the
preprocessor will modify it textually (i.e., replace it with
what 'a' was #defined to be).

The preprocessor operates on preprocessing tokens. It is not a text processor ^^^^^^^^^^^^^^^^^^^^
except during initial tokenization.

Yes it is, CPP processes a text file (which happens to be C code),
it's as simple as that.

Nope, it isn't. Try avoiding topic you don't have any clue about.

What matters to me is helping the OP better understand the
level at which CPP works. The term 'text processor', fits
well in this context of explaining the basics. I'm convinced
that the newby OP is not helped much with strict definitions
in terms of 'preprocessing tokens'.

<snip> consider the following example:

#if 0
That's all
#endif

and compare it with

/* That's all */

The first commenting method is valid only for correct C code, or, at least
sequences of valid C preprocessing tokens.

I admit that you reminded me that the first leads to an error,
and say thanks! However, this does not change my opinion that
the metaphoric 'kind of text processor', can help in understanding
the differences between preprocessing and compilation.

Case

 

[Alex Monjushko]

Emmanuel Delahaye ha scritto:

Get a better teacher, and read your C-book about arrays. Do exercices.

K&R 2nd ed. writes that C compiler transform the expression
a in *(a+i) so some kind of "conversion" happen, during
preprocessing stage?

What makes you think that this is done during the /preprocessing/ stage?

 

[Paul Mensonides]

Dan Pop wrote:

The preprocessor takes several steps (called phases of translation). The first
is the translation of external encoding, universal character names, and
trigraphs into some uniform internal format. The second phase deletes all
instances of backslash immediately followed by a newline. The third phase
tokenizes the result of the above--from that point on all processing is done
with preprocessing tokens--not text--until the seventh phase (where they are
converted to regular tokens). Macro expansion, specifically, doesn't happen
until the fourth phase.

Preprocessing tokens, BYW, are not a fancy way of saying "text" either. They
are distinct tokens--with a formal grammar and everything. The main differences
between "preprocessing tokens" and "tokens" is that 1) there are more of them,
and 2) the grammar for pp-numbers is much simpler. For example, # and ## are
preprocessing tokens, but they cannot be converted to a tokens in the
translation phase seven.

What matters to me is helping the OP better understand the
level at which CPP works. The term 'text processor', fits
well in this context of explaining the basics. I'm convinced
that the newby OP is not helped much with strict definitions
in terms of 'preprocessing tokens'.

A term that is incorrect, like 'text preprocessor', is never better. All it
does is perpetuate the common myth that the preprocessor operates on text--which
it doesn't.

I admit that you reminded me that the first leads to an error,
and say thanks! However, this does not change my opinion that
the metaphoric 'kind of text processor', can help in understanding
the differences between preprocessing and compilation.

In the metaphoric sense, the compiler of the underlying language is just as much
a text processor as the preprocessor. Despite what you're intentions may have
been and despite what your level of understanding of the preprocessor may be,
simplifying something as to make it incorrect (even if it is slightly) is
misleading and causes poor understanding to continue.

Readdressing the OP's original issue... The preprocessor does not transform
"A" to "*(A + B)". Even though the underlying language parser might do so
internally--it doesn't have to. It only has to treat the two syntaxes
equivalently. E.g. the identity relation compares equal semantically.

Further, regardless of what macro definitions exist, the preprocessing token
sequence

A

cannot be transformed via macro expansion to

*(A + B)

unless it is used as an argument in another macro invocation. E.g. it would
have to be something like this:

#define EMPTY()
#define DEFER(id) id EMPTY()

#define EAT(...)

#define A *(A + DEFER(EAT)(
#define B ) B) DEFER(EAT)(

#define M(...) __VA_ARGS__)

M( A ) // *(A + B)

In other words, it isn't easy to even when you're trying to do it. (The above
requires a pretty conformant preprocessor, BTW--like gcc).

Regards,
Paul Mensonides

 

[RoSsIaCrIiLoIA]

My teacher said that array in C is managed by preprocessor.

Preprocesser replace all array occurences (i.e. int a[10] ) with
something that I don't understand/remember well.

What's exactly happens with array during preprocessing/compiling stage?
Thanks in advance

I have a question if
type a[10] = {0}
then
a == *(a+i) == *(type*) ( (char*)a + i*sizeof(type))
or not?