473,322 Members | 1,314 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

A[x][y][z]

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]

Nov 15 '05 #1
38 1444
st*****@aol.com wrote:
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.

--
Chris "am I troll-caught?" Dollin
The software engineer's song: "who knows where the time goes".
Nov 15 '05 #2
st*****@aol.com wrote:
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.
Nov 15 '05 #3
"Skarmander" <in*****@dontmailme.com> wrote in message
news:43***********************@news.xs4all.nl...
st*****@aol.com wrote:
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
Nov 15 '05 #4
st*****@aol.com writes:
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #5
>> 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.

....
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.


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. Exceptthat you're still really programming in C, with all the drawbacks thatimplies, with a thin and fragile layer of a different syntax on top ofit.

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 inother 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 tryto 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

Nov 15 '05 #6
st*****@aol.com writes:
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?)
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.


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.
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.b


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.
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.


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.
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...


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.
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 want to program in C without learning more than "some few
commands", I don't think we can help you.
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 ?


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).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #7

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 ?!?

Nov 15 '05 #8
st*****@aol.com 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.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Nov 15 '05 #9
> Let's combine the goodies from each language !

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

Nov 15 '05 #10
st*****@aol.com writes:
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).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #11
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
st*****@aol.com writes:
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 fuck 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
Nov 15 '05 #12
"Frodo Baggins" <fr*********@gmail.com> wrote in message
news:11*********************@g44g2000cwa.googlegro ups.com...
Let's combine the goodies from each language !


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


C#

--
Mabden
Nov 15 '05 #13
Keith Thompson wrote:
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).

Nov 15 '05 #14
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 ?

Nov 15 '05 #15
"Mabden" <mabden@sbc_global.net> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

[...]
As for wanting arrays to be 1-based


... get the fuck 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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #16
"Netocrat" <ne******@dodo.com.au> writes:
Keith Thompson wrote:
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.


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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #17
st*****@aol.com writes:
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>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #18
st*****@aol.com wrote:

<snip>
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*
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Nov 15 '05 #19
In article <3O************@newssvr12.news.prodigy.com>,
Mabden <mabden@sbc_global.net> wrote:


"Frodo Baggins" <fr*********@gmail.com> wrote in message
news:11*********************@g44g2000cwa.googlegro ups.com...
Let's combine the goodies from each language !


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


C#


PL/I.
Nov 15 '05 #20
Anonymous 7843 wrote:
In article <3O************@newssvr12.news.prodigy.com>,
Mabden <mabden@sbc_global.net> wrote:

"Frodo Baggins" <fr*********@gmail.com> wrote in message
news:11*********************@g44g2000cwa.googleg roups.com...

Let's combine the goodies from each language !
Reminds me of Perl ; best of sed,awk,sh,etc combined.

C#


PL/I.

Bliss/10
Nov 15 '05 #21
Reminds me of Perl ; best of sed,awk,sh,etc combined.
C#


PL/I.

Bliss/10

why always create a new incompatible language when you
just have some small improvements ?

you need a new compiler and your old programs will
no longer run.

Nov 15 '05 #22
st*****@aol.com writes:
>>>Reminds me of Perl ; best of sed,awk,sh,etc combined.
>>>
>>>
>>C#
>>
>>
>
>PL/I.
>
>

Bliss/10

why always create a new incompatible language when you
just have some small improvements ?

you need a new compiler and your old programs will
no longer run.


Because sometimes a new dialect with small improvements is too close
to the original language. It can be unclear which version of the
language you're using.

I might even argue that C++'s closeness to C is a disadvantage. C and
C++ are far enough apart to be two distinct languages, but they're
still close enough that a lot of programmers think there's such a
thing as "C/C++".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #23
C Wegrzyn wrote:
Reminds me of Perl ; best of sed,awk,sh,etc combined.
C#


PL/I.

Bliss/10


bliss was (is) actually cool. No C#, PL/I, Java, etc please.

Nov 15 '05 #24

st*****@aol.com wrote:
So, who will be the first to write that useful command line utility
converting occurrances of A[x,y] to A[x][y]...


This would be a simple one-liner in the elegant Snobol language.Sadly,
the references to Snobol that show up
with Google are mostly 6-year old messages, complaining
that Snobol has disappeared!

But this is comp.lang.c not comp.lang.snobol.
Let me try to help OP.

<diatribe>
C is a victim of its own success!

