Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!munnari!otc!mikem
From: mikem@otc.UUCP
Newsgroups: comp.lang.c++
Subject: Re: Some Questions (2 & 3)
Message-ID: <85@otc.OZ>
Date: Sun, 8-Feb-87 22:43:59 EST
Article-I.D.: otc.85
Posted: Sun Feb  8 22:43:59 1987
Date-Received: Tue, 10-Feb-87 03:59:27 EST
References: <1207@hplabsc.UUCP>
Organization: O.T.C. Systems Development, Australia
Lines: 90

(I decided to post the answers instead of direct e-mail, since there are
 obviously lots of people going through similar learning curves, and the
 traffic on comp.lang.c++ has been a bit thin of late anyway...)

The second question was:

> Question 2:
> What are the semantics of a private constructor?  It seems to me that a
> private constructor should be invisible outside of members (and friends)
> of a class.  Yet the compiler (version 1.1) does not seem to enforce
> this.  Is this a bug in the compiler, or am I missing something?

Yes, a private constructor must mean that nothing except other
instances or friends can make one of the things. E.g:

	// privctor.c

	class Crap {
		int i;
		Crap(int ii) { i = ii; }

		friend void func();
	};

	void func()
	{
	    Crap c(1);	// ok, since func is friend of Crap
	}

	main()
	{
	    Crap c(1);  // not ok.
	}

   $ CC privctor.c
     CC  privctor.c:
     "privctor.c", line 18: error:  Crap::Crap() is private
     1 error
   $

If the compiler isn't enforcing this, there's probably a bug in the port.

The third question was:

> The following file compiles without error under version 1.1 on our
> machine.  It seems to me that it should complain about the arguments to
> the constructor since no constructor that accepts arguments has been
> declared.  Am I missing something or is this a bug in the compiler?
> 
> #include <stream.h>
> 
> class foo {
>        char c;
>        long l;
>        float f;
>    friend ostream& operator<<(ostream&, foo&);
> };
> 
> void bar()
> {
>    foo* p = new foo('a', 13, 99.9);
>    cerr << *p;
> }

This is a bug that occurs for me too. (There seem to be a few of them
around when something slightly out of the ordinary is asked of "new".)
The translator totally ignores the arguments, generating something
like:

int bar()
{
    struct foo *_auto_p;

    _auto_p = (struct foo*) _new((long)12);
}

Note that the generated code should still work in this case, which is probably
a fluke. cfront seems to be simply throwing everything it doesn't need away.

I've also had bugs emerge for invocations of new where an array of things
with constructors was asked for, but I don't have the example handy.

Hopefully, release 1.2 may be out soon. Maybe this is one of the bugs
that got fixed?

			Mike Mowbray
			Systems Development
			Overseas Telecommunications Commission (Australia)

UUCP:   {seismo,mcvax}!otc.oz!mikem              ACSnet: mikem@otc.oz