aliases, ptr coercions, and optimizations

Thread View: comp.std.c++

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Jim ADCOCK Mon, 30 Jul 1990 19:50

#249

Author: Jim ADCOCK
Date: Mon, 30 Jul 1990 19:50

15 lines
1060 bytes

Request for Clarification and a General Proposal:

I claim there is a need for clarification in terms of what kinds of ptr
casts are legal in the face of an optimizing compiler.  For example, does:

	foo* fooptr = &(bar.fooMember);

poison fooMember, the labeled section fooMember is in, the class derivation
that fooMember is in, or all of bar?

My general proposal is that C++ be very restrictive in terms of what pointer
casts are "guaranteed" to work, allowing for maximum compiler optimizations,
while minimizing the pointer hacks that are "guaranteed" to work.  IE,
good C++ citizens should get well optimized code, but C++ hacker code may
not work at all.

Re: aliases, ptr coercions, and optimizations

#243

Author: Jonathan Shapiro
Date: Thu, 02 Aug 1990 18:15

13 lines
1035 bytes

In article <56170@microsoft.UUCP>, jimad@microsoft.UUCP (Jim ADCOCK) writes:

> My general proposal is that C++ be very restrictive in terms of what pointer
> casts are "guaranteed" to work, allowing for maximum compiler optimizations,
> while minimizing the pointer hacks that are "guaranteed" to work.  IE,
> good C++ citizens should get well optimized code, but C++ hacker code may
> not work at all.

This is not in the spirit of the language at all.  There is nothing to
prevent the optimizer from recognizing the non-optimizable cases and
simply not optimizing them.

Jon

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads