contradiction in TC++PL?

[ES Kim]

Here's a code fragment from TC++PL Special Edition, p291:

void f1(T a)
{
T v[200];
T* p = &v[0];
p--; // please note (my comment)
*p = a; // oops: 'p' out of range, uncaught
++p;
*p = a; // ok
}

And here's an excerpt from p92:

"The result of taking the address of the element before the initial element
is undefined and should be avoided."

The author says, as I understand, it's ok with ++p after p--, which I think
contradict the statement in the excerpt. What do you think?

--
ES Kim

[Ron Natalie]

JKop wrote:

std::size_t SIZE = 6;

int array[SIZE];

for(int* ptr = array[0]; ptr != &array[SIZE]; ++ptr)
The init clause should be int *ptr = array; or int* ptr = &array[0];
My fat fingers (and outlook makes a lousy syntax checker).

By the way, the array size needs to be a constant experssion above.

Let's say we've 64MB of RAM. 63MB of RAM are being used. We want to create
an object of a structure, where sizeof(MyStruct ) == .75MB

Not enough memory.

It's got nothing to do with RAM. It has to do with address space.
Go read a book on computers. There doesn't need to be any memory
(virtual or otherwise) backing up the "inaccessib le" values.

[Ioannis Vranos]

JKop wrote:

What the hell ever happened to the whole concept of POD?

Plain Ol' Data

PLAIN OL' DATA!
When I have the likes of:
struct Blah
{
int a;
double b;
int* p_k;

float** p_p_f;
};
I should be able to set it to whatever the hell I please!
PODs aren't types of the 60s era, but of the C90 era.
Checking a pointer to see if it has a valid value (and perhaps throwing an
exception if not) is complete and utter total bullshit. It's inefficient
too. If I wanted such a mechanism, I'd explicitly ask for it:

int* k = ...

CheckPointer(k) ;
I'd like some clarity on the issue. Will the following behave identically on
all implementations , ie. will it output "I'm not a shit implementation! " on
all platforms?:
int main()
{
bool* p_boolean = reinterpret_cas t<bool* const>(92729);

std::cout << "I'm not a **pepper** implementation! ";
}

The above never causes side effects. Assignment of an integer to a
pointer type results in implementation defined behaviour, as far as you
do not dereference it.
"1.3.5 implementation-defined behavior

behavior, for a well-formed program construct and correct data, that
depends on the implementation and that each implementation shall document."

This means that you will never get unexpected effects for that.

On the other hand, pointing with a pointer to an invalid object (usually
with pointer arithmetic), results in undefined behaviour.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

JKop wrote:

What's the logic behind being able to have a pointer to one past the end of
an array?

Algorithms. One reason is in loops using a pointer or iterator with p++
incrementing, which at the end of the sequence points one past the last
element, and thus it has to be guaranteed that it is safe to do so.

--
Ioannis Vranos

http://www23.brinkster.com/noicys