I don't think Fortran programmers ever say
"Let's make our language more like Pascal."
Ones that might ... switch to Pascal!
Similarly, while most consider some languages,
e.g. Forth or APL, to have perverse syntax,
those who go out of their way to use Forth or
APL, almost by definition, like the "perversity"!

But C's rich elegant combination of simplicity
and flexibility and the fact that it was better
suited than prior languages to a wide variety of
applications recommended itself to many expert
programmers in the 1970's and 80's and it soon
become widespread ... even among many who
couldn't appreciate its elegance.

One of the most elegant features of C is the
identity between the referencing of pointers
and array elements. Yet this seems to be
consistently confused by novices! Why? It
can't be that C is "too complicated" -- C is
based on a tiny set of elegant principles.
I think the problem is that novices can't
believe such a powerful language is *so simple*!

One example of such simplicity is the fact, as
Keith Thompson points out, that arrays are always
one-dimensional: a 2-D array is an array of
arrays.

Viewed in total isolation, the question of whether
to start array indexes at 0 or 1 may be a legitimate
open question, but in C the question answers itself
once one notices that the following expressions
(outside sizeof, etc.) must be identical in C:
*p
*(p+0)
0[p+0]
p[0+0]
p[0]
Anyone who suggests that C indexes should start at 1,
doesn't even understand this much: the idea that their
opinion on C might have merit is laughable.

Similarly, since in the 4-D array expression
a[b][c][d][e]
one can't know, without studying the declarations,
whether 'a' is an array of pointers to arrays
of pointers, a pointer to an array of pointers
to arrays, or one of several other possibilities,
the idea of obfuscating this further by writing
a[b,c,d,e]
suggests lack of understanding. (We're sorry if
'[' and ']' are hard to produce on German keyboards
but I'm sure there's workarounds for that.)

(Do any other languages, besides C++ and others that
model their syntax on C, have a similar elegant
array/pointer model?)

Finally, it shows grave confusion to suggest that
someone who prefers to see C syntax when they're reading
a C program should simply run 'cc -E'. We all look
at intermediate compilation results when there's a
reason, but viewing unobfuscated source shouldn't be
one of them. To give only one of the most obvious
objections, on all compilers I've tried 'cc -E' will
remove comments; did OP overlook this?

No one claims the C language is a perfect panacea, but
it has an enviable elegance. Novices should devote
themselves to grasping that elegance before offering
"improvements."
</diatribe>

James Dow Allen

Nov 15 '05 #25
James Dow Allen wrote:

....
Anyone who suggests that C indexes should start at 1,
doesn't even understand this much: the idea that their
opinion on C might have merit is laughable.
I didn't suggest, that indices should start at 1,
starting at 0 is fine, but
I just suggested that e.g. int A[n]; should reserve n+1
memory-cells instead of n. Or that we have a preprocessor utility
to change int A[n] into int A[n+1] before the compiler
gets it from batch file or in a child process.
Very often you are using A[n] and want it to hold integers 1..n,
with or without 0.
I guess, this is a quite common error for C-programmers,
that they define int A[n]; and then access A[n] , e.g.
A[n]=x;
Now this may overwrite some other variable stored at [A+n]
causing strange behaviour in the program which is hard to debug.
I do consider this one of the worst problems with C.
If you think, arrays should be defined usually on A[0,..,n-1],
that's quite uncommon. Look at any math. or combinatorics
or numerics textbook or paper.
You are just _producing_ thousands of invain hours of
debugging by suggesting this A[n] - behaviour.
No matter how "beautiful" or "elegant" or
"logical" you might consider it. As I said, a programming
language has to be functional and easy to use and debug,
that's what it has been designed for, that's what it is
being used for, not elegance.
Similarly, since in the 4-D array expression
a[b][c][d][e]
one can't know, without studying the declarations,
whether 'a' is an array of pointers to arrays
of pointers, a pointer to an array of pointers
to arrays, or one of several other possibilities,
the idea of obfuscating this further by writing
a[b,c,d,e]
your opinion that
a[b,c,d,e] is more "obfuscated" than
a[b][c][d][e] seems very strange to me.
The first one is shorter and has fewer parentheses,
parentheses are always hard to follow, since you have
to keep track where they open and where they close.
It's even worse when you have nested expressions
like A[A[x][y]][z]=A[x][A[y][z]] which is nothing
more than simple associative law.
It's also completely uncommon in textbooks,papers.
suggests lack of understanding. (We're sorry if
'[' and ']' are hard to produce on German keyboards
but I'm sure there's workarounds for that.)
yes. Give a link to the utility I'm looking for.
(Do any other languages, besides C++ and others that
model their syntax on C, have a similar elegant
array/pointer model?)

