http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #33 from Thomas W. Lynch 2012-05-05
00:48:57 UTC ---
You say accessing type in operator new is illegal by the standard, but the
compiler doesn't give an error though doing so is bloody obvious and I have the
strick checking turned on-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Thomas W. Lynch changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #30 from Thomas W. Lynch 2012-05-04
23:36:48 UTC ---
Sorry to be thick headed Jon. Perhaps you could boil it down to the essentials
here, are you saying that assignment is illegal in operator new so it is proper
that there be no error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Thomas W. Lynch changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #28 from Thomas W. Lynch 2012-05-04
22:31:36 UTC ---
I see that example, I understand it, and I appreciate your writing it.
Though we are going a long way from the original "minor bug".
Had it not been operator new, but another op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Thomas W. Lynch changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #21 from Thomas W. Lynch 2012-05-04
21:40:46 UTC ---
So you are not going to say anything about the code in comment 11, which you
say shouldn't work, but does? Due to this, and fact you are now demeaning me,
I request a different set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #19 from Thomas W. Lynch 2012-05-04
21:27:18 UTC ---
Johnathan, const static members are compile time beasts. There are almost
macros like #define, but not quite as the compiler will give them storage if
you take their address. I do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #18 from Thomas W. Lynch 2012-05-04
21:16:18 UTC ---
This code compiles:
#include
#include
typedef unsigned int uint;
class C{ // just here to be faithful to the original code
int y;
};
class A{
public:
typedef A this_type;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Thomas W. Lynch changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #14 from Thomas W. Lynch 2012-05-04
20:18:02 UTC ---
I went through the life time issues in detail in prior comments. The C++ rules
for life time of an instance do not apply to those of the life time of a class.
Or are you saying thes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Thomas W. Lynch changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #11 from Thomas W. Lynch 2012-05-04
19:59:12 UTC ---
Jonathan, but there is "magical adjustment" as you put it, as the following
code works correctly:
#include
#include
typedef unsigned int uint;
class C{ // just here to be faithf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #9 from Thomas W. Lynch 2012-05-04
19:25:08 UTC ---
I went to take 'this_type' out of the source. You were correct to focus on
that.
As malloc() returns a void * there must be a cast to access the fields in the
instance. We routine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #8 from Thomas W. Lynch 2012-05-04
18:57:40 UTC ---
>No, that's not how it works. If Base::increment() writes to Base::field then it
>is always at the same offset into the Base object. Whether that Base object is
>a sub-object of anot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #6 from Thomas W. Lynch 2012-05-04
18:12:10 UTC ---
>> Part of the type information is the layout inside the class. The operator,
>> which has been copied into the child via inheritance,
>
>No, inheritance doesn't mean anything is co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #3 from Thomas W. Lynch 2012-05-04
05:20:46 UTC ---
> I don't think this is valid as the memory which is done after the operator new
is considered as unitialized.
The code does not use any uninitialized memory. It does not read the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Thomas W. Lynch changed:
What|Removed |Added
URL||http://stackoverflow.com/qu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Bug #: 53225
Summary: static operator new in multiple inheritance carries
incorrect type information for the class
Classification: Unclassified
Product: gcc
Version: 4.6.1
19 matches
Mail list logo
