Internals of an object

I sat through - what should have been a 10 minute discussion where at
issue is the 'security of a class'. Truth is I was puzzled by the
soruce, so much so that I lost track of the end result. In any event,
consider

is to fiddle with the internals of the object which puzzled me since
I'm unsure of a 'rational' reason to do such a thing and why is 'that'
even allowed?

Pictorially, I'm not following the deferencing of the 'object' and the
subsequent result. I understand the basic premise behind deferencing
pointers to change the contents of an address, but from an "object'
perspective these puzzle me.

*minAgentAddr = -23;
*(minAgentAddr+1) = -37;

So I tried to step through the source but Visual Studio didn't do me a
whole lot of justice so I thought:
minAgentAddr 'calls' function setVal which in turn sets iVal but that
makes no sense since minAgentAddr + 1 calls what? I'm confused.

Advertisements

"ma740988" <> skrev i en meddelelse
news:...
> I sat through - what should have been a 10 minute discussion where at
> issue is the 'security of a class'.

Security in a class is not dealt with in C++ (it is not dealt with in any
other language that i know of, for that matter). The privacy of member
variables and functions is there simply to avoid shooting yourself in the
foot.

[snip]
>
> For starters, it appears to me that the impetus behind this
>
> int *minAgentAddr = reinterpret_cast<int*>(&minAgent);
>
> is to fiddle with the internals of the object which puzzled me since
> I'm unsure of a 'rational' reason to do such a thing and why is 'that'
> even allowed?

The purpose of reinterpret_cast is to tell the compiler that you know better
and should be used rarely if ever. One place where the is okay is where some
object somehow crosses a language barrier (e.g. call-backs in Windows).
Here, the reinterpret_cast is justified.

Non-portable (minAgent may have different alignment requirements
to int), and undefined behaviour if it is de-referenced, because
the class may have padding before the first object.

But in the majority of cases, Agent's memory location will
consist of two ints. So &minAgent will be the same address
as &minAgent.iVal , and &minAgent + 1 will be the same
address as &minAgent.jVal. To rely on this behaviour would
be foolish, of course.
> int *minAgentAddr = reinterpret_cast<int*>(&minAgent);
>
> I'm unsure of a 'rational' reason to do such a thing and why is 'that'
> even allowed?

Your question applies to reinterpret_cast in general; and the answer
is that, in some cases it is useful (especially, cases where you
have established by other means that nothing undefined is going
to happen). For example in this case, if you want to change
private data in someone else's object , and you know that on
your platform, iVal will always be at the start of the object.
> Pictorially, I'm not following the deferencing of the 'object' and the
> subsequent result. I understand the basic premise behind deferencing
> pointers to change the contents of an address, but from an "object'
> perspective these puzzle me.
>
> *minAgentAddr = -23;
> *(minAgentAddr+1) = -37;

This could be rewritten (recalling that minAgentAddr is an int *):
minAgentAddr[0] = -23;
minAgentAddr[1] = -37;

(Old Wolf) wrote in message news:<>...
[...]
>
> Non-portable (minAgent may have different alignment requirements
> to int), and undefined behaviour if it is de-referenced, because
> the class may have padding before the first object.
>
> But in the majority of cases, Agent's memory location will
> consist of two ints. So &minAgent will be the same address
> as &minAgent.iVal , and &minAgent + 1 will be the same
> address as &minAgent.jVal. To rely on this behaviour would
> be foolish, of course.
>
> > int *minAgentAddr = reinterpret_cast<int*>(&minAgent);
> >
> > I'm unsure of a 'rational' reason to do such a thing and why is 'that'
> > even allowed?
>
> Your question applies to reinterpret_cast in general; and the answer
> is that, in some cases it is useful (especially, cases where you
> have established by other means that nothing undefined is going
> to happen). For example in this case, if you want to change
> private data in someone else's object , and you know that on
> your platform, iVal will always be at the start of the object.
>
I suspect 'always be at the start of the object' means, when viewed
from the perspective of minAgentAddr the object has been more or less
'transformed' and as such iVal and jVal are now viewed as:

Old Wolf <> wrote:
> > int *minAgentAddr = reinterpret_cast<int*>(&minAgent);
> >
> > I'm unsure of a 'rational' reason to do such a thing and why is 'that'
> > even allowed?
> Your question applies to reinterpret_cast in general; and the answer
> is that, in some cases it is useful (especially, cases where you
> have established by other means that nothing undefined is going
> to happen). For example in this case, if you want to change
> private data in someone else's object , and you know that on
> your platform, iVal will always be at the start of the object.

I'd let me add something, as a long C++ practicer ))

The reinterpret_cast operator should be used ONLY and EXCLUSIVELY to cast
between char* (const char*, if another is also const) and the other type
(in both ways). The C++ standard does not exclude other uses of
reinterpret_cast, but this is the only use of reinterpret_cast, which works.
This operator is used ONLY to get access to the internal representation and
to allocate an object in memory, obtained by some "unusual" way.

One of the correct examples of use of reinterpret_cast is the definition of
std::string in gcc. This string is implemented in such a way that first there
is allocated all memory required to hold all characters of created string,
including reserved space and internal structure:

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!