somelib-devel — Public mailing list for design discussion and bug reports

Re: [Somelib] Errors with downcasting using SOME::Object

[John P. (Quinticent) <jo...@ma...>]

Linux/gcc -

Hierarchy:

              mriIAsset
                   /    \
                 /        \
mriIVisualAsset   mriIAudioAsset    (There will be more in the future)

I think the whole problem is that SOMELib uses some sort of smart pointers
that I haven't looked into.  Tom is using them in SOME::Object.

SOME::Object<T> expands to class SOME::Object : public boost_smart_ptr<T>

I haven't looked at the boost stuff and I am not sure if boost_smart_ptr isA
T or hasA T.  If it is hasA this will have to change.  If it cannot be
downcast then it needs to be taken out of SOMELib as I am not sure what
benefits it gives.

-Quinticent

"Frank V. Castellucci" wrote:

> What is the hierarchy? You may need dynamic_cast<> based on the rules of
> usage in 1998(E) C++ standard.
> What is the error, and what is the compiler/platform?
>
> John Palmieri wrote:
> >
> > I am trying to integrate SOMELib into snaglepuss and am having errors
> > with downcasting my objects.
> >
> > You see I have a hiarchy of interfaces for use with dynamicly loadable
> > assets (png, mp3, mpg files).  They all get loaded and stuffed into
> > chests which are just glorified vectors of type mriIAsset *.  Now each
> > of the assets can be rendered to the screen, audio device, etc. with a
> > call to the render() method.  But, each type of asset also has enhanced
> > functionality based on their type so my png loader asset would also
> > inherit the interface mriIVisualAsset which would in turn inherit the
> > mriIAsset interface.  The problem I am having is that when I load my
> > object I check to see if it is visual, audio.  Let's say it is a visual
> > asset.  I then use this code to construct the object:
> >
> > SOME::Object<mriIVisualAsset>oAsset(assets[0]);
> > //construct our asset
> > if(!oAsset.construct()){ ...
> >
> > this works fine but now I want to add this asset to my chest:
> >
> > asset = static_cast<mriIAsset *>(oAsset);  //error here.  I'm guessting
> > the template is not truly inheriting
> >
> > chest->addAsset( chestpos, asset );//I should be able to mix and match
> > different assests in my chest
> >
> > This is an important feature and as much as I know you love the boost
> > stuff if it restricts projects from using standard C++ mechanisms when
> > working with SOMELib it will have to go.
> >
> > -Quinticent
> >
> > _______________________________________________
> > somelib-devel mailing list
> > som...@li...
> > http://lists.sourceforge.net/mailman/listinfo/somelib-devel
>
> --
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
> http://PythPat.sourceforge.net
> Pythons Pattern Package
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

Re: [Somelib] Errors with downcasting using SOME::Object

[Frank V. C. <fr...@co...>]

What is the hierarchy? You may need dynamic_cast<> based on the rules of
usage in 1998(E) C++ standard.
What is the error, and what is the compiler/platform?

John Palmieri wrote:
> 
> I am trying to integrate SOMELib into snaglepuss and am having errors
> with downcasting my objects.
> 
> You see I have a hiarchy of interfaces for use with dynamicly loadable
> assets (png, mp3, mpg files).  They all get loaded and stuffed into
> chests which are just glorified vectors of type mriIAsset *.  Now each
> of the assets can be rendered to the screen, audio device, etc. with a
> call to the render() method.  But, each type of asset also has enhanced
> functionality based on their type so my png loader asset would also
> inherit the interface mriIVisualAsset which would in turn inherit the
> mriIAsset interface.  The problem I am having is that when I load my
> object I check to see if it is visual, audio.  Let's say it is a visual
> asset.  I then use this code to construct the object:
> 
> SOME::Object<mriIVisualAsset>oAsset(assets[0]);
> //construct our asset
> if(!oAsset.construct()){ ...
> 
> this works fine but now I want to add this asset to my chest:
> 
> asset = static_cast<mriIAsset *>(oAsset);  //error here.  I'm guessting
> the template is not truly inheriting
> 
> chest->addAsset( chestpos, asset );//I should be able to mix and match
> different assests in my chest
> 
> This is an important feature and as much as I know you love the boost
> stuff if it restricts projects from using standard C++ mechanisms when
> working with SOMELib it will have to go.
> 
> -Quinticent
> 
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

[Somelib] Errors with downcasting using SOME::Object

[John P. <jo...@ma...>]

I am trying to integrate SOMELib into snaglepuss and am having errors
with downcasting my objects.

You see I have a hiarchy of interfaces for use with dynamicly loadable
assets (png, mp3, mpg files).  They all get loaded and stuffed into
chests which are just glorified vectors of type mriIAsset *.  Now each
of the assets can be rendered to the screen, audio device, etc. with a
call to the render() method.  But, each type of asset also has enhanced
functionality based on their type so my png loader asset would also
inherit the interface mriIVisualAsset which would in turn inherit the
mriIAsset interface.  The problem I am having is that when I load my
object I check to see if it is visual, audio.  Let's say it is a visual
asset.  I then use this code to construct the object:

SOME::Object<mriIVisualAsset>oAsset(assets[0]);
//construct our asset
if(!oAsset.construct()){ ...

this works fine but now I want to add this asset to my chest:

asset = static_cast<mriIAsset *>(oAsset);  //error here.  I'm guessting
the template is not truly inheriting

chest->addAsset( chestpos, asset );//I should be able to mix and match
different assests in my chest

This is an important feature and as much as I know you love the boost
stuff if it restricts projects from using standard C++ mechanisms when
working with SOMELib it will have to go.

-Quinticent

[Somelib] Interfaces have changed and new functionality added

[John P. <jo...@ma...>]

Ok time to get the latest CVS build, reinstall those libraries and
update your code.  Iterfaces have changed once again because of needed
functionality and better (at least I hope better) method names (for
example getFromKeyValue has been changed to enumCategory).  Changes are
illistrated in the latest example, complexmenu, which needs simplemenu
to compile.  Complexmenu builds on the categoration tecniques of
simplemenu but uses the new map based category filiters for finite
control over what classes are returned.  Perhaps later on in development
we can add boolean expression based filters.  For example
getCategory("category='hello' &  author!='John'");

hmmm... perhaps getCategory should be changed to queryCategory?

Well I think we should package things up, make a post and ask for
testers and input for the pre-beta of 1.0.   What do you think?

-Quinticent

Re: [Somelib] Makefile update - linux build now broken

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

John Palmieri wrote:

> Fixed the build by defining BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION for
> linux builds.  This has to be added for all compilers that do not support
> this functionality and should be documented in the FAQ for supporting of
> new platforms.

Where did you add this and on what platform was it necessary?

>  I'm going to move from just platform builds to
> platform_compiler builds since you can compile with different compilers on
> different systems.

The examples need a -I(configure's included directory) for when you choose
and alternate prefix.  Probably a -L too.



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

Re: [Somelib] Makefile update - linux build now broken

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

John Palmieri wrote:

> I couldn't test out the new build system since the current build is
> broken.

Here are the results from running configure on my HP system:

creating cache ./config.cache
checking host system type... hppa1.1-hp-hpux10.20
host_os = hpux10.20
./configure[577]: echo^[:  not found.
checking for c++... c++
checking whether the C++ compiler (c++   ) works... yes
checking whether the C++ compiler (c++   ) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking whether c++ accepts -g... yes
checking for a BSD compatible install... /opt/imake/bin/install -c
updating cache ./config.cache
creating ./config.status
creating config/config.mk
creating config/config.h


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

Re: [Somelib] Makefile update - linux build now broken

[John P. <jo...@ma...>]

Fixed the build by defining BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION for
linux builds.  This has to be added for all compilers that do not support
this functionality and should be documented in the FAQ for supporting of
new platforms.  I'm going to move from just platform builds to
platform_compiler builds since you can compile with different compilers on
different systems.  Oh, Microsoft C++ has command line tools that can be
configured with ./configure and used in the makefiles.  I'll install
VC++ in the future and work on making the Makefiles platform
independent (all info needed to compile is gathered with ./configure).

-Quinticent

John Palmieri wrote:

> I update the buldsystem to use recursive makes since I was trying to
> compile on a BSD and it didn't like some of the newer make symbols I was
> using. I also updated the install script in the main Makefile to install
> to <prefix>/include/SOMELib and <prefix>/lib/SOMELib.
>
> I couldn't test out the new build system since the current build is
> broken.  I get errors with some of the template functions in the boost
> headers:
>
> in file included from BasicDynLib.h:24,
>                  from BasicDynLib.cpp:22:
> ../boost_includes/boost_smart_ptr.hpp:353: parse error before `::'
> ../boost_includes/boost_smart_ptr.hpp:357: parse error before `::'
> ../boost_includes/boost_smart_ptr.hpp:358: redefinition of `template
> <class T> void swap(...)'
> ../boost_includes/boost_smart_ptr.hpp:354: `template <class T> void
> swap(...)' previously declared here
> ../boost_includes/boost_smart_ptr.hpp:358: redefinition of `void
> swap(...)'
> ../boost_includes/boost_smart_ptr.hpp:354: `void swap(...)' previously
> defined here
> ../boost_includes/boost_smart_ptr.hpp:367: parse error before `::'
> ../boost_includes/boost_smart_ptr.hpp:376: parse error before `::'
>
> As for getting ithe build working on HP I say we first concentrate on
> documentation for Windows and Linux and get out the beta.  We can then
> go and identify the platform dependent portions of SOMELib and write up
> specifications for adding new platforms to the build. ie.  What source
> files do I have to change for dynamic loading features? How do I add the
> new platform to configure.in for automatic configuration of my
> build? How do I edit the Makefiles? What documentaiton do I have to
> write up so that others will know how to use the lib on my platform?
> etc.
>
> -Quinticent
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

[Somelib] Makefile update - linux build now broken

[John P. <jo...@ma...>]

I update the buldsystem to use recursive makes since I was trying to
compile on a BSD and it didn't like some of the newer make symbols I was
using. I also updated the install script in the main Makefile to install
to <prefix>/include/SOMELib and <prefix>/lib/SOMELib.

I couldn't test out the new build system since the current build is
broken.  I get errors with some of the template functions in the boost
headers:

in file included from BasicDynLib.h:24,
                 from BasicDynLib.cpp:22:
../boost_includes/boost_smart_ptr.hpp:353: parse error before `::'
../boost_includes/boost_smart_ptr.hpp:357: parse error before `::'
../boost_includes/boost_smart_ptr.hpp:358: redefinition of `template
<class T> void swap(...)'
../boost_includes/boost_smart_ptr.hpp:354: `template <class T> void
swap(...)' previously declared here
../boost_includes/boost_smart_ptr.hpp:358: redefinition of `void
swap(...)'
../boost_includes/boost_smart_ptr.hpp:354: `void swap(...)' previously
defined here
../boost_includes/boost_smart_ptr.hpp:367: parse error before `::'
../boost_includes/boost_smart_ptr.hpp:376: parse error before `::'


As for getting ithe build working on HP I say we first concentrate on
documentation for Windows and Linux and get out the beta.  We can then
go and identify the platform dependent portions of SOMELib and write up
specifications for adding new platforms to the build. ie.  What source
files do I have to change for dynamic loading features? How do I add the
new platform to configure.in for automatic configuration of my
build? How do I edit the Makefiles? What documentaiton do I have to
write up so that others will know how to use the lib on my platform?
etc.

-Quinticent

Re: [Somelib] More changes

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

To start with, I have put everything into namespaces.  There is a mapping of
classnames required.
SOMEObj -> SOME::Object
SOMELibInfo -> SOME::LibCatalog
SOMEClassInfo -> SOME::ClassCatalog  could be changed back to ClassInfo
SOMELibFactory -> SOME::LibFactory
BasicDynLib -> SOME::BasicDynLib
getSOMELibFactory() -> SOME::getLibFactory()

member function names have been changed to reflect these changes.

I had obfuscated the keys for classname and category, but then simplemenu doesn't
work because you search for categories loaded.  A method to add extra keys on the
plugin side needs to be added.  How about addClassCatalog returns a reference to the
ClassCatalog?

"John Palmieri (Quinticent)" wrote:

> The solution is to kill windows ;-) Ok, yes add a constrctor that takes a map.
> Document this workaround in doxigen.

you got it.

> configure --prefix=<base install dir> (default is /usr but the libs get sent to
> <prefix>/lib/SOME and headers to <prefix>/include/SOME)

good

> I could make it more configurable.
>
> As for the test, I guessed at what the name for hpux would be.  I will change the
> configure script to print out the current host os.  You send me the output and I
> will change it.
>
> What are the directories for libs and includes on HPUX?

when it searches for the platform it is hppa1.1-hp-hpux10.20.  I'm not sure which
other hpux platforms match.  I guess we'll get to that when someone asks.  Which libs
and includes do you mean?

> > > > 3) Name analysis.  Are these the names we want for our classes
> > >
> > > Yes.  I think we need to run this through beta testers and develop a
> > > vocabulary (Perhaps the Info stuff should be called a catalog and
> > > getCategory should be overloaded to handle both the simple catagory and
> > > multipule category gets).  Also intern names we use for the maps should be
> > > obfusicated so as to avoid name clashes with someone perhaps using
> > > "category" as one of their categories.
> > >
> >
> > ClassProperties and LibCatalog?  I'll change the classname and category keys
> > to something peculiar.
> >
>
> Not ClassProperties this implies encapsulated class variables (eg properties)-
> ClassInfo is fine.  I like LibCatalog though.  getCatagory should take arguments:
>
> getCatagory( string simpleCatagory );
> getCatagory( string key, string value );
> getCatagory( SOME::map keyvalueMap );

>
> setCatagory for the ClassInfo should take:
> setCatagory( string simpleCatagory );
> setCatagory( string key, string value);

look through my names, tell me what you think.

> > > > 6) Write the searchForLib func.
> > >
> > > Yes.
> >
> > Actually, I have no idea what I intended searchForLib to do.  What does it
> > sound like to you?
> >
>
> findLib is more compact.
>
> Search for a library and return its LibCatalog.  Should we extend LibCatalog to
> have the same catagory functionality as ClassInfo?

how should we specify the searchpath?

> Hmm...well it is their fault but I see how this could be a problem.  Since we can
> only load libs that are compiled for somelib there is no real problem with someone
> trying to loadLib( "/usr/lib" ).  Anytime a library is found not to contain the
> correct exported functions it should be beaten to death with a stick and then
> unloaded from memory (and the programmer/user properly chastised for sloppy
> selection of directories).  Remeber also that each loaded lib should only load
> into memory the exported function (lazy loading) and memory usage should not go up
> until an object is actualy created.  To allow the programmer to finietly control
> memory usage we should provide methods for unloading specific libs and checking
> the size a library is currently taking up in memory.  In the future we could
> implement a caching mecinism that can be turned off or on (perhaps create a cache
> plugin achetecture - SOMELib using SOMELib, cool!!!)  that will unload unused
> libraries from memory and when requested load them back up.

I'll put in the code to make it throw out the lib if not a SOMELib.  Not sure when
I'll get the load a directories worth done.

> Cool. Oh I'm going to start work on a preprocesor that is optional (I need to
> refresh myself on the usage of lex and yacc so I said, "why not?").  The cool
> thing about the preprocessor is that using the same functionality as printf
> (unknown # of arguments) I can create an object with an unlimited amount of
> constructors.  It will be awhile before that goes in though.

If you're more interested in Python, go to www.egroups.com/files/boost and get
py_cpp.  You may have to register to get it.  There's a file called gen_function.py
that does something like that.  I haven't looked at it, but it may be interesting.

Hope the changes don't take too long to put into SnagglePuss.


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

Re: [Somelib] More changes

[John P. (Quinticent) <jo...@ma...>]

Thomas Matelich wrote:

>
> > Thomas Matelich wrote:
> >
> > >The solution was to write my own map, which was
> > > surprisingly easy.  Only a few real lines of code.  This change has been
> > > ifdef'ed for windows only and the API remains the same.
> > >
> >
> > Hmm... is your map derived from std::map? I want to add functionality soon
> > that passes in a map to a method to search for multipule object matches.
>
> No, I had to drop std::map completely.  I could make a constructor that takes
> a std::map.  Essentially the problem is when the map is created on one side
> and used on the other.  Although, both sides do share the same memory space,
> the static members of template classes seem to exist on both sides.
>

The solution is to kill windows ;-) Ok, yes add a constrctor that takes a map.
Document this workaround in doxigen.

>
> > There is only one Makefile for the main distro and simple Makefiles for the
> > examples.  The reason for this is I don't use recursive makes but instead
> > include vars.mk and rules.mk from each directory.  This creates a faster
> > build.  Tell me what errors you are getting and I will fix them.
> >
>
> Ok, makes sense.  So the errors I'm getting on hpux are UserConfig.h can't
> find config.h, things can't find boost and apparently your test for if it is
> hpux doesn't work because USE_SOME_HPUX_SL is not defined.  I'll try it out on
> Linux see if I can get it to work there.  Is the directory for installation
> configurable?
>

configure --prefix=<base install dir> (default is /usr but the libs get sent to
<prefix>/lib/SOME and headers to <prefix>/include/SOME)

I could make it more configurable.

As for the test, I guessed at what the name for hpux would be.  I will change the
configure script to print out the current host os.  You send me the output and I
will change it.

What are the directories for libs and includes on HPUX?

> > > 3) Name analysis.  Are these the names we want for our classes
> >
> > Yes.  I think we need to run this through beta testers and develop a
> > vocabulary (Perhaps the Info stuff should be called a catalog and
> > getCategory should be overloaded to handle both the simple catagory and
> > multipule category gets).  Also intern names we use for the maps should be
> > obfusicated so as to avoid name clashes with someone perhaps using
> > "category" as one of their categories.
> >
>
> ClassProperties and LibCatalog?  I'll change the classname and category keys
> to something peculiar.
>

