🚀 go-pugleaf

In article AD5A0C5196681CA0D@sleipner.nts.mh.se, lars.farm@nts.mh.se (Lars Farm) writes:
>This is a reply to a thread in c.l.c++.moderated. The moderator asked me to
>post this in com.std.c++ instead. The thread started with someone
>complaining about a warning for an unused variable where he had const float
>x = y; in a header.
>
>Experts explained that this is as it should be for const float, but not for
>const int (I know that the std does not talk about warnings). The point is:
>The experts seems to find some kind of conceptual difference between named
>constant floats and named constant ints, such that declaring const int K =
>L; in a header is considered good practice but const float X = Y; in a
>header is not and justifies a warning. I don't think there should be any
>such difference.

I was one of the people who posted articles on that thread, and I
certainly never said there was or should be any conceptual difference.
I did say the compiler is allowed to treat them differently.

AS AN OPTIMIZATION, a non-extern const does not always need to be
instantiated.  No compiler is required to make that optimization, to
document whether it makes that optimization, or even to be consistent
about such optimizations.  That is the whole point of optimizations:
no portable and standard-conforming program can tell the difference.
You have to resort to things like examining the executable image, or
performing a timing analysis, or some other technique outside the
language definition.

Why do I say this is an optimization? The standard doesn't (and
shouldn't, in my view) say explicitly that it is sometimes ok to omit
the instantiation.  Instead, it says what the results of certain
operations must be. It turns out that no valid program can detect
that a const was omitted. Any valid test the program makes will report
that the constant was instantiated.  The compiler can choose to omit
the instantiation only if you don't try to find out that it did.
(Shroedinger, anyone?)

If you are unhappy about your compiler generating unncessary code or
data, or warning about things which you think are the compiler's own
fault, you should take that up with the vendor. In this particular
case, no language rule is being violated.

---
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
]

Lars Farm wrote:
> 
> Experts explained that this is as it should be for const float, but not for
> const int (I know that the std does not talk about warnings). The point is:
> The experts seems to find some kind of conceptual difference between named
> constant floats and named constant ints, such that declaring const int K =
> L; in a header is considered good practice but const float X = Y; in a
> header is not and justifies a warning. I don't think there should be any
> such difference.

I think that there may be some misunderstanding about what a const data 
member actually represents.  In general, a const defined at file scope can be 
of any type.  In C++, it is generally preferable to use const instead of 
#define.

	const int maxSize = 100;   //preferable to "#define maxSize 100"

Now consider const data members of a class.  First let's distinguish between 
const data members and static const data members.  Const (non-static) data 
members are certainly allowed in a class, but they are const relative to an 
individual object.  Each object can have a different value for the const data 
member.  Consider the following:

	class X
	  {
	    public:
	        X(int);
	        ...   // other members

	    private:
	        const int m_n;
	        ...   // other members
	  };

We could define the constructor as follows:

	X::X(int n)
	  : m_n(n)
	  {
	    ...   // other statements
	  }

Thus declarations such as 

	X x1(5), x2(8);

would create two separate objects of class X, each having different values
of the const data member.  The data member is const after construction of the 
object.

Now let's address data members which are const and static.  Such a data 
member would be have the same const value for all objects of the class.  
Consider the following:

	class X
	  {
	    public:
	        X();
	        ...   // other members

	    private:
	        static const int m_n;
	        ...   // other members
	  };

The static const data member can be defined and initialized once outside the 
class definition, usually in a separate source code file (rather than the 
header file).

	const X::m_n = 3;

Now all objects of the class see the same value (3) for the static const data 
member.

All of the above discussion applies to the C++ described in Stroustrup's 
1991 book as well as to the current draft standard.  What has changed with 
the standard is the ability to actually define and initialize the static 
const data member within the class definition.

	class X
	  {
	    public:
	        X();
	        ...   // other members

	    private:
	        static const int m_n = 3;
	        ...   // other members
	  };

Before this modification, one had to use enums within the class definition

	class X
	  {
	    public:
	        X();
	        ...   // other members

	    private:
	        enum { int m_n = 3 };
	        ...   // other members
	  };

or else one had to use a constant declared at file scope

	const int m_n = 3;

	class X
	  {
	    public:
	        X();
	        ...   // other members

	    private:
	        ...   // other members
	  };

The restriction placed in the standard is that the ability to define and 
initialize the static const data member within the class definition is 
restricted to integral types.  You can't do it, for example, with doubles or 
user-defined types.  As for the reasoning behind this restriction, you'll 
have to ask someone on the standardization committee, but I suspect that it 
has something to do with efficiency.  By the way, you should know that 
Stroustrup opposed this modification even for integral types since it could 
be accomplished within the existing language by the use of enums as 
illustrated above.

-- 
John I. Moore, Jr.      phone:  (301) 924-0680
SoftMoore Consulting    email:  70672.1744@compuserve.com
16233 Monty Court
Rockville, MD  20853-1344
---
[ 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 
]

In article <31379F8F.7659@compuserve.com>,
"John I. Moore, Jr." <70672.1744@compuserve.com> wrote:

>I think that there may be some misunderstanding about what a const data 
>member actually represents.  

No. I'm not talking about member constants.

>In general, a const defined at file scope can be 
>of any type.  In C++, it is generally preferable to use const instead of 
>#define.
>
> const int maxSize = 100;   //preferable to "#define maxSize 100"

Yes and I think this is standard practice. 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?


--
Lars Farm, lars.farm@nts.mh.se


[ 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
]

In <AD64B66E966816216@sleipner.nts.mh.se>, lars.farm@nts.mh.se (Lars Farm)
writes:

>I suggested 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?

One area where such a requirement conflicts with existing rules would
be if the constant object has a constructor.  Then the existing rules
would not allow the constant to be omitted since the constructor must
be called (especially if it has detectable side effects) even if the
constant is not used in the particular compilation unit.

John Yeager
yeager@aosi.com
---
[ To submit articles: try just posting with your news-reader.
                      If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu.
]

Lars Farm (lars.farm@nts.mh.se) wrote:
: 
: Experts explained that this is as it should be for const float, but not for
: const int (I know that the std does not talk about warnings). The point is:
: The experts seems to find some kind of conceptual difference between named
: constant floats and named constant ints, such that declaring const int K =
: L; in a header is considered good practice but const float X = Y; in a
: header is not and justifies a warning. I don't think there should be any
: such difference.

In fact, there is no such difference, as I understand it, in the way the
standard treats float and int in this regard.

Unused-variable warnings (a quality-of-implementation matter) are often
less than helpful, e.g., I get such a warning every time I acquire mutual
exclusion by creating an object whose constructor acquires the lock and
whose destructor releases it, since the object is not accessed elsewhere.

Tom Payne (thp@cs.ucr.edu)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]