From: NOSPAMsl AT psycode DOT com (Gili)
Newsgroups: gnu.gcc.help,comp.os.os2.programmer.misc,comp.os.msdos.djgpp
Subject: Re: C++ constructor problem solved!! Read how, it might come in useful in your future programs!
Date: 20 Jan 1998 02:07:01 GMT
Organization: Generation.NET
Lines: 40
Message-ID: <bWLoegW7sFse-pn2-Y8HSrHrj4UXy@portA32.Generation.NET>
References: <bWLoegW7sFse-pn2-bxyqvlUyVUyY AT localhost> <34C2817A DOT 5547BE86 AT alcyone DOT com>
Reply-To: NOSPAMsl AT psycode DOT com
NNTP-Posting-Host: portA32.Generation.NET
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

On Sun, 18 Jan 1998 22:26:02, Erik Max Francis <max AT alcyone DOT com> 
wrote:

> Explicitly calling constructors is dangerous.  Here what's _really_
> happening is that the fstream is being constructed with the default
> constructor, and _then_ you're explicitly calling a nondefault
> constructor.  That is, it's functionally precisely the same thing as:
> 
>     File::File(...):
>         fstream()
>     {
>         ((fstream *) this)->fstream(...);
>         ...
>     }

	I found a second (and perhaps better) way of doing this. Now I use 
"this->fstream.fstream(<parameters>".

>     class File
>     {
>       public:
>         fstream *fs;
> 
>         File(...);
>         ...
>     };
> 
>     File::File(...)
>     {
>         fs = new fstream(...);
>         ...
>     }
> 

	This is unacceptable because I wanted to publicly inherite fstream().
I could use delegation like this but then I won't be inheriting the 
methods and variables of fstream().. Once again, I think 
"this->fstream.fstream()" is a good solution.

Gili