Finally, it shows grave confusion to suggest that
someone who prefers to see C syntax when they're reading
a C program should simply run 'cc -E'. We all look
at intermediate compilation results when there's a
reason, but viewing unobfuscated source shouldn't be
one of them. To give only one of the most obvious
objections, on all compilers I've tried 'cc -E' will
remove comments; did OP overlook this?
I don't know about cc -E
No one claims the C language is a perfect panacea, but
it has an enviable elegance. Novices should devote
themselves to grasping that elegance before offering
"improvements."
</diatribe>


that seems to me a bit as if you enjoyed presenting problems to
novices just in order to be able to demonstrate your superior
concept of elegance.
-Guenter.

Nov 15 '05 #26
"James Dow Allen" <jd*********@yahoo.com> writes:
st*****@aol.com wrote: [...] <diatribe>
C is a victim of its own success!

I don't think Fortran programmers ever say
"Let's make our language more like Pascal."
Ones that might ... switch to Pascal!
Well, that's not quite true. Google "Ratfor" for details. (It's
almost topical; Brian Kernighan invented it.)

[...]
One of the most elegant features of C is the
identity between the referencing of pointers
and array elements. Yet this seems to be
consistently confused by novices! Why? It
can't be that C is "too complicated" -- C is
based on a tiny set of elegant principles.
I think the problem is that novices can't
believe such a powerful language is *so simple*!
Hmm. Elegence is in the eye of the beholder, but I've never found C's
relationship between arrays and pointers particularly elegant. My
preference would be for arrays to be first-class objects, and for
array indexing to be defined as array indexing rather than being
derived from lower-level operations.

It confuses novices because it's confusing.

Of course it can't be "fixed" without breaking existing code (and
plenty of people like it the way it is).

[...]
Viewed in total isolation, the question of whether
to start array indexes at 0 or 1 may be a legitimate
open question, but in C the question answers itself
once one notices that the following expressions
(outside sizeof, etc.) must be identical in C:
*p
*(p+0)
0[p+0]
p[0+0]
p[0]
Anyone who suggests that C indexes should start at 1,
doesn't even understand this much: the idea that their
opinion on C might have merit is laughable.
They *must* be identical because existing code would break if they
weren't. That doesn't necessarily imply that a C-like language
couldn't be devised in which they aren't identical, and arrays behave
differently.

We agree that it's not a particularly good idea, at least in the form
the OP suggested, but we disagree about why.

[...]
Finally, it shows grave confusion to suggest that
someone who prefers to see C syntax when they're reading
a C program should simply run 'cc -E'. We all look
at intermediate compilation results when there's a
reason, but viewing unobfuscated source shouldn't be
one of them. To give only one of the most obvious
objections, on all compilers I've tried 'cc -E' will
remove comments; did OP overlook this?
I don't think that's what the OP was suggesting. He was proposing a
"preprocessor" (call it a translator or precompiler) that, for
example, changes arr[x][y] to arr[x,y]. The output of this translator
would be legible standard C.
No one claims the C language is a perfect panacea, but
it has an enviable elegance. Novices should devote
themselves to grasping that elegance before offering
"improvements."
</diatribe>


Other that the "elegance" part, I agree.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #27
st*****@aol.com writes:
James Dow Allen wrote:

[...]
>suggests lack of understanding. (We're sorry if
>'[' and ']' are hard to produce on German keyboards
>but I'm sure there's workarounds for that.)


yes. Give a link to the utility I'm looking for.


As far as I know, it doesn't exist. Sorry.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #28
Keith Thompson wrote:
st*****@aol.com writes:
James Dow Allen wrote:


[...]
>suggests lack of understanding. (We're sorry if
>'[' and ']' are hard to produce on German keyboards
>but I'm sure there's workarounds for that.)


yes. Give a link to the utility I'm looking for.

As far as I know, it doesn't exist. Sorry.

It's called a C compiler with digraph support. <: and :> will be
replaced internally with [ and ] on compilation. GCC is such a compiler.

A much better idea is to remap the keyboard or customize the editor to
produce some easy hotkey for [ and ] (easier than AltGr + some number),
since <: and :> aren't necessarily convenient either (and serves as a
nice illustration of why most people consider digraphs (and trigraphs)
next to useless).