Not ClassProperties this implies encapsulated class variables (eg properties)-
ClassInfo is fine.  I like LibCatalog though.  getCatagory should take arguments:

getCatagory( string simpleCatagory );
getCatagory( string key, string value );
getCatagory( SOME::map keyvalueMap );

setCatagory for the ClassInfo should take:
setCatagory( string simpleCatagory );
setCatagory( string key, string value);

> > > 5) Error conditions.  Currently a few exceptions.  Do we like this?
> >
> > The lib itself should never coredump (it does when it can't find a library
> > on linux).  Users objects we have no control over.
>
> How do you feel about exceptions?  I know a lot of people don't like them, but
> they are standard compliant, and I think the errors we send out are
> exceptional.
>

I'm not sure.  I use them a lot in Java but never touched it in C++.  I guess we
will ask this of our beta testers.

>
> > > 6) Write the searchForLib func.
> >
> > Yes.
>
> Actually, I have no idea what I intended searchForLib to do.  What does it
> sound like to you?
>

findLib is more compact.

Search for a library and return its LibCatalog.  Should we extend LibCatalog to
have the same catagory functionality as ClassInfo?

>
> > > 7) Do we want a getAllLibsInThisDirectory type function?
> >
> > Yes but it should just be the same method that loads the librarys.  The
> > method should just check if the agument given is a file or a directory.  We
> > should also perhaps add the ability to load libraries defined in a an
> > enviornment variable and a text file.
>
> Sounds good to me.  I'll put it on my list.  Though, what if they accidently
> pass in a dir and load 300M of libraries?
>

