Re: Constructing Derived in shell of Base <shudder>
Joshua Maurice <joshuamaurice@gmail.com>, on 16/07/2010 11:26:10, wrote:
On Jul 16, 10:57 am, "Francesco S. Carta"<entul...@gmail.com> wrote:
Joshua Maurice<joshuamaur...@gmail.com>, on 16/07/2010 10:37:14, wrote:
On Jul 16, 10:26 am, "Francesco S. Carta"<entul...@gmail.com> wrote:
Joshua Maurice<joshuamaur...@gmail.com>, on 16/07/2010 10:16:20, wrote:
Still, am
I right to think it would be a perverse implementation which would
have complete objects exist in not-contiguous storage of
sizeof(the_type)?
Nobody can question you if you decide to consider such an implementation
as "perverse", that's perfectly among your prerogatives :-)
I don't understand all such bothering for something that the standard
allows to implementers (in order to give them additional implementation
freedom) and forbids to programmers (relying on a particular layout
which could be completely different in another implementation, thus
leading to undefined behavior if relied upon).
In other words: it is something completely out of the programmer's
concern by definition.
It's part of my concern when I use placement new. There I control the
storage and I put complete objects into that storage. I want to
understand the exact extent of the allowance to avoid making
portability mistakes. To know that, I have to understand what it's
trying to achieve and what exactly it allows and what exactly it does
not allow.
I still believe it's not our concern. We are assured that with placement
new, only sizeof(type) contiguous "chars" are needed/used.
Well, let me phrase the question like this. Is the following code
legal?
#include<new>
class foo
{
public:
virtual void bar() {}
};
int main()
{
foo * f = new foo;
foo * f2 = new (f) foo;
f2 -> bar();
}
I would never write code like this as a matter of style and sanity,
but I would still like to know as a matter of understanding all of the
standard and its nuances. Does that phrase disallow this? From James
Kanze's reply, that might not be the intent, nor how it's commonly
understood. At this point, I'll settle with one of:
1- Most / all of the standard writers and compiler writers don't know.
Don't assume the above code will work in a portable way.
2- Most / all of the standard writers and compiler writers believe the
standard guarantees that above example code is valid. You may rely on
it.
3- Most / all of the standard writers and compiler writers believe the
standard specifically guarantees that the above has 'undefined
behavior' or is otherwise unportable and "bad".
Given an answer to the above question is 1 or 3, I have an additional
question: What motivated this allowance?
I'm in the lower end of the range (the less important bits) when it
comes to fully understand the standard and its rationales, but I know a
thing for sure: one of the powers of C and C++ is to allow you doing a
lot of "unsafe" things without patrolling your actions.
That kind of things is not checked at runtime for performance
motivations and neither is checked at compile time because its analysis
would cost too much time (when such analysis is at all possible).
The above, for me, is a sufficient reply for all the cases where
something unsafe or UB is allowed by the standard (either implicitly or
explicitly).
Though, I don't know if it is enough for you, in such a case I'll step
aside and I'll leave space to better knowing people :-)
--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com