A[x][y][z]

[sterten]

it's awful in C with multi-dimension arrays.

A[x][y][z] is worse than A[x,y,z] ,

is someone successfully running the C-compiler from batch-file,
first converting all of the latter expressions
into the corresponding former ones and then compiling it ?

And while we're at it, this preprocessing utility should
also change array definitions like e.g.
int B[N];
into int B[N+1];
since B[N] would not be defined else, only B[0],B[1],..,B[N-1]

 

[Chris Dollin]

it's awful in C with multi-dimension arrays.

If you say so.

A[x][y][z] is worse than A[x,y,z] ,

Is it?

is someone successfully running the C-compiler from batch-file,
first converting all of the latter expressions
into the corresponding former ones and then compiling it ?

And while we're at it, this preprocessing utility should
also change array definitions like e.g.
int B[N];
into int B[N+1];
since B[N] would not be defined else, only B[0],B[1],..,B[N-1]

My advice would be to write the code correctly in the first place.
`int B[N]` defines an N-element array. It just has weird indexing.
You may think - I certainly do - that 0-based indexing is the work
of the devil, but that is the choice made for C, and you're better
off working with it (and hence not contrary to the usual behaviour
of those here who might help you) than against it.

 

[Skarmander]

it's awful in C with multi-dimension arrays.

A[x][y][z] is worse than A[x,y,z] ,

<snip>
If you want Pascal, you know where to get it.

S.

 

[Alexei A. Frounze]

it's awful in C with multi-dimension arrays.
A[x][y][z] is worse than A[x,y,z] ,

If you want Pascal, you know where to get it.

Maybe Matlab is a better try?
Alex

 

[Keith Thompson]

it's awful in C with multi-dimension arrays.

I don't disagree.

C doesn't actually have multi-dimensional arrays. It only has
one-dimensional arrays, but the element type can itself be an array
type; an array of arrays of arrays acts very much like a 3-dimensional
array.

A[x][y][z] is worse than A[x,y,z] ,

It's fine once you get used to it. Note also that A[x,y,z] is also a
valid expression (though not one that you'd ever want to use). The
comma operator evaluates both operands and yields the result of its
right operand, so A[x,y,z] is equivalent to A[z] (assuming x and y
have no side effects).

And because of the relationship between arrays and pointers, the
actual meaning of A[x][y][z] can vary depending on whether A is an
array of arrays of arrays, or a pointer to an array of pointers to
arrays of pointers to arrays (I think I got that right), or any of a
number of other possibilities. The pointer implementation is actually
more common because it's more flexible.

is someone successfully running the C-compiler from batch-file,
first converting all of the latter expressions
into the corresponding former ones and then compiling it ?

I sincerely hope not.

And while we're at it, this preprocessing utility should
also change array definitions like e.g.
int B[N];
into int B[N+1];
since B[N] would not be defined else, only B[0],B[1],..,B[N-1]

And while you're at it, you can do things like:

#define IF if(
#define THEN ){
#define ELSE }else{
#define ELSEIF }else if(
#define ENDIF }

and pretend you're writing in a different language altogether. Except
that you're still really programming in C, with all the drawbacks that
implies, with a thin and fragile layer of a different syntax on top of
it.

People have tried this kind of thing, and it's invariably a bad idea.
The result is something that experienced C programmers won't be able
to read because it doesn't look like C, and experienced programmers in
other languages won't be able to read because it doesn't quite look
like anything else.

There is an underlying logic to the way C is designed. You might not
like it (there are things I dislike myself), but you really should try
to understand it before you try to mess with it.

If you want to program in C, you should learn C, with all its little
quirks. If you dislike C so much, you should pick a different
language.

 

[sterten]

A[x][y][z] is worse than A[x,y,z] ,

>
>It's fine once you get used to it.

on German keyboards there is also the disadvantage that you have
to press the "altGr" key to get [] , which often makes typing
of math-programs difficult and erroneous. E.g. I often type
"}" instead of "]" and then it's hard to loacate the error.

....

>
>I sincerely hope not.

why ? Afraid others could improve their programming skills
and your own programs written in less advanced language
become less competitive ?

>> And while we're at it, this preprocessing utility should
>> also change array definitions like e.g.
>> int B[N];
>> into int B[N+1];
>> since B[N] would not be defined else, only B[0],B[1],..,B[N-1]

>
>And while you're at it, you can do things like:
>
> #define IF if(
> #define THEN ){
> #define ELSE }else{
> #define ELSEIF }else if(
> #define ENDIF }

these won't make notation much shorter or easier.
Although sometimes I wished the pre-compiler could
add things like "}" --> "} // next x"
It's hard in C to keep track of the nested levels of "{,}"

One other thing comes to mind, that is dynamical array definition.
Why can't I do : (or is there a way ?)
main(int argc,char*argv[]){
sscanf(argv[1],"%i",&n);
global int A[n];
}

>and pretend you're writing in a different language altogether. Except
>that you're still really programming in C, with all the drawbacks that
>implies, with a thin and fragile layer of a different syntax on top of
>it.
>
>People have tried this kind of thing, and it's invariably a bad idea.

please give a link or a searchable keyword and let me decide by myself

>The result is something that experienced C programmers won't be able
>to read because it doesn't look like C, and experienced programmers in
>other languages won't be able to read because it doesn't quite look
>like anything else.

you still have the output of the preprocessor which you could show
to these.

>There is an underlying logic to the way C is designed. You might not

>like it (there are things I dislike myself), but you really should try
>to understand it before you try to mess with it.

you won't expect that it's so perfect that it can't be improved...

>If you want to program in C, you should learn C, with all its little
>quirks.

no. I only need some few commands. When you require people to
learn "all the little quirks" - that might keep them away from C

>If you dislike C so much, you should pick a different
>language.

Not "so much". And why isn't it allowed to improve something
no matter how good it is already ?

And BTW. strangely enough I get the same advice from these
assembly programmers and Basic programmers where I wanted
to introduce some C-elements.
Let's combine the goodies from each language !



-Guenter

 

[Keith Thompson]

A[x][y][z] is worse than A[x,y,z] ,

It's fine once you get used to it.

on German keyboards there is also the disadvantage that you have
to press the "altGr" key to get [] , which often makes typing
of math-programs difficult and erroneous. E.g. I often type
"}" instead of "]" and then it's hard to loacate the error.

(Please don't snip attributions. It's helpful if readers can tell who
wrote what.)

Ok. That's not a problem I've ever run into; I can't think of a good
solution. (Maybe you could define an editor macro?)

why ? Afraid others could improve their programming skills
and your own programs written in less advanced language
become less competitive ?

Um, no. I just think it's a bad idea.

And while we're at it, this preprocessing utility should
also change array definitions like e.g.
int B[N];
into int B[N+1];
since B[N] would not be defined else, only B[0],B[1],..,B[N-1]

And while you're at it, you can do things like:

#define IF if(
#define THEN ){
#define ELSE }else{
#define ELSEIF }else if(
#define ENDIF }

these won't make notation much shorter or easier.
Although sometimes I wished the pre-compiler could
add things like "}" --> "} // next x"
It's hard in C to keep track of the nested levels of "{,}"

What do you mean by "pre-compiler"? It sounds like you want something
that modifies your source code. A language-sensitive text editor
could probably do that kind of thing.

One other thing comes to mind, that is dynamical array definition.
Why can't I do : (or is there a way ?)
main(int argc,char*argv[]){
sscanf(argv[1],"%i",&n);
global int A[n];
}

There's no "global" keyword, but C99 does support variable-length
arrays.

please give a link or a searchable keyword and let me decide by myself

Sorry, I don't have any references. I understand that the original
Bourne shell used something like the ugly pseudo-Pascal
BEGIN/END/IF/ELSE macros, but I believe it's been corrected.

you still have the output of the preprocessor which you could show
to these.

The preprocessor (if you mean the C preprocessor that's part of the
compiler) also expands #include directives and *all* macros, among
other things. The output isn't particularly legible.

you won't expect that it's so perfect that it can't be improved...

I didn't say that, or anything resembling it.

The C standard exists for a reason. It's certainly not perfect; there
are plenty of things I would have done differently. But it permits
consistency across programmers and implementations. If I write code
in C, any C programmer can read it. (Code is written for other
programmers as much as for the compiler.)

The English language has plenty of problems, and there are a lot of
changes I could suggest. I could invent an English-like language with
more logical spelling and grammar and a more consistent vocabulary.
But if I started writing in this new language, even if it's superior
to standard English, nobody would be able to understand me.

no. I only need some few commands. When you require people to
learn "all the little quirks" - that might keep them away from C

If you want to program in C without learning more than "some few
commands", I don't think we can help you.

Not "so much". And why isn't it allowed to improve something
no matter how good it is already ?

Lots of people have tried to improve C. They do it by inventing new
languages (C++, C#, Java, several languages calling themselves D).

And BTW. strangely enough I get the same advice from these
assembly programmers and Basic programmers where I wanted
to introduce some C-elements.
Let's combine the goodies from each language !

The best way to do that would be to create a new coherent language.
You can even use C as the intermediate language generated by the
compiler (the original "cfront" implementation of C++ did this).

 

[sterten]

what I had in mind and meant with "pre-compiler" or "preprocessor"
is a small utility which reads the C-"source" containing A[x,y]
or int A[n] and converts it into another C-source-file
where A[x,y] is converted into A[x][y] and int A[n]; into
int A[n+1] and maybe some other things too.

This can't be so difficult to write and probably already
exists somewhere ?!?

 

[Flash Gordon]

(e-mail address removed) wrote:

Provide context. I'm sure that one of two things is true:
1) You have already been given instructions on how to do this
2) You have been providing context.