Hmm...well it is their fault but I see how this could be a problem.  Since we can
only load libs that are compiled for somelib there is no real problem with someone
trying to loadLib( "/usr/lib" ).  Anytime a library is found not to contain the
correct exported functions it should be beaten to death with a stick and then
unloaded from memory (and the programmer/user properly chastised for sloppy
selection of directories).  Remeber also that each loaded lib should only load
into memory the exported function (lazy loading) and memory usage should not go up
until an object is actualy created.  To allow the programmer to finietly control
memory usage we should provide methods for unloading specific libs and checking
the size a library is currently taking up in memory.  In the future we could
implement a caching mecinism that can be turned off or on (perhaps create a cache
plugin achetecture - SOMELib using SOMELib, cool!!!)  that will unload unused
libraries from memory and when requested load them back up.

>
> > > What did I miss?  Should we make a beta dist next week and make a
> > > freshmeat posting?
> > >
> >
> > I was thinking the same thing.  Beta testing should be concentrating on
> > getting ideas from outside developers and then after we freeze the
> > development a final beta should be packaged and all bugs fleshed out for
> > 1.0.  Wow my first 1.0 open source project.
> >
> > I'm interested to know what projects you are using this in.  For me I am
> > using it in Snaglepuss - open source multimedia development. And OnCue -
> > Snaglepuss' scripting enviornment.
>
> So far I've only used it in my own version of CppUnit (the XP unit testing
> framework).  I made it so tests can be stored in shared libraries and loaded
> at runtime.  This is nice because I can now ship my tests and not have their
> existence affect the customer.  I hope to clean it up and get management to
> let me release it.  The neat thing is that each test case has a static member
> which returns a suite of tests and I was able to do some "Test Defines" macros
> to call that static and send it's return back to the host app, rather than
> calling a constructor.
>

