Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!rutgers!dptg!ulysses!andante!alice!ark
From: ark@alice.UUCP (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Some annoying questions [answered, I hope]
Keywords: const, scope, destructors I was reading the most recent C++ Report which discribes the differences
Message-ID: <9641@alice.UUCP>
Date: 19 Jul 89 19:04:13 GMT
References: <42941@bbn.COM>
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 150

In article <42941@bbn.COM>, news@bbn.COM (News system owner ID) writes:

> 1) The report says that the const qualifier is treated rather like a #define in
>     C++ in that a declaration
> 	const int i=3;
>     with external scope does not define an external variable in C++.  After
>     fiddling a little with my C++ translator here (Designer C++) I noticed
>     that this statement is true for ints, shorts, longs, chars, unsigneds,
>     etc. but not for doubles, floats, enums, pointers, classes, arrays.

There are two separate questions.  First, is `i' given external
linkage?  That is, if I say

	const int i = 3;

in one compilation and

	extern const int i;

in another compilation, do these two declarations refer to the same
entity?  The answer is `no' -- the default for const objects is
internal linkage so you would have to say

	extern const int i = 3;

to make the two `i's the same.

The second question is whether or not any memory is allocated for `i'.
The answer is `yes, but the compiler is allowed to dispense with
allocating memory if it sees it can do so safely.'  Doing so is just
an optimization, and it is carried out in just those circumstances
when it is invisible except for its effect on storage consumption.

>    Is this discrepency fixed in version 2? (and how on earth is the compiler
>     supposed to deal with a constant class initialized by an external
>     constructor?)
>    What is supposed to happen if one takes the address of what would be in
>     ANSI c an external constant integer? (or is that illegal)

For instance:

	const int i = 7;
	const int* ip = &i;

allocates memory for `i' because it needs an address to put in `ip.'

> 2) another question about constants, suppose I have a class
> 	class number {
> 	    /* ... */
> 	public:
> 	    number(int);
> 	    operator+(number&);
> 	    operator+=(number&);
> 	};
> 	const number zero(0);
> 
> 	foo() {
> 	    number x;
> 	    zero+x;
> 	    zero += x;
> 	}
>     Now since a `this' argument has type pointer to number it should not
>     accept a constant number.  However if we say this constant objects are
>     useless.  On the other hand if we say the type of this is pointer to
>     const number then we can't write a += operator.
>    How should C++ handle constant objects?

You're correct that operator+ and operator+= as you've written
them will not accept a constant number.  However, there are several
things you can do.  For example:

	class number {
	    /* ... */
	public:
	    number(int);
	    number operator+(const number&) const;
	    number& operator+=(const number&);
	};

I've made a few changes to your declarations here.  First, by
saying `const number&' instead of `number&' as the argument of
operator+, I've allowed the right-hand operand of operator+ to be
a const number or a non-const number (because you can bind a
const number& to a number object).  The `const' after the right
parenthesis says that operator+ doesn't modify the object on which
you're calling it, so it can be called for constant objects.
I also declared a return type for operator+.

I made similar changes to operator+=, but because it modifies its
object I didn't say `const' after the ).  Thus you can use + on
a constant object but not +=.

Incidentally, I think it's better to avoid using member functions
for symmetrical operations like + and do it this way instead:

	number operator+(const number&,const number&);

Make it a friend of the number class if needed.

>     Is
> 	foo() {
> 	    /* ... */
> 	    goto L1;
> 	    /* ... */
> 	    String x(10);
> 	    L1:
> 	}
>    also illegal (again the constructor for x does not get called)

Yes.

>     Assume there is a destructor for String, then is
> 	foo() {
> 	    /* ... */
> 	    {
> 		String x(10);
> 		goto L1;
> 	    }
> 	    L1:
> 	}
>    illegal?

No, that's fine.  Goto out of a block causes destructors to be
called for objects that were constructed in that block.  Same
for break and continue.

> 4) Consider
> 	for ( i=0 ; i<10; ++i )
> 	    String j(10);
>    To my understanding this is valid C++, what is the scope of j?

This is invalid in 2.0 for exactly that reason.

> 5) The report mentions that in version 2 classes define a local scope in that
>     enums declared inside the class are only available inside the class (and
>     its members).
>    Does this extend to classes defined inside another class?
>     (if not why not)

No, sorry.  That would introduce too large an incompatibility with
C and with previous versions of C++.  It would be nice, but...

> 6) I have noticed that in Designer C++ a constructor is always public, even
>     if it isdeclared in a private part of the class (and the same is true
>     of the destructor)?

It's a bug, fixed in 2.0.
-- 
				--Andrew Koenig
				  ark@europa.att.com