contradiction in TC++PL?

[Howard]

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!

I think the point here is that we're now talking about "implementation
defined" behavior. Since you're not (yet) dereferencing the pointer(s),
there's no "undefined behavior" going on. But it's certainly possible that
you could be compiling for a platform that implements addresses in adress
registers, isn't it? In that case, wouldn't it behoove (I love that word
) them to disallow somehow any assignment of an address which is not
valid?

Implementation defined behavior is simply where the Standard allows a
compiler to take the actions it needs to take under the given conditions,
rather than specify them explicitly. Assuming that this actually *is*
implementation-defined (I really don't know for sure, not having the
standard handy), it just means that you'd have to check your own compiler(s)
before attempting that kind of action. And I'm sure you'll agree that
explictly setting a pointer value to be anything other than NULL, or the
address of an existing object (or its member), is pretty senseless, eh?

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_cast<bool* const>(92729);

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

I have absolutely NO idea if it's actually done that way on any specific
platform, but there's likely to be far more platforms out there than I care
to list, let alone test on, dontcha think?

-Howard

 

[JKop]

for(ptr = array[0]; ptr != &array[SIZE]; ++ptr) { ..

Could you please elaborate on that? Here's my feeble attempt:

#include <cstddef>

int main()
{
std::size_t SIZE = 6;

int array[SIZE];

for(int* ptr = array[0]; ptr != &array[SIZE]; ++ptr)
{
//But we have a type mismatch just above
}

}

It's not "wasting memory", the trivial idea (not using 0 or 2**N - 1)
is just wasting a few bytes of address space.

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.


-JKop

 

[Ron Natalie]

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 "inaccessible" values.

 

[Ioannis Vranos]

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_cast<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]

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.