Cool. Oh I'm going to start work on a preprocesor that is optional (I need to
refresh myself on the usage of lex and yacc so I said, "why not?").  The cool
thing about the preprocessor is that using the same functionality as printf
(unknown # of arguments) I can create an object with an unlimited amount of
constructors.  It will be awhile before that goes in though.

>
> --
> Thomas O Matelich
> Senior Software Designer
> Zetec, Inc.
> sos...@us...
> tma...@ze...
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

-Quinticent

Re: [Somelib] More changes

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

John Palmieri wrote:

> Thomas Matelich wrote:
>
> >The solution was to write my own map, which was
> > surprisingly easy.  Only a few real lines of code.  This change has been
> > ifdef'ed for windows only and the API remains the same.
> >
>
> Hmm... is your map derived from std::map? I want to add functionality soon
> that passes in a map to a method to search for multipule object matches.

No, I had to drop std::map completely.  I could make a constructor that takes
a std::map.  Essentially the problem is when the map is created on one side
and used on the other.  Although, both sides do share the same memory space,
the static members of template classes seem to exist on both sides.

> There is only one Makefile for the main distro and simple Makefiles for the
> examples.  The reason for this is I don't use recursive makes but instead
> include vars.mk and rules.mk from each directory.  This creates a faster
> build.  Tell me what errors you are getting and I will fix them.
>

Ok, makes sense.  So the errors I'm getting on hpux are UserConfig.h can't
find config.h, things can't find boost and apparently your test for if it is
hpux doesn't work because USE_SOME_HPUX_SL is not defined.  I'll try it out on
Linux see if I can get it to work there.  Is the directory for installation
configurable?

> > 3) Doxygen also generates latex, man, and rtf formats, should I add
> > those to CVS?
>
> Hmm...no but add them to the tarballs.  We should automate their creation
> with a make docs and make docs_install.

make docs calls doxygen doxy_config.

> > Code:
> > 1) Formatting.  I was going to run astyle on it.  Are you CoreLinux++
> > guys using a pretty printer?
>
> I used lint once and hated it but anything taht increases the readability
> of the code I am all for.

astyle.sourceforge.net is cool if you don't hit one of the bugs.
Unfortunately there doesn't appear to be any development being done on it.

> > 3) Name analysis.  Are these the names we want for our classes
>
> Yes.  I think we need to run this through beta testers and develop a
> vocabulary (Perhaps the Info stuff should be called a catalog and
> getCategory should be overloaded to handle both the simple catagory and
> multipule category gets).  Also intern names we use for the maps should be
> obfusicated so as to avoid name clashes with someone perhaps using
> "category" as one of their categories.
>

ClassProperties and LibCatalog?  I'll change the classname and category keys
to something peculiar.

> > 4) Namespaces.  Pretty please :)
>
> I just took a look at the white paper for Itini stuff from RedHat (C++
> wrapper for GTK+).  They use namespaces and I think so should we.  Screw
> all the non complient complilers use g++ :)

Music to my ears.  I will change the SOME_BOOST stuff out of a macro and all
SOME...'s will become SOME::...'s

> > 5) Error conditions.  Currently a few exceptions.  Do we like this?
>
> The lib itself should never coredump (it does when it can't find a library
> on linux).  Users objects we have no control over.

How do you feel about exceptions?  I know a lot of people don't like them, but
they are standard compliant, and I think the errors we send out are
exceptional.

> > 6) Write the searchForLib func.
>
> Yes.

Actually, I have no idea what I intended searchForLib to do.  What does it
sound like to you?

> > 7) Do we want a getAllLibsInThisDirectory type function?
>
> Yes but it should just be the same method that loads the librarys.  The
> method should just check if the agument given is a file or a directory.  We
> should also perhaps add the ability to load libraries defined in a an
> enviornment variable and a text file.

