> No, it's not, you have to explicitly dereference a pointer to get that
> so you would have to use *p rather than p.
This is what I get for writing an email during working hours. :)
Yes, you're right. I am dumb :(
>
> > Thus, p = mem[1]='h'. If
> > we add 1 to p, though, we're changing the contents of the memory space 1 -
> > it goes from 'h' to 'i'. Now, p = mem[1] = 'i'.
> >
> Nope, you'll be incrementing the pointer p so that p will point to space
> 2 which is 'i'.
>
> > What if we wanted p to just go to the next box? Well we add 1 to
> > *p!
>
> Wrong again, to do that you want to add 1 to p, if you add 1 to *p then
> p will still point to space 1 and the value in space 1 will be
> incremented from 'h' to 'i'.
Really! I can code! I know how it works! really! *cries*
>
> > Let's do that, so now p = mem[2] = 'i'. Same letter as mem[1], but
> > in a different place;
> >
> > 1 2 3 4 5 6 7 8
> > |-----|-----|-----|-----|-----|-----|-----|-----|
> > | 'i' | 'i' | '\0'| ? | 2 | ? | ? | ? |
> > |-----|-----|-----|-----|-----|-----|-----|-----|
> >
> If you first added 1 to p then you added 1 to *p you would end up with
> this...
>
> > 1 2 3 4 5 6 7 8
> > |-----|-----|-----|-----|-----|-----|-----|-----|
> > | 'h' | 'j' | '\0'| ? | 2 | ? | ? | ? |
> > |-----|-----|-----|-----|-----|-----|-----|-----|
>
> > So, a pointer only takes up one box, and describes the address
> > of other places in memory.
>
> Actually the amount of space a pointer takes up is
> implementation-defined. I think that most modern implementations use 32
> bit pointers but it could be more, or less. You best bet is to not
> write code that depends on the size of a pointer.
>
This i know, that's why i said it was simplified. They're vauge
ill-defined memory blocks. Not that this refers to all aspects, but size
doesn't always matter. :)
> > Now, lets look at a character string like
> > s[5]="". What this does is define a space in memory.. it may look like
> > this;
>
> s[5]=""; is an assignment to a pointer, what it does is create a
> constant string which is empty (looks like this)...
>
> | '\0' |
>
> and sets a pointer (stored in s[5]) to the start of that string. This
> is, of course, assuming that you did this at the top of the function
> somewhere to create an array of character pointers...
>
> char *s[6];
>
> the following is a declaration that reservs 5 chars of memory space and
> sets it to the empty string...
>
> char s[5]="";
>
> The resulting memory would look like this...
>
> | '\0' | ? | ? | ? | ? |
>
Actually, meant to type char s[5]="" - was skipping around too
much. In which case,the declaration and definition on the same line do
allocate the memory, and yes, the memory would look like that above, as
you note. :)
Yah, that'd be more accurate, but declaring
> > Now, if we copy the word 'hello' into our s character array, we
> > get this:
> >
> You get a buffer overrun because you allocated space for 5 characters
> and "hello" actually uses 6 as follows...
>
> | 'h' | 'e' | 'l' | 'l' | 'o' | '\0' |
>
No. I didn't specifically declare I was copying strings - just 5
characters. The one thing I did was keep it as simple as possible.
> > The thing is, the variable 's' can be used just like the pointer
> > up above. It is a pointer after all.
>
> no, it's not. it can be used like a pointer in some ways, and in some
> ways it cannot. For example you cannot change the value of s to make it
> point to something else
Actually you can. It's just bad form. I know i've done it on a
few occasions when I didn't specifically declare my strings as constant.
Least, i'm pretty sure you can. You can make anything point to anything.
it sucks.
>
> > s[2] actually means take the
> > address of s and add 2 to it .. ie *s + 2.
>
> Close, try *(s + 2)
>
Bleh. that's what I meant. :(
> > Just be careful though, if you
> > pass that s[] variable to a function as a *s, you won't be able to use
> > your array subscripting to access it. s[] can be converted to *s, but not
> > the other way around.
> >
> It is perfectly valid to access a pointer as an array.
Not in all circumstances. Try accessing a multidimensional array
that you passed to a function as a single pointer in it's own context.
It's better to never do this.
>
> > Now, here's where we get to your question;
> >
> > how is
> >
> > char *to_vict = NULL, *to_room = NULL;
> > or
> > const char *to_vict = NULL, *to_room = NULL;
> >
> > any different from
> >
> > char to_victim[MAX_STRING_LENGTH] = "";
> > char to_char[MAX_STRING_LENGTH] = "";
> >
> > Well, there you have it. Since I happen to know that these
> > strings are already allocated (they're static actually which makes them
> > even more optimized), all we _need_ is a pointer to them. They don't
> > change (thus, const is justified - it means 'memory pointed to by this
> > pointer is not supposd to change via this pointer. compiler error if it
> > does'). If you allocate memory for them though, it will still work.
> > However, that pointer of 'to_victim[max_string_length]' which points to a
> > max_string_length size of allocated memory will be blown away - it will
> > quickly be set to point not to that memory, but the static string.
>
> Actually it won't even compile because the compiler won't let you change
> the location where it points to.
>
*sniff* I'm pretty sure i've overwritten static strings all the
time. Just not const static strings, at least not directly. Maybe it was
just that hp compiler. Stupid piece of crap. Hm. Well, I know i've done
it in assembler - but there, it was called 'optimization' :)
Maybe it was just indirect. I know I've fudged strings up in
every way possible. Maybe i'm just getting senile.
(note - apparently it wasn't hp's, it was NCR's not nearly ansi
compliant..well, maybe compliant for '85)
> > * - yes, i know, it grows the otherway maybe, there's seperate areas,
> > blahblahblah. It's simplified. Deal.
> >
> It's wrong. Deal.
But it's a learning tool. I got the important things that
required no thought even though I screwed up the semantics.
I can claim I get it right when I code myself, but now it takes
concerted thinking to figure it out. I probably should wait till I'm not
at work to write :(
PjD
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT