arrays of strings and pointers

[bitshadow]

It's also possible that the expression 10*10000 could overflow (it's
of type int, which needn't be able to represent values greater than
32767).

True, but doesn't C allow the int type to change up to long long - if
the compiler supports it - to accomadate the int?

The malloc() is similar to the array declaration in that it allocates
(or attempts to allocate) the same amount of space, and the variable
name is spelled the same way. It's very different in that
char buf[10[[10000];
declares buf as an array object, whereas
buf = malloc(whatever);
implies that buf is a pointer. C FAQ, section 6.

thanks, i knew that . as for the FAQ you mean section 2? cause unless
i'm mistaken section 6 deals with the preprocessor.

also thanks for the pointers - no pun intended - on how to use google
groups. its more than annoying actually.

 

[Keith Thompson]

True, but doesn't C allow the int type to change up to long long - if
the compiler supports it - to accomadate the int?

No. An unsuffixed decimal integer constant such as 10 or 10000 has
the first of the following types that can represent its value:
int
long int
long long int

Since int can represent values up to at least 32767, both 10 and 10000
are guaranteed to be of type int. If their product, 10*10000, doesn't
fit in an int, an overflow results. (The list of types applies only
to individual integer constants, not to larger expressions.)

It's important to remember that the type of an expression in C is
determined by the expression itself, not by the context in which it
appears.

The malloc() is similar to the array declaration in that it allocates
(or attempts to allocate) the same amount of space, and the variable
name is spelled the same way. It's very different in that
char buf[10[[10000];
declares buf as an array object, whereas
buf = malloc(whatever);
implies that buf is a pointer. C FAQ, section 6.

thanks, i knew that . as for the FAQ you mean section 2? cause unless
i'm mistaken section 6 deals with the preprocessor.

also thanks for the pointers - no pun intended - on how to use google
groups. its more than annoying actually.

You're welcome. It's nice to know that my campaign actually has some
effect.

 

[Simon Biber]

No, it doesn't always apply.

It's clearer to say that it's implicitly converted to a pointer, not
that it "becomes" a pointer (the array is still there, after all).

An expression of array type is implicitly converted to a pointer to
its first element *unless* it's the operand of a unary "&" or "sizeof"
operator, or it's a string literal in an initializer.

Yes, I didn't think it necessary to mention that, but perhaps I should have.

 

[Neil Cerutti]

You're welcome. It's nice to know that my campaign actually
has some effect.

I applaud your campaign to teach people using Google Groups how
to post properly to usenet. My only criticism of the effort is
that the language you use in the standard response is prejudicial
instead of simply instructional. If you removed the references to
Google's brokeness, I think it would be improved.

But you're doing the dirty work, so do it the way you like. ;-)

 

[Flash Gordon]

Neil Cerutti wrote:

I applaud your campaign to teach people using Google Groups how
to post properly to usenet. My only criticism of the effort is
that the language you use in the standard response is prejudicial
instead of simply instructional. If you removed the references to
Google's brokeness, I think it would be improved.

Part of what we are trying for is enough people complaining to Google
that they actually fix it.

But you're doing the dirty work, so do it the way you like. ;-)

 

[Default User]

Neil Cerutti wrote:



Part of what we are trying for is enough people complaining to Google
that they actually fix it.

It also lays off the blame from the user to the tool, which can make it
a bit easier to swallow (theoretically).



Brian

 

[Alan Balmer]

I applaud your campaign to teach people using Google Groups how
to post properly to usenet. My only criticism of the effort is
that the language you use in the standard response is prejudicial

Nope, it's judicial, but not prejudicial.

 

[Keith Thompson]

I applaud your campaign to teach people using Google Groups how
to post properly to usenet. My only criticism of the effort is
that the language you use in the standard response is prejudicial
instead of simply instructional. If you removed the references to
Google's brokeness, I think it would be improved.

I didn't prejudge anything. I looked at Google's interface and
concluded that it's broken. This entire mess is Google's fault, and
they've stubbornly refused to fix it.

But you're doing the dirty work, so do it the way you like. ;-)

Thanks.

 

[Neil Cerutti]

Nope, it's judicial, but not prejudicial.

Point taken. I only meant that the instructions favor a
preconceived notion, i.e., that Google's interface is broken.
_The C++ Programming Language_ by Stroustrup would be diminished
if legitimate bashing of other programming languages was
included.

 

[Jordan Abel]

Point taken. I only meant that the instructions favor a
preconceived notion, i.e., that Google's interface is broken.

It's not a preconceived notion. It's a fact supported by
observational evidence.

now, from a philosophical point of view, one _could_ challenge the
idea that an interface which behaves in that way is necessarily
broken... but then one would be wrong.

 

[Keith Thompson]

Point taken. I only meant that the instructions favor a
preconceived notion, i.e., that Google's interface is broken.

It is not a preconceived notion. It's a conclusion reached by
observing Google's interface and its effects on this newsgroup.

Before they rolled out their current interface, any prejudice I had
would have been in favor of Google. I like Google, and I'm impressed
by what they've accomplished. The brokenness of their current
groups.google.com interface was an unpleasant surprise.

_The C++ Programming Language_ by Stroustrup would be diminished
if legitimate bashing of other programming languages was
included.

I don't think that's a good analogy. We're critiquing the Google
interface. A critique of a programming language would inevitably
include criticisms of that language.

 

[Neil Cerutti]

It is not a preconceived notion. It's a conclusion reached by
observing Google's interface and its effects on this newsgroup.

I just meant it in the sense of being decided beforehand, not in
the sense of being conceived without evidence or through
prejudice. It was not a fair word to use; I probably chose it for
the negative connotations, and now look like a jerk claiming I
didn't mean it in a negative way. Sorry for the cheap rhetorical
trick, which several people have properly called me on.

 

[Alan Balmer]

Point taken. I only meant that the instructions favor a
preconceived notion, i.e., that Google's interface is broken.

I'd call that an observation, not a preconceived notion ;-) It
previously worked adequately, and now it doesn't.

 

[Keith Thompson]

I just meant it in the sense of being decided beforehand, not in
the sense of being conceived without evidence or through
prejudice. It was not a fair word to use; I probably chose it for
the negative connotations, and now look like a jerk claiming I
didn't mean it in a negative way. Sorry for the cheap rhetorical
trick, which several people have properly called me on.

Ok, fair enough.

I still don't understand what you mean by "decided beforehand", but we
can just drop it if you like.

 

[Neil Cerutti]

I still don't understand what you mean by "decided beforehand",
but we can just drop it if you like.

Decided before writing the instructions. The instructions do
actually contain some argument for the broken conclusion though,
so now I don't know what I mean either. ;-)

 

[Dave Thompson]

There are at least four different ways to implement a data structure
that acts like 2-dimensional array.

If you want a variable number of fixed-size arrays, you can declare
an array of pointers:
int *arr2[10];

If you want a fixed number of variable-size arrays, you can declare
a pointer to an array:
int (*arr3)[10];

You have the antecedent clauses swapped. (Or both the consequents and
code, which I assumed is less likely.)

If you want maximum flexibility, you can declare a pointer-to-pointer:
int **arr4;

For arr2, arr3, and arr4, you have to do your own memory management.
For arr4, you have to allocate an array of pointers *and* multiple
arrays of int, one for each row of the 2d-array-like data structure.

For array-of-pointer (2) and pointer-to-pointers (4) you don't have to
allocate each row separately; you can allocate one big chunk, or even
several midsized ones, and set pointers into them. But only if you
don't need to independently change the size(s) of rows that are
allocated together; and you must either know a priori or keep track of
which ones are the original allocations (thus) to be free'd. This is
enough of a pain that I would usually stick with the simple way.

<snip rest including pointer to FAQ section 6> concur.

- David.Thompson1 at worldnet.att.net

 

[Keith Thompson]

There are at least four different ways to implement a data structure
that acts like 2-dimensional array.

If you want a variable number of fixed-size arrays, you can declare
an array of pointers:
int *arr2[10];

If you want a fixed number of variable-size arrays, you can declare
a pointer to an array:
int (*arr3)[10];

You have the antecedent clauses swapped. (Or both the consequents and
code, which I assumed is less likely.)

You're right, I goofed. Thanks for catching it.

For array-of-pointer (2) and pointer-to-pointers (4) you don't have to
allocate each row separately; you can allocate one big chunk, or even
several midsized ones, and set pointers into them. But only if you
don't need to independently change the size(s) of rows that are
allocated together; and you must either know a priori or keep track of
which ones are the original allocations (thus) to be free'd. This is
enough of a pain that I would usually stick with the simple way.

I was assuming a potential need to reallocate the individual chunks,
or to allocate them separately rather than all at once. Certainly you
can sometimes optimize by allocating multiple chunks together, if you
have enough information.