Sounds good to me.  I'll put it on my list.  Though, what if they accidently
pass in a dir and load 300M of libraries?

> > What did I miss?  Should we make a beta dist next week and make a
> > freshmeat posting?
> >
>
> I was thinking the same thing.  Beta testing should be concentrating on
> getting ideas from outside developers and then after we freeze the
> development a final beta should be packaged and all bugs fleshed out for
> 1.0.  Wow my first 1.0 open source project.
>
> I'm interested to know what projects you are using this in.  For me I am
> using it in Snaglepuss - open source multimedia development. And OnCue -
> Snaglepuss' scripting enviornment.

So far I've only used it in my own version of CppUnit (the XP unit testing
framework).  I made it so tests can be stored in shared libraries and loaded
at runtime.  This is nice because I can now ship my tests and not have their
existence affect the customer.  I hope to clean it up and get management to
let me release it.  The neat thing is that each test case has a static member
which returns a suite of tests and I was able to do some "Test Defines" macros
to call that static and send it's return back to the host app, rather than
calling a constructor.


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

Re: [Somelib] More changes

[John P. <jo...@ma...>]

Thomas Matelich wrote:

> Well, I finally finished my project files for Windows.  On our (probably
> my :) TODO list is documentation for using SOMELib on Windows.  There's
> a few tricks involved.
>
> You may notice the addition of some_string_map.h in SOMELib.  This was
> necessary due to the way windows does its dll's and the fact that
> std::map uses a static pointer called Nil for keeping track of things.
> This static would apparently get created both in the app and the dll,
> then when the map was modified by the dll in the initSOMELibInfo
> function it would have a different address than the exe.  Essentially it
> became fubar.  The solution was to write my own map, which was
> surprisingly easy.  Only a few real lines of code.  This change has been
> ifdef'ed for windows only and the API remains the same.
>

Hmm... is your map derived from std::map? I want to add functionality soon
that passes in a map to a method to search for multipule object matches.

>
> The Makefile situation needs some real work, too bad the Software
> Carpentry solution is still on the horizon.  I have as yet been unable
> to get the makefiles to work.  Also, the SOMELib, TestApp, and
> BasicTestLib Makefiles are missing.  If you could put those in
> Quintecent, I would appreciate it.
>

There is only one Makefile for the main distro and simple Makefiles for the
examples.  The reason for this is I don't use recursive makes but instead
include vars.mk and rules.mk from each directory.  This creates a faster
build.  Tell me what errors you are getting and I will fix them.

>
> So what else do we need to do before we can go 1.0?
> Docs, Docs, Docs:
> 1) Finish out API documentation

This is a must.  A person who has to jump through hoops to use our lib
won't.

>
> 2) I'd like to get a homepage put on the sourceforge site
>

Sounds good.  Perhaps someone would like to do this for us.

> 3) Doxygen also generates latex, man, and rtf formats, should I add
> those to CVS?

Hmm...no but add them to the tarballs.  We should automate their creation
with a make docs and make docs_install.

>
> 4) Tutorials
>

Yes also a must.

>
> Code:
> 1) Formatting.  I was going to run astyle on it.  Are you CoreLinux++
> guys using a pretty printer?

I used lint once and hated it but anything taht increases the readability
of the code I am all for.

>
> 2) Spell check.
>

Yes.  I am dislexic and often spell words very very wrong :)

> 3) Name analysis.  Are these the names we want for our classes

Yes.  I think we need to run this through beta testers and develop a
vocabulary (Perhaps the Info stuff should be called a catalog and
getCategory should be overloaded to handle both the simple catagory and
multipule category gets).  Also intern names we use for the maps should be
obfusicated so as to avoid name clashes with someone perhaps using
"category" as one of their categories.

>
> 4) Namespaces.  Pretty please :)
>

I just took a look at the white paper for Itini stuff from RedHat (C++
wrapper for GTK+).  They use namespaces and I think so should we.  Screw
all the non complient complilers use g++ :)

> 5) Error conditions.  Currently a few exceptions.  Do we like this?

The lib itself should never coredump (it does when it can't find a library
on linux).  Users objects we have no control over.

>
> 6) Write the searchForLib func.

Yes.

>
> 7) Do we want a getAllLibsInThisDirectory type function?
>

Yes but it should just be the same method that loads the librarys.  The
method should just check if the agument given is a file or a directory.  We
should also perhaps add the ability to load libraries defined in a an
enviornment variable and a text file.

>
> Examples:
> 1)  Like what you did there Quinticent, do we need more?  Lets try and
> think of other tricks people might want to do with this.
>

Yes.  For each functionality we should add an example.  Beta testers should
be encouraged to contribute.

>
> What did I miss?  Should we make a beta dist next week and make a
> freshmeat posting?
>

I was thinking the same thing.  Beta testing should be concentrating on
getting ideas from outside developers and then after we freeze the
development a final beta should be packaged and all bugs fleshed out for
1.0.  Wow my first 1.0 open source project.

I'm interested to know what projects you are using this in.  For me I am
using it in Snaglepuss - open source multimedia development. And OnCue -
Snaglepuss' scripting enviornment.

>
> --
> Thomas O Matelich
> Senior Software Designer
> Zetec, Inc.
> sos...@us...
> tma...@ze...
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

-Quinticent

[Somelib] More changes

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

Well, I finally finished my project files for Windows.  On our (probably
my :) TODO list is documentation for using SOMELib on Windows.  There's
a few tricks involved.

You may notice the addition of some_string_map.h in SOMELib.  This was
necessary due to the way windows does its dll's and the fact that
std::map uses a static pointer called Nil for keeping track of things.
This static would apparently get created both in the app and the dll,
then when the map was modified by the dll in the initSOMELibInfo
function it would have a different address than the exe.  Essentially it
became fubar.  The solution was to write my own map, which was
surprisingly easy.  Only a few real lines of code.  This change has been
ifdef'ed for windows only and the API remains the same.

The Makefile situation needs some real work, too bad the Software
Carpentry solution is still on the horizon.  I have as yet been unable
to get the makefiles to work.  Also, the SOMELib, TestApp, and
BasicTestLib Makefiles are missing.  If you could put those in
Quintecent, I would appreciate it.

