🚀 go-pugleaf

In article AD64B66E966816216@sleipner.nts.mh.se, lars.farm@nts.mh.se (Lars Farm) writes:
>
>... People rely on the fact that
>unused constants are optimized away. Unfortunately, it appears that some
>compiler writers do this only for the special case of integer types. I see
>no reason why this should be any different:
>
>  const float F = 1.234;     //should be preferable to "#define F 1.234"
>
>Isuggested that required behaviour was that these constants are not
>instantiated unless actually used, much like templates. Rather than leaving
>it as an optional optimization as it appears to be now. This should apply
>to any built in type. Thus invalidating stupid warnings about unused
>variables. If some compilers warn about this, and according to the thread
>in c.l.c++.moderated some do, then many users will have to revert to the
>#define style constants instead. Is that the intent of the language
>designers?

I tried to answer this once already. I'll try again.

There is a limit to what you can or should try to specify in the language
definition.

For one thing, warnings are not mentioned as such at all. A compiler can
warn about anything it likes. ("Warning: function A contains more than
25 lines of code." "Warning: function B contains fewer than 25 lines
of code.") Whether you think a particular warning is a good or a bad
idea, and whether you can or want to turn off all messages or just a
particular warning is up to you, the compiler vendor, and whoever
writes the programming standards in your shop. The language definition is
silent on this issue, and quite deliberately so.

For another thing, language requirements have to be testable for them to
make sense. If you try to make a requirement that certain constructs be
optimized away when they can be optimized away, how do you test for
compliance? Any test you make to see whether such a thing is present
must report that it is present, or the compiler violates the language rules.
The optimization can occur only if you don't try to find out whether it
occurred. (There are exceptions, but const objects are not one of the
exceptions).

Next, why single out this one particular optimization? Why not concentrate
on optimizations that have a significant impact on program performance,
like creation and destruction of extra temporaries. The effect of of an
extra floating-point object in the program is negligible compared to the
proliferation of temporary objects that are not actually required.

The whole area of optimization and unneeded code and data is deliberately
not part of the language definition. Those things are left as a "quality of
implementation" issue. Different programs and programmers have different
criteria for what is important, and IMHO C++ implementors should not be
prohibited from satisfying user requirements.

If you require a space optimization, it might make the code run slower. If
you require a time optimization, it might make the program larger. If you
require a set of optimizations that can only make the program both smaller
and faster, it might mean the compiler gets bigger and slower to the point
where it isn't useful. These are not just theoretical points. Some compilers
have captured a large market segment by compiling very quickly, even though
the resulting programs were not very efficient. Many users cared more
about the compile/test/rewrite cycle than a percentage difference in
program performance. Would you deny certification to a compiler that
generates correct code and performs acceptably for its customers even if it
does not make any optimizations? I don't insist that you buy this compiler;
I do insist that I be allowed to buy it.

I suppose I should also comment on the comparison with unneeded template
instantiations. That isn't an optimization issue, but a correctness issue.
Simple example:
	template< class T > class X {
		T t;
		...
		bool operator<( const T& rhs ) { return t < rhs.t; }
	};
Suppose we instantiate X on a type T for which the "<" operator is not
defined. That isn't a problem unless we invoke X<T>::operator<. So the
language rule is that a compiler can't reject a program due to an
invalid instantiation unless the instantiation is actually required. We
can test compiler compliance by instantiating X on various T's which
do and do not have a "<" operator and observe the results when we do
and do not try to use the "<" operator.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]