http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #18 from Thomas W. Lynch <dimitrisdad at gmail dot com> 2012-05-04
21:16:18 UTC ---
This code compiles:
#include <cstddef>
#include <stdlib.h>
typedef unsigned int uint;
class C{ // just here to be faithful to the original code
int y;
};
class A{
public:
typedef A this_type;
void* operator new(size_t enfacia_size, uint count){
size_t total_size
= enfacia_size
+ sizeof(int) * count; // the 'tail'
;
this_type *new_pt = (this_type *)malloc(total_size);
new_pt->count = count;
return new_pt;
};
uint count;
};
class B : public C, public A{
public:
int i;
};
int main(){
B *b_pt = new(5) B;
uint j=0;
j++;
};
And this is the debugger output:
(gdb) r
Starting program try_offsets
Breakpoint 1, main () at try_offsets.cc:32
(gdb) n
(gdb) p &(b_pt->count)
$1 = (uint *) 0x804a00c
(gdb) x/10 b_pt
0x804a008: 5 0 0 0
0x804a018: 0 0 0 0
0x804a028: 0 135129
(gdb) p b_pt
$2 = (B *) 0x804a008
(gdb)
Compare this to the prior code and debugger output of the same form, and you
will notice that operator new, from a point of view of type, behaves
differently than other method. Though it was inherited, its understanding of
this_type has not changed, as it does in the case for other methods.
In the least, in a strongly typed system I would expect there to be a warning
about inheriting operator new when the type was not going to be updated as it
is for other opertors and methods, though I suspect it is a small matter for
the compiler to give it the right type info.
>From a language design point of view, I could see not having operator new
accept references to the object as it blurs the line between allocation and
intialization (operator new and construction). It such a constraint were made
it should not be by implied contract with the programming because it is such a
subtle issue, there should be an error IMHO. Though, I don't like seeing
non-orthogonal artificial constraints, there is no reason operator new
shouldn't see the correct static type. Let the programmer determine the
appropriate conceptual partitioning.
In any case, what we have now is neither of these. The compiler lets you do,
though it is easy check for, and then it generates code that doesn't work -
then when coming back to the compiler guys one engages in a very technical
discussion. Seems a small change would increase productivity and quality code
..
I see our comments crossed, let me look at what you just posted here now