So what else do we need to do before we can go 1.0?
Docs, Docs, Docs:
1) Finish out API documentation
2) I'd like to get a homepage put on the sourceforge site
3) Doxygen also generates latex, man, and rtf formats, should I add
those to CVS?
4) Tutorials

Code:
1) Formatting.  I was going to run astyle on it.  Are you CoreLinux++
guys using a pretty printer?
2) Spell check.
3) Name analysis.  Are these the names we want for our classes
4) Namespaces.  Pretty please :)
5) Error conditions.  Currently a few exceptions.  Do we like this?
6) Write the searchForLib func.
7) Do we want a getAllLibsInThisDirectory type function?

Examples:
1)  Like what you did there Quinticent, do we need more?  Lets try and
think of other tricks people might want to do with this.

What did I miss?  Should we make a beta dist next week and make a
freshmeat posting?


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

Re: [Somelib] Updated makefiles and examples

[John P. <jo...@ma...>]

Configure only creates the config.h and config.mk files.

Thomas Matelich wrote:

> John Palmieri wrote:
>
> > Here are a list of changes I just commited:
> >
> > Updated the Makefile for better handling of crossplatform issues (eg
> > SOME_USE_LINUX_SO is now configured by the configure script along with
> > the hpux one).  Included an install script (make install).  Examples no
> > longer compile by default and now require SOMELib to be installed.
> > remeber to run autoconf and then ./config after you get the sources.
> >
> > -Quinticent (I prefer this since it is a better unique identifier than
> > John :-)
>
> I don't know if I'm doing something wrong, but I don't get any makefiles
> made when I run configure on hpux.  I need to change SOMELib having to be
> installed for the examples for windows, because I don't have an install,
> either that or the install directory has to be SOMELib rather than SOME.
> I won't make the change in CVS now, but will have to.  I did put an ifdef
> around config.h, though.  I'm still in the process of getting windows to
> build.
>
> tom
>
> --
> Thomas O Matelich
> Senior Software Designer
> Zetec, Inc.
> sos...@us...
> tma...@ze...
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

Re: [Somelib] Updated makefiles and examples

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

John Palmieri wrote:

> Here are a list of changes I just commited:
>
> Updated the Makefile for better handling of crossplatform issues (eg
> SOME_USE_LINUX_SO is now configured by the configure script along with
> the hpux one).  Included an install script (make install).  Examples no
> longer compile by default and now require SOMELib to be installed.
> remeber to run autoconf and then ./config after you get the sources.
>
> -Quinticent (I prefer this since it is a better unique identifier than
> John :-)

I don't know if I'm doing something wrong, but I don't get any makefiles
made when I run configure on hpux.  I need to change SOMELib having to be
installed for the examples for windows, because I don't have an install,
either that or the install directory has to be SOMELib rather than SOME.
I won't make the change in CVS now, but will have to.  I did put an ifdef
around config.h, though.  I'm still in the process of getting windows to
build.

tom

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

[Somelib] Updated makefiles and examples

[John P. <jo...@ma...>]

Here are a list of changes I just commited:

Updated the Makefile for better handling of crossplatform issues (eg
SOME_USE_LINUX_SO is now configured by the configure script along with
the hpux one).  Included an install script (make install).  Examples no
longer compile by default and now require SOMELib to be installed.
remeber to run autoconf and then ./config after you get the sources.

-Quinticent (I prefer this since it is a better unique identifier than
John :-)

[Somelib] documentation

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

Added a few std::'s here and there and regenerated the documentation.
I'm using doxygen (http://www.stack.nl/~dimitri/doxygen/index.html) and
to rebuild it just type `doxygen doxy_config` at the some0-5 directory.
I'll work on getting Microsoft projects for your new examples soon.

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

[Somelib] Direction

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

John Palmieri wrote:

> I made some major changes to SOMELib(see my last post).  Everything
> still compiles correctly but extra methods were added so everyone should
> do a cvs update.  I also added a new example "simplemenu" to illistrate
> the use of the new methods.  From now on when new functionality is added
> one of the examples should be updated to reflect this or new examples
> should be created.
>
> --Quinticent
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

sounds good.  I'm working on getting things working on HPUX.  I meant to
write an email kind of explaining myself.  Essentially, I just don't want
this to turn into something where to do what we can now becomes difficult
and the discussions led me to feel that way.  As the suggestions whirled
around in my brain for a while, I came to grips with my problems.  I like
the idea of being able to provide extra info.  Limiting it to category
bothered me, but I hadn't gotten around to fixing it.

Let's list all the places I can think this can go, or has gone.  Also I'll
list my opinion on it:
1)  Load unknown classes:
    a) C++ classes on POSIX, Windows, HPUX - DONE
    b) Other Platforms
    c) Other Languages
2)  Selecting
    a) By Name DONE
    b) By classification DONE (almost, John's gone a long way)
3)  Properties
    a) defined only by the inheritance interface DONE
    b) a fixed IDL type specification
    c) dynamic, may be specified by plugin class
4)  Method invocation
    a) inheritance interface only - DONE
    b) A fixed IDL type specification - I just don't like this idea
    c) A dynamic "map" of functions like EJB(?) - I could maybe get into
this
    d) ?

Some further discussion:
1.b)  I don't have any other platforms.  I need to look into SourceForge's
compile farm.  Also, how does the GPL work, can I look at libtool and see
how they use other platforms or would that be illegal?
1.c)  A lot of work is being done in this area.  I won't rule it out, but I
don't think we should be ruling it out.

3.b) and 4.b)  I don't really like the idea of having a separate file and
preprocessor.  It just seems like an extra area for bugs and versioning
problems.

3.c) and 4.c)  I might be able to get into something like this as long as
we maintain.  This seems like something that would fit in with what Frank
said regarding builtin attribute accessing/mutating.  I'm with John (do you
prefer Quinticent?) in not liking macros and I've already talked about not
liking wrapping all my types, etc..  I'm envisioning something like

SOMEClassProperty:
    attribute or function

SOMEClassAttribute: public SOMEClassProperty
    read-only or writable

SOMEClassMethod: public SOMEClassProperty
    parameter specification, etc.

There are fancy STL/generic things we could use as well.  Well I need to
get to work.


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

[Somelib] Changes are in

[John P. <jo...@ma...>]