That said, since the German QWERTZ keyboard is about as unfriendly as
possible for the standard C characters (just about anything is hidden
behind Alt or even Alt+Shift), I recommend just using a slightly
modified layout with [/{ instead of ö/Ö, and ]/} instead of ä/Ä. It
depends on your OS how easy or hard it is to define a custom layout.

You won't need German characters unless you're entering comments or
string literals, and that is easily taken care of with a hotkey for
switching layouts.

It will take a little getting used to, but it'll make for much easier
typing in the long run.

S.
Nov 15 '05 #29
James Dow Allen wrote:

<snip>
I don't think Fortran programmers ever say
"Let's make our language more like Pascal."
Ones that might ... switch to Pascal!


Fortran 77 and 90 did borrow many features of structured programming
that already existed in Pascal and C, such as

(1) block if-else-elseif statements
(2) loops (without the need for a numbered CONTINUE in F90)
(3) user-defined types

Visual Basic, compared to the original BASIC, has undergone a similar
evolution.

Nov 15 '05 #30

Keith Thompson wrote:
And we wonder why people think comp.lang.c is a hostile newsgroup.
Not to support rudeness ...
There are applications in which 1-based arrays are more convenient
than 0-based arrays.
Or disagree with this
1-based arrays
are much more convenient for some mathematical algorithms (see
_Numerical Recipes in C_, which I cited upthread).


But this is a bad argument. I am initimately familiar with the book
.... the use of 1 based arrays was for ease of translation from
algorithms that had been coded in Fortran in previous versions of the
book, and the exact implementation invoked undefined behaviour (as you
mentioned in passing). The original Fortran coded examples were
actually useful, they were idiomatic for the language. The C examples,
when that came out, were completely unidiomatic and difficult to
follow; but a limited amount of effort had been put into it making it
useable. The Fortran 90 version, as far as I and my friends can see,
are actually almost unuseable (and I haven't looked for any more modern
versions :-)

