This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ -- a valid idea?


On Saturday, June 12, 2004, at 10:22  PM, Alexis Wilke wrote:
> > Now, the other day I thought of something which is (to my point of 
> > view) a
> > problem in C++.

On Thu, Jun 24, 2004 at 06:14:41AM -0700, Mike Stump wrote:
> Thinking of problems doesn't mean they are problems.  Please come up 
> with a test case, ensure that all methods and functions are defined, 
> and create two loops which you think should be equally as efficient, 
> one which uses the prefix ++ and the other which uses the postfix ++ 
> and then time them.  If you discover there is a problem, in the current 
> (snapshot) compiler, then let us know.  We can then examine the code 
> and the assembly produced and see if a bug report is reasonable.

It's certainly possible to write code where a class defines a postfix
operator++ that is not an inline function, and that does more work than
the prefix operator++, so that the user who then uses the postfix++ but
does not use the result will pay a penalty.

However, I don't think that this is a problem that the compiler must
solve.  Rather, it can be avoided by coding the overloaded operators
well.

For example, the coder might always use a scheme like the following:

class some_iterator {
public:
    // ...
    some_iterator& operator++();

    some_iterator operator++(int) {
	some_iterator tmp = *this;
	operator++();
	return tmp;
    }
};

The compiler is allowed to assume that the copy constructor only does
a copy, and to optimize away unneeded copy operations.  The result
in this case should be that, for some_iterator above, using the
postfix operator without using the result should give code equivalent
to using the prefix operator.

Now, for the currently released GCC, you'll find that the dead uses
of tmp are only completely optimized away if tmp has only one data
member that can fit in a register.  tree-ssa (now in the trunk) does
better, and you should find that this style comes very close to
eliminating any penalty from "incorrect" use of the postfix form.

Now, if someone writes a postfix operator and doesn't make it inline,
a penalty will be paid.  That's life.  If you don't like that, don't
write your code that way.

			   

	


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]