I made some major changes to SOMELib(see my last post).  Everything
still compiles correctly but extra methods were added so everyone should
do a cvs update.  I also added a new example "simplemenu" to illistrate
the use of the new methods.  From now on when new functionality is added
one of the examples should be updated to reflect this or new examples
should be created.

--Quinticent

[Somelib] Maps and extending catagory descriptor

[John P. <jo...@ma...>]

I am working on extending SOMEClassInfo by changing both the name and
catagory from individual properties to keys in a
map<string,string> structure.  All member functions are the same and
some have been added to manipulate the map in order to add extra class
info at runtime.  This allows a programmer to further catagorize his/her
plugins.  To support this SOMELibInfo has been given a method to
compliment the getCatagory method.  This method(which has not been named
yet) which takes two strings (key, value) will return all objects whoes
key matches the value.  A further method can be added in the future that
excepts a map of key value pairs and only returns objects that equal
every one of the map's criteria.

-John Palmieri

Re: [Somelib] Another checkin

[Frank V. C. <fr...@co...>]

Thomas Matelich wrote:
> [snip]
> John Palmieri wrote:
> 
> 
> > I want our stuff to be compatable with the CoreLinux++ stuff so once we
> > hammer the details out a bit we should pass it by them and see their
> > thoughts on the subject.
> 
> Can you guess my response to this?  While CoreLinux is going to provide an
> excellent framework for developing very flexible code, I am not the guy to use
> it.  I haven't read the whole scheme, but the links that Frank sent scare me
> (nothing personal).  I don't want to wrap my basic data types.  I want to write
> plain code, using non-invasive libraries that provide a limited, very useful set
> of functionality.  Compatibility is fine with me, but not dependence.

I think that we (CoreLinux++) may be looking to use SOMelib, if
applicable, not the other way around.

And as I don't want to use your bandwidth for CoreLinux++ discussions,
if you would be so kind as to e-mail me or post to one of our mailing
lists what "scared" you <grin>, I would appreciate any constructive
criticism.


-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Somelib] Another checkin

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

John Palmieri wrote:

> Scratch that.  I get it now.  A few items:
>
> Do you think that parameter constructors are necisary?   I always viewed them
> as convinence and they do dirty up the code a bit with the macros.  Also you
> are stuck with being able to construct parameterized constructors only if you
> have a macro that matches the number of parameters.  I have a sever dislike
> of macros ever since I tried to program for windows and wondered why they
> didn't just go the ANSI way.

The only macro functions in the program are the ones for generating boilerplate
object constructors.  I did it this way to simplify the life of the programmer.
Since we are looking for a function to call to return an object of some unknown
class type, we either need to use this macro, or enforce a function to be
present in the class, either by forcing our own base class or by convention and
using templates, oh wait, that wouldn't work because we don't know the type.  I
am strongly opposed to forcing a base class, through personal preference and our
goal to allow this to be easily dropped into a problem.  I don't see a problem
with these simple macros.

To address the multiple constructor issue, I must state that I love references.
Truly, I think they are the best thing since templates (though I'm not sure
which came first).  Anyway, the problem is that member references must be
initialized at construction, hence the need for providing the extra multiple
parameter constructor option.

> The Info class is a nice way to abstract things.  I quite liked it after I
> understood it.  It can be expanded in the future for use with dynamic
> interfaces.  I still think it can be automated.

I agree.  At this point (since I haven't learned Python yet), I haven't done so,
and don't think it will be done for a while.  If standard compliant compilers
were prolific, I would use some fancy template tricks for this.

> BasicPluginInterface should be a pure virtual class with no implementation in
> it. Kinda confused me when an interface has actual code in it.

I suppose the TestApp should be expanded to be more of a training tool, but at
this point it really is just my testbed.  I put the implementation in there for
my own security to make sure the virtual functions really were working.  I can
remove it, or make it pure and have an implementation.  Actually, I think thats
what I'll do.

> Also I belive the SOME_EXPORT macro can consume the extern "C" directive so
> that is no longer a worry of the developers.

I agree, I'll do that.

<pasted in from message title "One More Thing">
John Palmieri wrote:

> I hit send by accident.  The Info class should be implemented as a
> map(Or a vector of maps) rather than a vector so that extra info can be
> stored and retrived from this interface in the future.  I can see how
> dynamic interfaces may work now.

Do you mean like additions to the category info?  I'm assuming you're talking
about SOMEClassInfo (as opposed to SOMELibInfo).

> There is a stub file (perhaps defined in IDL) that exports all the
> symbols for the dynamic interface.  A preparser goes through this file
> and constructs the infoclass and adds a method someDynamicInterface(
> string method,  vector params ) to the implementation file.  This method
> is constructed of a bunch of if statement like so:
>
> int HelloWorld::someDynamicMethodCall( string method, vector params ){
>          //I'm not sure how we will do return types.  Perhaps void pointers.
>          method+= "_"+params.length(); //or whatever the method is.
>                                                           // Note that this
> signiture is only an example
>                                                           // we need to find a
> more unique value
>           if( method == "Print_1" ){  //Print method is called with 1
> parameter
>                  this->Print( dynamic_cast<string>params[0] );
>           } else {
>                  return DynamicInterface::NOSUCHMETHODERROR;
>           }
> }
>
> The infoclass will then have information about print and how many
> parameter and of what type this method takes.  All objects will inherit
> from DynamicInterface which exports the someDynamicMethodCall method and
> all error enumerations.  The Info class can now be used in an IDE to
> edit object properties and generate code much like JavaBeans.
>
> Just a thought.

This is a useful idea.  My problem is that this is not how *I* want to write my
code.  SOMELib to me is a handy, simple way to use plugin classes on multiple
architectures without having to go much out of your way.  Right now all that you
need to do to use this is write your interface, then put some derived classes in
a library with one macro after the class declaration and write a short function
to provide that info to the loading executable.  Implementing a preprocessor,
and forcing table creation is not my idea of a good time.

> I want our stuff to be compatable with the CoreLinux++ stuff so once we
> hammer the details out a bit we should pass it by them and see their
> thoughts on the subject.

Can you guess my response to this?  While CoreLinux is going to provide an
excellent framework for developing very flexible code, I am not the guy to use
it.  I haven't read the whole scheme, but the links that Frank sent scare me
(nothing personal).  I don't want to wrap my basic data types.  I want to write
plain code, using non-invasive libraries that provide a limited, very useful set
of functionality.  Compatibility is fine with me, but not dependence.

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

[Somelib] Recent activity

[Frank V. C. <fr...@co...>]

As I have been reading the posting to this group for a few weeks, every
once in a while I see things like:

> I want our stuff to be compatable with the CoreLinux++ stuff so once we
> hammer the details out a bit we should pass it by them and see their
> thoughts on the subject.

I thought it would be to our mutual benefits to give everyone a "heads
up" to where we are in the similar endeavor.

The relevant framework requirement (although lightly worded):
http://corelinux.sourceforge.net/doc/requirements/req4865.php

And the UML design for the framework abstraction and one implementation
level:
http://corelinux.sourceforge.net/doc/design/4865.php

What we have been doing to facilitate this view is building up the
MetaType, because C++ RTTI just isn't enough, so that when we get to
these frameworks, we can reason with the objects in a more dynamic
fashion. We are avoiding any IDL for the short term, obviously at the
cost of adding more code, but clearly see the usefulness of the
capability in the near term. To support the IDL type thingy, we need a
prepared infrastructure that is denied us by lack of resources.

So, we have been approaching it in the following way, and our current
CVS cut of framework library reflects this work:

1. Creation of the MetaType, and subsequent fundemental type wrappers
(Real, Integer, SmallInteger, etc.) which generate the information and
support needed for the types (size, parents, attributes, factory) in
this endeavor. This is done through macros defined at edit time.

2. Type attribute accessor/mutator enablement (again through macros),
the most useful one being that which takes and returns void pointers to
values which then call instance methods to cast types appropriatley.

What the run-time MetaType instance (e.g. MetaTypeInteger) gives us are
mainly arrays of structures which can be coupled with the type instance
(e.g. Integer myInteger;) to execute against (like your
DynamicMethodCall).

Christophe/Hans (CoreLinux++ team members): You may want to join the
somelib-devel as I may forget to cross post these exchanges.

Thoughts anywhere/anyone?

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Somelib] One more thing

