Re: [Somelib] _S_IFDIR is not defined

[Thomas M. <tma...@ze...>]

John Palmieri wrote:

> Thomas Matelich wrote:
>
> > John Palmieri wrote:
> >
> > > >
> > > >
> > > > If one is using kdevelop to create the shared libraries, it uses libtool which
> > > > automatically uses the versioning scheme I mentioned.  Therefore, I think it is
> > > > very important to only find the files with the correct extension.
> > > >
> > >
> > > Well, I think that this is application specific and not SOMELib specific.  Say
> > > I wanted to end all my libraries with the extention .plug so that it can be
> > > associated with a mime type?  In the current scheme I could do this but if you
> > > enforce library extentions then this is not possible.
> >
> > Ok.  I think changing extension doesn't work on Win and HP, but it is a valid point.
>
> I've seen plugin systems under windows that change the dll extention.  Try it out and
> see what you get.
>
> >
> >
> > > I did a test by creating a
> > > soft link to one of the libraries in complexmenu.  It does load the lib 2 times.
> > > I belive that to avoid this we should be checking if a library is already loaded
> > > (Which I thought it did) and to not load it twice.  Perhaps we should give
> > > libraries UID's.
> >
> > It only checks to see if the same path is loaded twice.  Aren't there functions for
> > tracking down the "real" path to a file or dir?  I'll look into that.  I suppose I
> > should add the check for the same name and version of a library.  Should we allow
> > multiple versions loaded?  Probably.
> >
>
> Yes.
>
> >
> > > I think that once wildcard (regular expression) matches and text
> > > file loading are implemented a developer will have the option of restricting what
> > > extentions are loaded.  Perhaps you would feel better if we restricted directory
> > > loading so that you would have to supply a wildcard?  i.e. To load a entire
> > > directory you would have to use Path p = "plugins/*" and not just Path p =
> > > "plugins/"?  That way a developer would have to deliberatly say I want all files
> > > in this directory no matter what.
> >
> > That would make me feel better, but i don't know if I would enjoy using that
> > interface.  Hmm, tough decision.
> >
>
> I'll change it then when I implement regex.

I know you don't want outside dependencies, but boost now includes regex++, in case you
don't want to write it yourself.

> >
> > > On a side note, have you gotten the assignment operator to work?  It is a lot
> > > nicer to say Path p="plugins/" instead of Path p; p.set("plugins/");  I don't know
> > > why it was not working for me.
> >
> > Assignment operators are not inherited.  So I guess the first question is what the
> > purpose of the XPPath base class is (I'm guessing this relates to the regex stuff).
> > If it is needed, those functions will need to be added to Path, otherwise, let's drop
> > the heirarchy.
> >
>
> Realy, that is wierd because I inherited string in one of my programs and assignment
> still works.

If the inherited class had a constructor inh_string(string), then the default assignment
operator would have been invoked for inh_string because a constructor becomes an implicit
converison operator.  Since Path doesn't have Path(string), it is failing.

>  XPPath is needed so we don't have to duplicate the regex code(and other
> generic code) everytime we change it, unless the changes you made to Path render it
> platform independent.  The other idea is to change XPPath to Path and Path to PathDriver
> and have the new Path encapsulate PathDriver for the platform specific code.
> Composition over inheritance.

Yes, I like this much better.  I'll let you handle that.

>
>
> When do you think we could put out another tar ball?  Version .4a is a bit dated now and
> the new code is quite usable.  Perhaps after Path has frozen and regex is in?
>

That sounds like a good time to do it.

>
> --Quinticent
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...