Re: [Alephmodular-devel] Random rumblings on files and errors

[Michael A. <mdm...@ya...>]

--- Br'fin <br...@ma...> wrote:
> 
> On Thursday, January 30, 2003, at 06:56  AM, Michael
> Adams wrote:
> 
> > --- Br'fin <br...@ma...> wrote:
> >> By calling conventions I was thinking of calls
> like
> >> this:
> >>
> >> 	virtual bool get_named_child(const char *name,
> >> IFileSystemDesc*
> >> &out_desc) const = 0;
> >>
> >
> > I thought you had mentioned useing STL strings
> instead
> > of char* in future code, but maybe I'm remembering
> > wrong.  Also did you really mean IFileSystemDesc*
> > &out_sesc?  That * with the & confuses me.  Oh I
> think
> > I get it now.  So you would call it like this:
> >
> > IFileSystemDesc *f = NULL;
> > a->get_named_child("name", f);
> > And the pointer f would now point to something
> new?
> 
> Yes, that was my idea when writing it out that way.
> 
> > I haven't been paying much attention to this whole
> > discussion, but why not do this?
> >
> > ... get_named_child(..., IFileSystemDesc
> &out_desc);
> > ...
> > IFileSystemDesc  f;
> > a->get_named_child("x", f);
> >
> > It would make one less pointer floating around
> which
> > reduces chance of seg faults, but like I said I
> > haven't been paying close enough attention so
> maybe
> > there is some reason for using a pointer that I'm
> > missing.
> >
> The biggest problem with that is this is C++. So
> IFileSystemDesc is an 
> interface. An Abstract Base Class.
> 
> 'IFileSystemDesc f;' would result in a compile time
> error (Trying to 
> instantiate an incomplete class) But even if it were
> a full class, it 
> would be set in its ways. You can't really cram a
> larger subclass into 
> IFileSystemDesc as it was allocated purely and
> directly as a 
> IFileSystemDesc.
> 
> -Jeremy Parsons
> 

Yeah, your right.  I forgot about that for a moment.

Michael D. Adams

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com