[John P. <jo...@ma...>]

I hit send by accident.  The Info class should be implemented as a
map(Or a vector of maps) rather than a vector so that extra info can be
stored and retrived from this interface in the future.  I can see how
dynamic interfaces may work now.

There is a stub file (perhaps defined in IDL) that exports all the
symbols for the dynamic interface.  A preparser goes through this file
and constructs the infoclass and adds a method someDynamicInterface(
string method,  vector params ) to the implementation file.  This method
is constructed of a bunch of if statement like so:

int HelloWorld::someDynamicMethodCall( string method, vector params ){
         //I'm not sure how we will do return types.  Perhaps void
pointers.
         method+= "_"+params.length(); //or whatever the method is.
                                                          // Note that
this signiture is only an example
                                                          // we need to
find a more unique value
          if( method == "Print_1" ){  //Print method is called with 1
parameter
                 this->Print( dynamic_cast<string>params[0] );
          } else {
                 return DynamicInterface::NOSUCHMETHODERROR;
          }
}

The infoclass will then have information about print and how many
parameter and of what type this method takes.  All objects will inherit
from DynamicInterface which exports the someDynamicMethodCall method and
all error enumerations.  The Info class can now be used in an IDE to
edit object properties and generate code much like JavaBeans.

Just a thought.

I want our stuff to be compatable with the CoreLinux++ stuff so once we
hammer the details out a bit we should pass it by them and see their
thoughts on the subject.

Well that is it for now.

-John Palmieri

Re: [Somelib] Another checkin

[John P. <jo...@ma...>]

Scratch that.  I get it now.  A few items:

Do you think that parameter constructors are necisary?   I always viewed them
as convinence and they do dirty up the code a bit with the macros.  Also you
are stuck with being able to construct parameterized constructors only if you
have a macro that matches the number of parameters.  I have a sever dislike
of macros ever since I tried to program for windows and wondered why they
didn't just go the ANSI way.

The Info class is a nice way to abstract things.  I quite liked it after I
understood it.  It can be expanded in the future for use with dynamic
interfaces.  I still think it can be automated.

BasicPluginInterface should be a pure virtual class with no implementation in
it. Kinda confused me when an interface has actual code in it.

Also I belive the SOME_EXPORT macro can consume the extern "C" directive so
that is no longer a worry of the developers.


John Palmieri wrote:

> Sounds good.  I'll look at it tomorow.  I just made some major
> breakthroughs in my other project and I will be integrating SOMELib soon.
>
> One thought on the Info classes.  Can you show me how these work.  I don't
> quite follow the code.  Say I have a class such as:
>
> class Sprite {
>       public:
>              Sprite();
>              Sprite( string fileName );
>              ~Sprite();
>
>              void render( int x, int y );
>              bool load( string fileName );
>
>        private:
>               string _fileName;
>               char *rawGraphics;
> };
>
> How would I convert this into a SOMEObj?
>
> and say I normaly use it like this:
>
> main(){
> .
> .
> .
> Sprite sp = new Sprite("tux.png");
> sp->render(100,100);
> .
> .
> .
> }
>
> How would I convert this for use with SOMELib?
>
> You see I want to keep the syntax generaly the same with a few extras but
> not so much that it becomes as complicated as COM or Corba.  If that ever
> happend then we are beyond the scope of our project.  If extras like the
> Info class are absolutly needed then perhaps we can rig a pre-parser to
> handle all the gorry details of setting up the vectors.  Well just a
> thought.
>
> -John Palmieri
>
> Thomas Matelich wrote:
>
> > I made some of the changes we talked about.  I have not added the
> > ability to get a SOMEObj directly from the factory yet (kind of dragging
> > my heels on that one because I just don't like it).  John, if you could
> > fix up the configure stuff when you get a chance.  I noticed that I was
> > linking BasicTestLib to TestApp which is silly.  But because I did that,
> > I had to make libSOME into an SO, because TestApp wasn't pulling in all
> > the symbols necessary.
> >
> > How would we go about making configure automatically set up our choice
> > of dll access?
> >
> > --
> > Thomas O Matelich
> > Senior Software Designer
> > Zetec, Inc.
> > sos...@us...
> > tma...@ze...
> >
> > _______________________________________________
> > somelib-devel mailing list
> > som...@li...
> > http://lists.sourceforge.net/mailman/listinfo/somelib-devel
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel