🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.os2.programmer.misc
Article #310

Re: C++ problem -- Over 30 people were unable to help me, can you?!

#310
From: Bjorn Fahller
Date: Sat, 17 Jan 1998 00:00
52 lines
3026 bytes
On Sat, 17 Jan 1998 00:51:46, NOSPAMsl@psycode.com (Gili) wrote:

> Hi,
> 
> 	I created a class called File() which inherites fstream() publically 
> (i.e. class File : public fstream)
> I'd like to call fstream()'s constructor whenever File()'s constructor
> is called. However, I have run into a major problem.
> I can call the constructor in this way:
> "
> File::File(const char* name, int mode, int prot):
> fstream(name, mode, prot)
> {
>   <body goes here>
> }
> "
> 
> 	However, I'd like to use exception-handling and that isn't possible 
> in the constructor initialization. What I'd like to do is to be able 
> to call the fstream() constructor from the body of File()'s 
> constructor. This would allow me to use exception-handling... However,
> simply calling fstream() in the body seems to make C++ think I'm 
> creating an fstream() variable instead of calling the constructor. 
> Also, when I try using ::fstream() to call the constructor, the call 
> *seems* to work but my file does not open correctly (which it does 
> when fstream() is called from the constructor initialization.) Does 
> anyone have any idea how this problem could be solved?

Yes. It all depends on what you actually want to do, though. Here are 
two possible solutions, pick the one that's most suitable for you:

1. Call the fstream constructor in the initialiser, just like you did 
in your example. In the body of the constructor, do error checking and
throw if necessary (if you throw here, the destructor of the 
underlying fstream will be executed, but I assume that's what you 
want.)

2. Don't call the fstream constructor in the initialiser (which means 
the default constructor is executed.) Then, in the constructor body, 
call fstream::open, with shatever parameters you want, and throw if 
the result is not satisfactory.

I'd opt for #1, since #2 does construct the fstream first (but it's 
not tied to any file) and then reinitialises it with the call to open.
#1 semantically means the same, but doesn't waste time doing things 
you throw away in the constructor body.

Mail me if you need more details. Post again if the question I 
answered wasn't the one you actually asked.
   _
/Bjorn.
Technical Details
Message-ID: <DlpnOhDvP3gv-pn2-zQX4fq1HhHLx@du36-2.ppp.algonet.se>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <bWLoegW7sFse-pn2-d679pGp6mnys@portD23.Generation

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 11318c,8dafc9e0bf3f0357
X-Google-Attributes: gid11318c,public
X-Google-Thread: 10891a,8dafc9e0bf3f0357
X-Google-Attributes: gid10891a,public
X-Google-Thread: 11307a,8dafc9e0bf3f0357
X-Google-Attributes: gid11307a,public
From: bjorn@algonet.se (Bjorn Fahller)
Subject: Re: C++ problem -- Over 30 people were unable to help me, can you?!
Date: 1998/01/17
Message-ID: <DlpnOhDvP3gv-pn2-zQX4fq1HhHLx@du36-2.ppp.algonet.se>
X-Deja-AN: 316844943
Content-Transfer-Encoding: 8bit
References: <bWLoegW7sFse-pn2-d679pGp6mnys@portD23.Generation
Content-Type: text/plain; charset="iso-8859-1"
Organization: Algonet/Tninet
Mime-Version: 1.0
Newsgroups: comp.os.os2.programmer.misc,gnu.gcc.help,comp.os.msdos.djgpp