Yes not letting the arrays be anything other than 0 based is a weakness
of C. There are, however, very few algorithms where the structure of
the indexing set matters nontrivially, and even in those cases it is
usually the order relation that is important. In the few cases that it
does matter, sets of the form {0...b^n-1} (I am using ^ for `to the
power') are by far the most common.

I am not saying that one does not think of the first or second rather
than zeroth element: one certainly does. But that is a trivial change
during i/o or converting some field in a record. What I am saying that
when one needs to do arithmetic with the index, it is usually (but not
always) the zero based index that one wants. (Ask me! Having
programmed in various versions of Fortran now for well over twenty
years, I know how happy I was when I could use zero based arrays in
Fortran. And I also know how little it really matters in real life
when one gets used to using the `wrong' offset.)

In fact next to the indexing set {0...b^n-1}, the one I would like most
is not {1...b^n-1}, but rather {-b^n+1...b^n-1}. 1 based arrays is,
and I speak from experience, is not really a big deal.

Nov 15 '05 #31
On 6 Oct 2005 01:39:21 -0700, in comp.lang.c , st*****@aol.com wrote:
James Dow Allen wrote:

...
Anyone who suggests that C indexes should start at 1,
doesn't even understand this much: the idea that their
opinion on C might have merit is laughable.
I didn't suggest, that indices should start at 1,
starting at 0 is fine, but
I just suggested that e.g. int A[n]; should reserve n+1
memory-cells instead of n. Or that we have a preprocessor utility
to change int A[n] into int A[n+1] before the compiler
gets it from batch file or in a child process.


Why? Because you're incapable of recalling that the first element of
an array is at zero off set from the start? Because you're lazy?
Very often you are using A[n] and want it to hold integers 1..n,
with or without 0.
I guess, this is a quite common error for C-programmers,


Only when they're beginners. It must be practically the first lesson
one learns about arrays.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 15 '05 #32
On 6 Oct 2005 07:01:16 -0700, in comp.lang.c , ta*********@gmail.com
wrote:

Keith Thompson wrote:
(i'm not convinced he did, but...)
1-based arrays
are much more convenient for some mathematical algorithms (see
_Numerical Recipes in C_, which I cited upthread).


But this is a bad argument. I am initimately familiar with the book
... the use of 1 based arrays was for ease of translation from
algorithms that had been coded in Fortran


More accuirately, tehy were coded thus because the writers were
Fortran programmers who knew very little C, and seemingly lacked the
skills to reimplement their algos in C. So instead they literally
xlated the fortran, then wrote helper functions to mangle the C arrays
into fortran ones... yeuch.
Yes not letting the arrays be anything other than 0 based is a weakness
of C.


Sure, there are sometimes needs for arrays not starting at one, or for
sparse arrays. C happens not to have native support for that, well
excuse me but it also doesn't have native support for fast fourier
transforms or gaussian integrals or threads, all of which would also
be useful too. Is their lack a weakness?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 15 '05 #33
Mark McIntyre wrote:
On 6 Oct 2005 01:39:21 -0700, in comp.lang.c , st*****@aol.com wrote:

James Dow Allen wrote:

...
Anyone who suggests that C indexes should start at 1,
doesn't even understand this much: the idea that their
opinion on C might have merit is laughable.


I didn't suggest, that indices should start at 1,
starting at 0 is fine, but
I just suggested that e.g. int A[n]; should reserve n+1
memory-cells instead of n. Or that we have a preprocessor utility
to change int A[n] into int A[n+1] before the compiler
gets it from batch file or in a child process.

Why? Because you're incapable of recalling that the first element of
an array is at zero off set from the start? Because you're lazy?

Very often you are using A[n] and want it to hold integers 1..n,
with or without 0.
I guess, this is a quite common error for C-programmers,

Only when they're beginners. It must be practically the first lesson
one learns about arrays.


If you can't decide whether your indexing should be rel-0 or rel-1, to
what IBM does. Use both. IBM disk formats have Tracks and Sectors. The
first track on a disk is 0. The first sector on the track is 1. Go
figure. :-)

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 15 '05 #34
Mark McIntyre <ma**********@spamcop.net> writes:
On 6 Oct 2005 07:01:16 -0700, in comp.lang.c , ta*********@gmail.com
wrote:
Keith Thompson wrote:


(i'm not convinced he did, but...)
1-based arrays
are much more convenient for some mathematical algorithms (see
_Numerical Recipes in C_, which I cited upthread).


But this is a bad argument. I am initimately familiar with the book
... the use of 1 based arrays was for ease of translation from
algorithms that had been coded in Fortran


More accuirately, tehy were coded thus because the writers were
Fortran programmers who knew very little C, and seemingly lacked the
skills to reimplement their algos in C. So instead they literally
xlated the fortran, then wrote helper functions to mangle the C arrays
into fortran ones... yeuch.


Yes, I did write that, and I was very likely wrong. I briefly skimmed
the relevant section of _Numerical Recipes in C_ and came away with
the impression that the advantages of 1-based arrays are inherent to
certain algorithms rather than based on their initial implementation
in Fortran. Now that others have said that's not the case, I'll just
bow out, since I lack the expertise to say anything useful.
Yes not letting the arrays be anything other than 0 based is a weakness
of C.


Sure, there are sometimes needs for arrays not starting at one, or for
sparse arrays. C happens not to have native support for that, well
excuse me but it also doesn't have native support for fast fourier
transforms or gaussian integrals or threads, all of which would also
be useful too. Is their lack a weakness?


Arrays starting at a user-specified base index are a common feature in
a number of other languages. There's always a tradeoff between adding
features and keeping a language small and elegant, and I'm not going
to argue that C made the wrong choice. FFTs and Gaussian integrals
are (I think) more sensibly implemented as library functions; threads
can be implemented as a library too. But in any case, I don't
consider it a huge deal.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #35
In C, given an array `whatever[size]' the expression
`whatever' (outside sizeof, etc.) is a pointer.
I'm sure I'm not the only who was amazed to discover
how well this works out: array arguments become, in
effect, calls by name automatically; analyzing
"multidimensional" array expressions becomes easy;
pointer and array addressing become a single thing
to understand instead of two.

C programmers are not *required* to agree that the
array/pointer relationship is *beautiful* but they
need to understand and accept it. It, unlike
trivia such as the spelling of `foo += 1', is central
to C's essence.

Keith Thompson wrote:
"James Dow Allen" <jd*********@yahoo.com> writes:
...
Viewed in total isolation, the question of whether
to start array indexes at 0 or 1 may be a legitimate
open question, but in C the question answers itself
once one notices that the following expressions
(outside sizeof, etc.) must be identical in C:
*p
*(p+0)
0[p+0]
p[0+0]
p[0]


They *must* be identical because existing code would break if they
weren't. That doesn't necessarily imply that a C-like language
couldn't be devised in which they aren't identical, and arrays behave
differently.


Given that the array/pointer relationship is essential
to C, I assume what you're suggesting is that
C could have been consistently defined so that the
expression (*p) evaluates to (p[1]). Now (*(p+6))
would be (p[7]) and so on. Did you have something
else in mind?
No one claims the C language is a perfect panacea, but
it has an enviable elegance. Novices should devote
themselves to grasping that elegance before offering
"improvements."


Other that the "elegance" part, I agree.


"Elegance" is hard to define and best grasped with
examples. The property of ordinary expressions that
*(p+6) is equivalent to p[6]
would be devastatingly less elegant if replaced with
*(p+6) is equivalent to p[7]
James D. Allen

Nov 15 '05 #36
"James Dow Allen" <jd*********@yahoo.com> writes:
[...]
Keith Thompson wrote: [...]
They *must* be identical because existing code would break if they
weren't. That doesn't necessarily imply that a C-like language
couldn't be devised in which they aren't identical, and arrays behave
differently.


Given that the array/pointer relationship is essential
to C, I assume what you're suggesting is that
C could have been consistently defined so that the
expression (*p) evaluates to (p[1]). Now (*(p+6))
would be (p[7]) and so on. Did you have something
else in mind?


Yes, I did. What I had in mind is making arrays first-class objects,
and decoupling arrays and pointers. x[y] would be defined as the y'th
element of the array x, not as *(x+y). Array names would not decay to
pointers. Since indexing wouldn't be defined in terms of pointer
arithmetic, allowing a user-defined base (e.g., "int arr[10..20];")
wouldn't break anything further.

This is *purely* hypothetical, of course. Such a change could not be
made without breaking tons of existing code.

[...]
"Elegance" is hard to define and best grasped with
examples. The property of ordinary expressions that
*(p+6) is equivalent to p[6]
would be devastatingly less elegant if replaced with
*(p+6) is equivalent to p[7]


Absolutely. There's probably no way to provide non-zero-based arrays
in C without radical changes to the language, and I'm not advocating
any such changes. (Operator overloading might provide some
possibilities, but there's always C++ for that.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #37
On Sun, 02 Oct 2005 20:50:19 GMT, Keith Thompson <ks***@mib.org>
wrote:
<snip>
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).
Are you sure? The standard (7185) says these are just 'abbreviations'
(sugar) for the array-of-array form, and I don't recall original (J&W)
as being any different in this area.

COBOL similarly creates multidim arrays (only) as array of group
consisting of array etc., but allows abbreviated subscripting.

Fortran, PL/I, and Ada have true (distinct) multidim arrays, and the
first two have special notations for subarrays/slices. (Ada has slices
only for 1-dim arrays, the simple and easy case.) And APL of course.
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.
Concur.
[snip]


- David.Thompson1 at worldnet.att.net
Nov 15 '05 #38
Dave Thompson <da*************@worldnet.att.net> writes:
On Sun, 02 Oct 2005 20:50:19 GMT, Keith Thompson <ks***@mib.org>
wrote:
<snip>
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).

Are you sure? The standard (7185) says these are just 'abbreviations'
(sugar) for the array-of-array form, and I don't recall original (J&W)
as being any different in this area.

[...]

No, I'm not sure. I haven't used Pascal in a long time, and I
probably confused its treatment of arrays with Ada's. Now that I
think about it, I believe you're right.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #39

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Jeff Lambert | last post by:
I have this function everywhere in our SQL server 2000 stored procedures. Has anyone written a workaround function for it? I would appreciate if you could share. As you can imagine, searching the...
14
by: Bernhard Sturm | last post by:
Hi group I have a rather peculiar question, and I really don't know how to solve this within an SQL statement: Given a view (v), that results in: ID X ----------------- 1 a 1 b
8
by: James Bradley | last post by:
Hi Folks, I am coming up to speed with C# and I have run into an interesting issue. I have an old VB COM library that I need to access with a ProgId == 'xyz' I also have a C# class that is...
2
by: Roger Lord | last post by:
I am constructing a string in my program and then trying to use it to get the value of an integer variable whose label looks like that string. I can't figure out how to do it. For example: Dim...
1
by: bitwxtadpl | last post by:
Hi, I have a simple parsing regular expression that is expecting data and a delimiter. Axy where A is the data and xy is the delimiter When the delimiter is xy it works as expected. But, when I...
0
by: Alexander Eisenhuth | last post by:
Hello Together, Shortly what I'm doing: - Extending python with boost.pthon extension - Using python C-Api for datatypes in the extension - extension has a thread (that can be stopped/started)...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.