In either case you have no excuse for not doing so now. There are plenty
of posts on the group giving instructions, so if you don't know how then
read yesterdays posts and you will find the instructions.

what I had in mind and meant with "pre-compiler" or "preprocessor"
is a small utility which reads the C-"source" containing A[x,y]
or int A[n] and converts it into another C-source-file
where A[x,y] is converted into A[x][y] and int A[n]; into
int A[n+1] and maybe some other things too.

This can't be so difficult to write and probably already
exists somewhere ?!?

It may well not be difficult, but I don't believe there is any *good*
reason for doing it for all the reasons Kieth and others have stated.

Some reasons are:
1) If you ran the code through such a utility twice it would not produce
an error but would *definitely* produce incorrect code.
e.g. int A[n] --> int A[n+1] --> int A[n+1+1]
2) No C programmer would find it easy to work with your original code
since it is written in something that is not quite C.
3) No non-C programmer would be able to work with your code since it
would be unlike any other language.
4) If you want a language that uses things like A[x,y] and allows arrays
to be indexed from something other than 0 there are plenty to choose
from.

Since you have not addressed any of the reasons people have stated why
what you are asking for is a bad idea we have absolutely no idea why you
are continuing with this unless it is that you are a troll.

BTW, there are plenty of things that I wish were different in C, but I
do what everyone else does and either use the language as is or use a
different language, I don't try to make C look like something different.

 

[Frodo Baggins]

Let's combine the goodies from each language !

Reminds me of Perl ; best of sed,awk,sh,etc combined.
Regards,
Mohan S N

 

[Roberto Waltman]

what I had in mind and meant with "pre-compiler" or "preprocessor"
is a small utility which reads the C-"source" containing A[x,y]
or int A[n] and converts it into another C-source-file
where A[x,y] is converted into A[x][y] and int A[n]; into
int A[n+1] and maybe some other things too.

This can't be so difficult to write and probably already
exists somewhere ?!?

(A) Converting A[x,y] into A[x][y]

That could work only under the assumption that an expression such as
A[x,y] will never occur in you code.

How can a preprocessor know if you mean a two-dimensional array or a
unidimensional one, where the comma operator is used to generate the
index?

A[z]
A[y,z]
A[x,y,z]
A[p,q,r,s,t,u,v,w,x,y,z]

These are all valid C expressions, all of them selecting the 'z'th
element of the unidimensional array A.


(B) Converting int A[n] into A[n+1];

(b.1) While that's more easily done, it may have many undesirable side
effects.
The loop (for i=0; i < MAX; i++) {...A...} is a very well C known
idiom, while (for i=1; i<= MAX; i++) {...A...} is not.
You can expect many "off by one" errors when using this approach with
existing code, or when linking your code with libraries expecting the
"C" way.

(b.2) Use C++. Use only the set of features common with C (*), so you
can fool yourself into thinking it is C, but define a set of classes
and overloaded [] operators providing the functionality you want.


(*) Yes, I know the "C is not a proper subset of C++" drill

Roberto Waltman

[ Please reply to the group, ]
[ return address is invalid. ]

 

[Keith Thompson]

what I had in mind and meant with "pre-compiler" or "preprocessor"
is a small utility which reads the C-"source" containing A[x,y]
or int A[n] and converts it into another C-source-file
where A[x,y] is converted into A[x][y] and int A[n]; into
int A[n+1] and maybe some other things too.

This can't be so difficult to write and probably already
exists somewhere ?!?

Flash Gordon has already reminded you about the context thing, so I
won't rant about that.

If you really wanted to, you could do something like this:

double A[10][20][30];
#define A_(x,y,z) (A[(x)][(y)][(z)])

You could then write A_(x,y,z) and have it expand to the equivalent of
A[x][y][z], but with extra parentheses to avoid operator precedence
problems.

A problem with this is that the scope of A is the same as for any
object declared at that point, but the scope of the A_ macro goes from
the point of its definition to the end of the file. Also, since
A_(x,y,z) doesn't use square brackets, it doesn't look like an array
indexing operation. A (possibly inline) function with the same
profile won't work because you can't assign to the result. A function
returning a pointer to the array element would require you to
explicitly dereference the pointer whenever you want to use it.
Personally, I find any of these options uglier than A[x][y][z], but
it's your call.

As for wanting arrays to be 1-based, the book _Numerical Recipes in
C_, available at <http://www.library.cornell.edu/nr/bookcpdf.html>,
uses some tricks that do this. I haven't looked at them in detail,
but I suspect they might invoke undefined behavior by using a base
address before the beginning of the array object (which will happen to
work if that base address happens to be within the address space of
the program).

 

[Mabden]

what I had in mind and meant with "pre-compiler" or "preprocessor"
is a small utility which reads the C-"source" containing A[x,y]
or int A[n] and converts it into another C-source-file
where A[x,y] is converted into A[x][y] and int A[n]; into
int A[n+1] and maybe some other things too.

This can't be so difficult to write and probably already
exists somewhere ?!?

Why would it. C programmers write C code.

If you really wanted to, you could do something like this:

double A[10][20][30];
#define A_(x,y,z) (A[(x)][(y)][(z)])

You could then write A_(x,y,z) and have it expand to the equivalent of
A[x][y][z], but with extra parentheses to avoid operator precedence
problems.

A problem with this is that

.... it's not C and no one else will know what the Hell is going on. So
this person should use a language they like or write their own.

You could make a Pascal programmer happy with a #define that changed {
and } into BEGIN and END, but it's not going to let them write a C
program, which is what they are trying to do.

As for wanting arrays to be 1-based

.... get the **** over it (the OP, not you Keith). In C the index is an
OFFSET!!!

Get it?!! The first member is OFFSET by NOTHING! It is the first one.
You are already there!! You don't take a step forward. You don't drive a
mile to get there - you are home. You are at Ground Zero! They don't
call it "Ground One"!!!

You can't change it, you can't hide it, we don't want to know why some
other language does it differently...

Deal with it!

 

[Mabden]

Reminds me of Perl ; best of sed,awk,sh,etc combined.

C#

 

[Netocrat]

C doesn't actually have multi-dimensional arrays. It only has
one-dimensional arrays, but the element type can itself be an array
type; an array of arrays of arrays acts very much like a 3-dimensional
array.

This is a false distinction, as evidenced by the standard:
6.5.2.1 Array subscripting
"Successive subscript operators designate an element of a
multidimensional array object."

I've pointed this quote out in the past, if I recall correctly you were
even involved in the thread where the subthread of "does C have
multidimensional arrays" sparked up.

If you want to program in C, you should learn C, with all its little
quirks. If you dislike C so much, you should pick a different
language.

Right - in C arrays index from 0 and multi-dimensional arrays are
indexed with successive square bracket enclosures. Anything else is
not C and at best will confuse a C programmer who has to maintain the
code (as Flash Gordon has pointed out the proposed scheme has worse
implications).

 

[sterten]

I won't run that converting utility in the rare cases, when I use
the comma-operator.
And when I show the code to other C-programmers I could still
show them the converted code.

So, who will be the first to write that useful command line utility
converting occurrances of A[x,y] to A[x][y] and int A[n]
to int A[n+1] (or similar)
for the benefit of all C-programmers ?

 

[Keith Thompson]

... get the **** over it (the OP, not you Keith). In C the index is an
OFFSET!!!

Get it?!! The first member is OFFSET by NOTHING! It is the first one.
You are already there!! You don't take a step forward. You don't drive a
mile to get there - you are home. You are at Ground Zero! They don't
call it "Ground One"!!!

You can't change it, you can't hide it, we don't want to know why some
other language does it differently...

Deal with it!

And we wonder why people think comp.lang.c is a hostile newsgroup.

Asking how to implement 1-based arrays in C is a perfectly legitimate
question. It happens that the answer is that there's no really good
way to do it, though there are a number of not-so-good ways to do it.

There are applications in which 1-based arrays are more convenient
than 0-based arrays. C's 0-based arrays are suited for systems
programming and for the convenience of the compiler. 1-based arrays
are much more convenient for some mathematical algorithms (see
_Numerical Recipes in C_, which I cited upthread). C's lack of
support for arrays starting at an index other than 0 is a
(justifiable) weakness of the language, not an immutable law of nature
justifying verbal abuse of anyone who questions it.

A future C standard, or an upward-compatible extension, could allow
an array to be defined either as
double arr[LENGTH];
or as
double arr[LO..HI];
Existing code would not be affected (unless I'm missing something).
Code that uses the new form would incur the overhead of computing the
offset rather than assuming it's 0 (the indexing operator would be
defined differently for based arrays. I'm not sure whether this would
be worth doing; it's always tempting to add just one more feature, but
the end result of too many such additions would be a *much* more
complex language.

<OT>
I suspect that C++'s operator overloading would make this fairly easy
to do. The OP might want to look into it, but we don't discuss C++
here. Try comp.lang.c++.
</OT>

There may well be some stupid questions, but there aren't many.
Stupid answers are far more common.

 

[Flash Gordon]

(e-mail address removed) wrote:

So, who will be the first to write that useful command line utility
converting occurrances of A[x,y] to A[x][y] and int A[n]
to int A[n+1] (or similar)
for the benefit of all C-programmers ?

How can you have failed to notice that NONE of the C programmers here
think it is a good idea or would be of benefit to anyone? The reasons
have been explained multiple times in different ways.

Since you seem to have an an inability to grasp the simple concepts
involved and won't say why you consider any of the stated reasons to be
invalid I can only conclude that you are a troll.

*plonk*

 

[Keith Thompson]

This is a false distinction, as evidenced by the standard:
6.5.2.1 Array subscripting
"Successive subscript operators designate an element of a
multidimensional array object."

I've pointed this quote out in the past, if I recall correctly you were
even involved in the thread where the subthread of "does C have
multidimensional arrays" sparked up.

Ok, good point (though I don't remember the previous discussion).

I'll rephrase. C has multidimensional arrays. They're implemented
as, and are indistinguishable from, arrays of arrays.

There are other languages that make the distinction. For example,
Pascal has both multidimensional arrays:
arr1: array[1..10,1..10] of float;
and arrays of arrays:
arr2: array[1..10] of array[1..10] of float;
with distinct syntax for indexing into them (arr1[x,y] vs. arr2[x][y])
and different semantics (you can easily extract a one-dimensional
array from an array of arrays, but not from a multidimensional array).

So yes, C has multidimensional arrays in much the same way that it has
pass-by-reference: it lets you build it explicitly on top of other
constructs. I'm not convinced the statement about multidimensional
arrays in 6.5.2.1 is strictly necessary (I think it probably follows
from other statements in the standard), but I have no problem with it
being re-stated.

[snip]

 

[Keith Thompson]

I won't run that converting utility in the rare cases, when I use
the comma-operator.
And when I show the code to other C-programmers I could still
show them the converted code.

So, who will be the first to write that useful command line utility
converting occurrances of A[x,y] to A[x][y] and int A[n]
to int A[n+1] (or similar)
for the benefit of all C-programmers ?

Who will be the first to write that useful command line utility
converting followups posted through groups.google.com so they include
proper quoting and attributions, so I can stop posting this:

If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.

The answer to your question is probably "nobody". That's not just
because it's a bad idea; it's because, as far as I can tell, there's
no real demand for such a thing other than you.

If you really want this thing implemented, you'll need at least two
things.

First, you'll need a rigorous specification of what you want,
including how it's going to handle corner cases. You can say that it
will refuse to translate certain things, or that it's undefined
behavior, but you should cover all the cases explicitly. This will
require a fairly thorough knowledge of C. Since you've expressed an
unwillingness to obtain such knowledge, you'll need some help with
this.

Second, you'll need to motivate someone who has sufficient time and
expertise to work on this. Since I doubt that anyone who has the
ability to do this would be interested in working on it for its own
sake (though I could easily be mistaken on that point), the most
effective motivator is likely to be money, probably a lot of it. I
don't know whether you're in a position to provide this motivation.

You'll have to spend some time working with whoever agrees to do this
for you, and you'll have to spend some additional time waiting for it
to be completed. I'm not going to try to estimate how much time.

I suggest that learning to use C as it exists is likely to take less
of your time, and none of anyone else's time, and little or no money.

What you do is, of course, entirely up to you, but that's my advice.

<OT>
You might also consider looking at C++. It implements operator
overloading and has a large runtime library called the STL; it may be
possible to do what you're looking for within the language. If you
have any questions about C++, comp.lang.c++ is down the hall on the
left (though you should consider studying the language on your own
before you start asking questions).
</OT>