Menu
▾
▴
somelib-devel — Public mailing list for design discussion and bug reports
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
(5) |
Oct
(47) |
Nov
(24) |
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: John P. <jo...@ma...> - 2000-11-20 23:11:02
|
I see you changed the directory checking method of SOME::Path. For some reason _S_IFDIR is not defined on my system. Where is this defined? -Quinticent |
|
From: John P. <jo...@ma...> - 2000-11-17 05:54:14
|
I moved the framework for loading directories into XPPath and Path objects. I need to seperate out the XPPath interface from implementaion. You can still use regular strings to load specific libs for backwards compatability. Path takes a name of a directory or a file name. I will implement wildcard searches later. An example on how to use the Path object is in complexmenu. It is only implemented under linux right now. Path.cpp must be created for each platform (though I suspect that the HPUX and linux versions are similar). I tried to no avail to make it as easy as Path p = "plugins"; to use. I overloaded the assignment operator and gave the base XPPath class XPPath::XPPath( string ) constructors (and const char *) but it still didn't want to compile. Oh well. We can add another platform to the lists of hosts as I have gotten it to compile on FreeBSD. Turns out that the libdl functionality is located in the stdc lib on FreeBSD (and I suspect otherBSD's) I will get around to updating the config so that it checks for libdl and then for the dl functions in libc. I will also change the linux target to unix_so, so I don't piss off the BSD guys, who I find charming but often annoying (Just kidding) . How about that - SOMELib on Apple OS X's Darwin :-) I wonder if they use .so's? Hehe. Sun Solaris is next on my list. -Quinticent |
|
From: Thomas M. <tma...@ze...> - 2000-11-07 20:45:10
|
already done John Palmieri wrote: > I couln't update the CVS yet. I had problems comiling ssh on the Suns so I > couldn't do a commit. If you want just change the == to = and make sure there is > a space (ie "$platform" = "hpux"; not "$platform"="hpux") > > -Quinticent -- Thomas O Matelich Senior Software Designer Zetec, Inc. sos...@us... tma...@ze... |
|
From: John P. <jo...@ma...> - 2000-11-07 18:09:44
|
I couln't update the CVS yet. I had problems comiling ssh on the Suns so I couldn't do a commit. If you want just change the == to = and make sure there is a space (ie "$platform" = "hpux"; not "$platform"="hpux") -Quinticent Thomas Matelich wrote: > "John Palmieri (Quinticent)" wrote: > > > I fixed that, just haven't checked it in. It has to do with the test > > utility. Earlier versions of test use = not ==. > > great, I'll check that out in a few minutes. > > > I tried compiling on a Sun Solaris using the Linux build. Theoretically > > they should be the same. Well the sources compiled but they refused to > > link. I got 500 lines of gibberish error messages. One thing I hate about > > templates is that it makes error messages hard to debug. Could be that they > > are not using the GNU linker. I'll check it out. Do you know anyone who > > knows about Solaris? I have someone looking into the BSD builds too. > > > > -Quinticent > > I have a lot of experience with template error messages, so you could send me > the output if you're having trouble with it. Too bad there isn't a Solaris box > on the compile farm. > It's looking like I may need to be able to compile SOMELib as a static library > on HP because g++ doesn't build libstdc++.a with PIC code. When I determine > that to be true, I'll start adding a static target to the Makefiles (unless you > get to it first :). > > -- > 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 |
|
From: Thomas M. <tma...@ze...> - 2000-11-07 15:54:37
|
"John Palmieri (Quinticent)" wrote: > I fixed that, just haven't checked it in. It has to do with the test > utility. Earlier versions of test use = not ==. great, I'll check that out in a few minutes. > I tried compiling on a Sun Solaris using the Linux build. Theoretically > they should be the same. Well the sources compiled but they refused to > link. I got 500 lines of gibberish error messages. One thing I hate about > templates is that it makes error messages hard to debug. Could be that they > are not using the GNU linker. I'll check it out. Do you know anyone who > knows about Solaris? I have someone looking into the BSD builds too. > > -Quinticent I have a lot of experience with template error messages, so you could send me the output if you're having trouble with it. Too bad there isn't a Solaris box on the compile farm. It's looking like I may need to be able to compile SOMELib as a static library on HP because g++ doesn't build libstdc++.a with PIC code. When I determine that to be true, I'll start adding a static target to the Makefiles (unless you get to it first :). -- Thomas O Matelich Senior Software Designer Zetec, Inc. sos...@us... tma...@ze... |
|
From: John P. (Quinticent) <jo...@ma...> - 2000-11-07 01:54:59
|
I fixed that, just haven't checked it in. It has to do with the test utility. Earlier versions of test use = not ==. I tried compiling on a Sun Solaris using the Linux build. Theoretically they should be the same. Well the sources compiled but they refused to link. I got 500 lines of gibberish error messages. One thing I hate about templates is that it makes error messages hard to debug. Could be that they are not using the GNU linker. I'll check it out. Do you know anyone who knows about Solaris? I have someone looking into the BSD builds too. -Quinticent Thomas Matelich wrote: > I'm in the process of commiting a few changes. I implemented the dynlib > stuff for windows and hpux. One problem I'm noticing with the config > stuff. On hp and one of my two linux boxes (same autoconf version, > 2.13) I get and error running configure on the lines where is checks > platform equal to linux,hpux,... > > on the one linux box it says > ./configure: test: ==: binary operator expected > > on hpux it says: > configure[580]: ==: A test command parameter is not valid. > > 3 errors for the 3 checks. > > If you could look into that, I'd appreciate it. > > -- > 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 |
|
From: Thomas M. <tma...@ze...> - 2000-11-06 23:48:37
|
I'm in the process of commiting a few changes. I implemented the dynlib stuff for windows and hpux. One problem I'm noticing with the config stuff. On hp and one of my two linux boxes (same autoconf version, 2.13) I get and error running configure on the lines where is checks platform equal to linux,hpux,... on the one linux box it says ./configure: test: ==: binary operator expected on hpux it says: configure[580]: ==: A test command parameter is not valid. 3 errors for the 3 checks. If you could look into that, I'd appreciate it. -- Thomas O Matelich Senior Software Designer Zetec, Inc. sos...@us... tma...@ze... |
|
From: John P. <jo...@ma...> - 2000-11-05 19:24:35
|
I started on seperation of the platfor dependent issues by creating
three new directories under SOMELib: linux hpux and windows. I was
creating functionality for directory loading when I relised that putting
all this within #ifdefs in the BasicDynLib.cpp file was very messy.
I decided then to take out all of the DynLib's (SODynLib, DLLDynLib,
etc.) and place them within their own directory as simply DynLib.h and
DynLib.cpp. I started with linux and havn't done hpux yet. Window is
your bag since you need to update the project files for VC++. It should
still compile under windows. All objects should now be named DynLib
since the new build system simply creates a DynLib.o in the SOMELib
directory by compiling from the appropriate configured platform
directory.
On another note this has forced me to fix the platform detection methods
in the makefile and should now work for HPUX. I figured out some of the
silly things that have hampered earlier detection efforts. Like
forgetting to put spaces in the test (ie test "something"<space needed
here>==<space needed here>"something"; then) Ah brings me back to my
academic use of fortran:
write("This is a
1 continuation of a line")
write("Shit I get a compile error here because I forgot to space over 5
frigin columns")
And people still use fortran :-)
You don't want to hear my gripe with python and make using tabs as
delimiters.
-Quinticent
|
|
From: John P. <jo...@ma...> - 2000-11-03 22:08:37
|
Nice. So can you give a tiny bit of code to show how to invoke a raw/smart/etc. pointer? We should provide a way to perhaps do lazy loading of libraries where only a Libraries catalog is loaded and retained in memory. When an object is requested from a perticular lib the lib is loaded in some sort of cache and flushed after it hasn't been used in quite awhile. We could provide mechanisms for keeping libs always in memory for speed/space tradeoffs. For right now though I think SOMELib is solid in terms of functionality. It does what we set out for it to do and barring any more major bugs I think it is ready for beta. Stability is now the top priority. Functionality can wait till 2.0. -Quinticent Thomas Matelich wrote: > I fixed the bug, sort of. The problem was that I was delete'ing lib > from LibCatalog in the destructor. I removed that. Now the problem is > that I'm not deleteing it at all. Your libs will never be unloaded. > Not a problem now because we had no available functionality to do that > in the first place, but in the future... > > Anyway, the recently proposed changes to SOME::Object have been > implemented. I need to change the TestApp so that it tests each way to > get objects. We now have a bunch more examples that need to be written > :) > > Gotta go and prepare a class on Unit Testing for my co-workers using my > test framework based on CppUnit and SOMELib!!! > > -- > 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 |
|
From: Thomas M. <tma...@ze...> - 2000-11-03 05:39:38
|
I fixed the bug, sort of. The problem was that I was delete'ing lib from LibCatalog in the destructor. I removed that. Now the problem is that I'm not deleteing it at all. Your libs will never be unloaded. Not a problem now because we had no available functionality to do that in the first place, but in the future... Anyway, the recently proposed changes to SOME::Object have been implemented. I need to change the TestApp so that it tests each way to get objects. We now have a bunch more examples that need to be written :) Gotta go and prepare a class on Unit Testing for my co-workers using my test framework based on CppUnit and SOMELib!!! -- Thomas O Matelich Senior Software Designer Zetec, Inc. sos...@us... tma...@ze... |
|
From: Thomas M. <tma...@ze...> - 2000-11-02 22:51:11
|
Thomas Matelich wrote: > I have somewhat intentionally screwed up configure.in because the > host_os thing is not working. I have tried everything I can think of to > get it to do it right to no avail. So if you could make it work, that > would be great. Just don't cheat by putting linux first :). SOMELib is currently broken. I don't know what is going on. It's crashing when trying to call a ctor function. Will let you know when its fixed. Sorry for breaking CVS. -- Thomas O Matelich Senior Software Designer Zetec, Inc. sos...@us... tma...@ze... |
|
From: Thomas M. <tma...@ze...> - 2000-11-02 21:43:21
|
I have somewhat intentionally screwed up configure.in because the host_os thing is not working. I have tried everything I can think of to get it to do it right to no avail. So if you could make it work, that would be great. Just don't cheat by putting linux first :). -- Thomas O Matelich Senior Software Designer Zetec, Inc. sos...@us... tma...@ze... |
|
From: John P. <jo...@ma...> - 2000-11-01 21:02:11
|
Make is so number one :-) -Quinticent Thomas Matelich wrote: > John Palmieri wrote: > > > Perhaps instead of getting rid of the boost stuff which could be useful > > to some projects we could create two seperate objects: > > > > SOME::Object which works like the current SOME::Object with the > > exception that it does not destroy the pointer when it goes out of scope > > and provides a destroy, delete, dismember, etc. method for deleting a > > contained object. > > > > SOME::SmartObect which uses the boost smart pointers. > > > > or if you want to keep the functionality of SOME::Object the same we > > could have a SOME::PersistantObject. > > > > What do you think? > > One of the reasons I'm leaning toward sucking some_boost::shared_ptr into > SOME::Object is that I have changed the implementation and it would be > confusing to someone who was using boost::shared_ptr. I'm really thinking > we need to eliminate some_boost. > How about this: > Change ClassCatalog so that instead of giving you shared_ptr's it gives raw > pointers, and create an Object heirarchy. > > Object - abstract base class with virtual functions for getting the T* and > | overloaded operators so that it acts like a pointer. > | > |-SmartObject - Uses ref count > | > |-PersistantObject - No automatic deletion, must call destroy() or > whatever. > | > |-MetaObject? Some automatic CoreLinux++ stuff (I have no idea what I'm > talking about :) > > The biggest downside to this is the virtual function calls but we already > had that, and the user can skip the Object and get the pointer directly if > so desired. Seems to satisfy both our requirements. > > -- > 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 |
|
From: Thomas M. <tma...@ze...> - 2000-11-01 15:49:51
|
John Palmieri wrote: > Perhaps instead of getting rid of the boost stuff which could be useful > to some projects we could create two seperate objects: > > SOME::Object which works like the current SOME::Object with the > exception that it does not destroy the pointer when it goes out of scope > and provides a destroy, delete, dismember, etc. method for deleting a > contained object. > > SOME::SmartObect which uses the boost smart pointers. > > or if you want to keep the functionality of SOME::Object the same we > could have a SOME::PersistantObject. > > What do you think? One of the reasons I'm leaning toward sucking some_boost::shared_ptr into SOME::Object is that I have changed the implementation and it would be confusing to someone who was using boost::shared_ptr. I'm really thinking we need to eliminate some_boost. How about this: Change ClassCatalog so that instead of giving you shared_ptr's it gives raw pointers, and create an Object heirarchy. Object - abstract base class with virtual functions for getting the T* and | overloaded operators so that it acts like a pointer. | |-SmartObject - Uses ref count | |-PersistantObject - No automatic deletion, must call destroy() or whatever. | |-MetaObject? Some automatic CoreLinux++ stuff (I have no idea what I'm talking about :) The biggest downside to this is the virtual function calls but we already had that, and the user can skip the Object and get the pointer directly if so desired. Seems to satisfy both our requirements. -- Thomas O Matelich Senior Software Designer Zetec, Inc. sos...@us... tma...@ze... |
|
From: John P. <jo...@ma...> - 2000-11-01 14:45:37
|
Perhaps instead of getting rid of the boost stuff which could be useful to some projects we could create two seperate objects: SOME::Object which works like the current SOME::Object with the exception that it does not destroy the pointer when it goes out of scope and provides a destroy, delete, dismember, etc. method for deleting a contained object. SOME::SmartObect which uses the boost smart pointers. or if you want to keep the functionality of SOME::Object the same we could have a SOME::PersistantObject. What do you think? --Quinticent |
|
From: Thomas M. <tma...@ze...> - 2000-10-31 19:31:59
|
John Palmieri wrote: > Ok, now that i have that solved how do I create an object that does not get destroyed > after the SOME::Object goes out of scope? I don't want to keep track of more than one > pointer per object loaded. Is there a way of telling the SOME::Object not to delete > pointers after it has gone out of scope (persistance)? Not at this time. I'm starting to think that we should collapse the heirarchy into SOME::Object and provide a release method. -- Thomas O Matelich Senior Software Designer Zetec, Inc. sos...@us... tma...@ze... |
|
From: Frank V. C. <fr...@co...> - 2000-10-31 19:09:27
|
Having had reason to dig into the SOMELib and boost code, the behavior
of a shared_ptr is such that when the reference count drops to zero (0),
there is no longer any need to keep the instance of the underlying
object.
Persistent backed smart pointers are an aspect of a application swap
mechanism, and has the requirement of at least two things in general:
1. A SmartPointer that can drop and re-load on demand by inheriting
(conceptually) some aspects of the shared_ptr (when drop to 0, get rid
of the object instance) but retain some unique thing needed and load the
object again.
2. Obviously a persistence framework :)
This is one of the frameworks that we will be providing at some point.
John Palmieri wrote:
>
> Ok, now that i have that solved how do I create an object that does not get destroyed
> after the SOME::Object goes out of scope? I don't want to keep track of more than one
> pointer per object loaded. Is there a way of telling the SOME::Object not to delete
> pointers after it has gone out of scope (persistance)?
>
> -Quinticent
>
> Thomas Matelich wrote:
>
> > I'll start with a list of statements:
> > 1) SOME::Object<T> hasA T*, but is overloaded to act likeA :) T*.
> > 2) To get the T* out of a SOME::Object, call the get() function.
> > Watch out that your SOME::Object doesn't delete the memory when you don't expect
> > it.
> > 3) If you want implicit conversion, define BOOST_SMART_PTR_CONVERSION.
> > This is dangerous because you might delete the pointer or have the memory go away
> > as in get()
> > 4) If BOOST_NO_MEMBER_TEMPLATES is not defined (and shouldn't need to be for g++),
> > SOME::Object<Base> should be able to be created from SOME::Object<Derived>.
> >
> > > > SOME::Object<mriIVisualAsset>oAsset(assets[0]);
> > > > //construct our asset
> > > > if(!oAsset.construct()){ ...
> > > > 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
> >
> > Since I do love the shared_ptr so much I have propagated it through all my code. So I
> > don't have these problems. I was bit by the problem in number 2) above in a program
> > I'm using this with so that is why I have gone that route. It seems like the problem
> > here is that shared_ptr documentation is not included with the program. I would be
> > tempted to just suck the shared_ptr code into the SOME::Object, but I think having
> > things separate is good. On the other hand, I had to modify the shared_ptr code from
> > boost standard to make it inheritable. So the pros of inheritance is a smaller
> > interface for SOME::Object, and the cons are disjoint concepts and problems with trying
> > to use Object without understanding shared_ptr, also the fact that I had to change the
> > boost implementation. What do you think?
> >
> > So anyway the solution to your problem is one of the following:
> > 1) define BOOST_SMART_PTR_CONVERSION
> > 2) asset = static_cast<mriIAsset*>(oAsset.get());
> > 3) use Object everywhere in place of pointers
> > 4) use shared_ptr everywhere in place of pointers
> >
> > A couple of other notes. I usually just use the lowest (furthest to the base) possible
> > level in my inheritance hierarchy as the template parameter for the Object. That way,
> > I don't have to worry about downcasting. Also, shouldn't static_cast be dynamic_cast?
> >
> > --
> > 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
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package
|
|
From: John P. <jo...@ma...> - 2000-10-31 18:34:31
|
Ok, now that i have that solved how do I create an object that does not get destroyed
after the SOME::Object goes out of scope? I don't want to keep track of more than one
pointer per object loaded. Is there a way of telling the SOME::Object not to delete
pointers after it has gone out of scope (persistance)?
-Quinticent
Thomas Matelich wrote:
> I'll start with a list of statements:
> 1) SOME::Object<T> hasA T*, but is overloaded to act likeA :) T*.
> 2) To get the T* out of a SOME::Object, call the get() function.
> Watch out that your SOME::Object doesn't delete the memory when you don't expect
> it.
> 3) If you want implicit conversion, define BOOST_SMART_PTR_CONVERSION.
> This is dangerous because you might delete the pointer or have the memory go away
> as in get()
> 4) If BOOST_NO_MEMBER_TEMPLATES is not defined (and shouldn't need to be for g++),
> SOME::Object<Base> should be able to be created from SOME::Object<Derived>.
>
> > > SOME::Object<mriIVisualAsset>oAsset(assets[0]);
> > > //construct our asset
> > > if(!oAsset.construct()){ ...
> > > 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
>
> Since I do love the shared_ptr so much I have propagated it through all my code. So I
> don't have these problems. I was bit by the problem in number 2) above in a program
> I'm using this with so that is why I have gone that route. It seems like the problem
> here is that shared_ptr documentation is not included with the program. I would be
> tempted to just suck the shared_ptr code into the SOME::Object, but I think having
> things separate is good. On the other hand, I had to modify the shared_ptr code from
> boost standard to make it inheritable. So the pros of inheritance is a smaller
> interface for SOME::Object, and the cons are disjoint concepts and problems with trying
> to use Object without understanding shared_ptr, also the fact that I had to change the
> boost implementation. What do you think?
>
> So anyway the solution to your problem is one of the following:
> 1) define BOOST_SMART_PTR_CONVERSION
> 2) asset = static_cast<mriIAsset*>(oAsset.get());
> 3) use Object everywhere in place of pointers
> 4) use shared_ptr everywhere in place of pointers
>
> A couple of other notes. I usually just use the lowest (furthest to the base) possible
> level in my inheritance hierarchy as the template parameter for the Object. That way,
> I don't have to worry about downcasting. Also, shouldn't static_cast be dynamic_cast?
>
> --
> 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
|
|
From: Frank V. C. <fr...@co...> - 2000-10-31 16:15:45
|
As Thomas noted:
mriAsset *asset = oAsset->get();
should do the trick and is more "newbie friendly".
John Palmieri wrote:
>
> After looking at it a bit more I fixed it using:
>
> mriIAsset *asset = &(*oAsset);
>
> I just don't like this as a solution having to derefrence then get the address. It
> is kind of round about and will confuse C++ newbies.
>
> --Quinticent
>
> "Frank V. Castellucci" wrote:
>
> > Did you try the sample code? If you get the same error, what gcc version
> > are you using?
> >
> > Frank
> >
> > John Palmieri wrote:
> > >
> > > I still get the error:
> > >
> > > cannot convert `oAsset' from type `SOME::Object<mriIVisualAsset>' to type
> > > `mriIAsset *'
> > >
> > > -Quinticent
> > >
> > > "Frank V. Castellucci" wrote:
> > >
> > > > You were right the first time, SOME::Object is not a class in the
> > > > hierarchy and once you instantiate it:
> > > >
> > > > --> SOME::Object<mriIVisualAsset>oAsset(assets[0]);
> > > >
> > > > it IS only a SOME::Object/shared_ptr<mriVisualAsset>, but looking at the
> > > > shared_ptr, you should be able to:
> > > >
> > > > --> mriAsset *asset = oAsset;
> > > >
> > > > which should call the coercion operator on boost::shared_ptr. At least
> > > > that's how it behaves (compiles, runs without error) for me in the
> > > > attached emulation test.
> > > >
> > > > "John Palmieri (Quinticent)" wrote:
> > > > >
> > > > > 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
> > > > >
> > > > > _______________________________________________
> > > > > 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
> > > >
> > > > ------------------------------------------------------------------------
> > > >
> > > > #include <iostream>
> > > >
> > > > template <typename T>
> > > > class boostemul
> > > > {
> > > > public:
> > > > boostemul(T *aT)
> > > > :
> > > > theValue(aT)
> > > > {
> > > > }
> > > > operator T*( void ) const
> > > > {
> > > > return theValue;
> > > > }
> > > > private:
> > > > T *theValue;
> > > > };
> > > >
> > > > template <typename U>
> > > > class somObjemu : public boostemul<U>
> > > > {
> > > > public:
> > > > somObjemu( U *aU )
> > > > :
> > > > boostemul<U>( aU )
> > > > {
> > > > }
> > > > };
> > > >
> > > > class mriAsset
> > > > {
> > > > public:
> > > > mriAsset(){}
> > > > virtual void render( void ) = 0;
> > > > };
> > > >
> > > > class mriAudioAsset : public mriAsset
> > > > {
> > > > public:
> > > > mriAudioAsset():mriAsset(){}
> > > > virtual void render( void )
> > > > {
> > > > cout << "In audio render." << endl;
> > > > }
> > > > };
> > > >
> > > > class mriVisualAsset : public mriAsset
> > > > {
> > > > public:
> > > > mriVisualAsset():mriAsset(){}
> > > > virtual void render( void )
> > > > {
> > > > cout << "In visual render." << endl;
> > > > }
> > > > };
> > > >
> > > > int main( void )
> > > > {
> > > > mriVisualAsset anA2;
> > > >
> > > > somObjemu<mriVisualAsset> aObj(&anA2);
> > > >
> > > > mriAsset *pA = aObj;
> > > > pA->render();
> > > > return 0;
> > > > }
> > >
> > > _______________________________________________
> > > 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
>
> _______________________________________________
> 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
|
|
From: Thomas M. <tma...@ze...> - 2000-10-31 15:18:56
|
I'll start with a list of statements:
1) SOME::Object<T> hasA T*, but is overloaded to act likeA :) T*.
2) To get the T* out of a SOME::Object, call the get() function.
Watch out that your SOME::Object doesn't delete the memory when you don't expect
it.
3) If you want implicit conversion, define BOOST_SMART_PTR_CONVERSION.
This is dangerous because you might delete the pointer or have the memory go away
as in get()
4) If BOOST_NO_MEMBER_TEMPLATES is not defined (and shouldn't need to be for g++),
SOME::Object<Base> should be able to be created from SOME::Object<Derived>.
> > SOME::Object<mriIVisualAsset>oAsset(assets[0]);
> > //construct our asset
> > if(!oAsset.construct()){ ...
> > 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
Since I do love the shared_ptr so much I have propagated it through all my code. So I
don't have these problems. I was bit by the problem in number 2) above in a program
I'm using this with so that is why I have gone that route. It seems like the problem
here is that shared_ptr documentation is not included with the program. I would be
tempted to just suck the shared_ptr code into the SOME::Object, but I think having
things separate is good. On the other hand, I had to modify the shared_ptr code from
boost standard to make it inheritable. So the pros of inheritance is a smaller
interface for SOME::Object, and the cons are disjoint concepts and problems with trying
to use Object without understanding shared_ptr, also the fact that I had to change the
boost implementation. What do you think?
So anyway the solution to your problem is one of the following:
1) define BOOST_SMART_PTR_CONVERSION
2) asset = static_cast<mriIAsset*>(oAsset.get());
3) use Object everywhere in place of pointers
4) use shared_ptr everywhere in place of pointers
A couple of other notes. I usually just use the lowest (furthest to the base) possible
level in my inheritance hierarchy as the template parameter for the Object. That way,
I don't have to worry about downcasting. Also, shouldn't static_cast be dynamic_cast?
--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...
|
|
From: John P. <jo...@ma...> - 2000-10-31 14:17:18
|
After looking at it a bit more I fixed it using:
mriIAsset *asset = &(*oAsset);
I just don't like this as a solution having to derefrence then get the address. It
is kind of round about and will confuse C++ newbies.
--Quinticent
"Frank V. Castellucci" wrote:
> Did you try the sample code? If you get the same error, what gcc version
> are you using?
>
> Frank
>
> John Palmieri wrote:
> >
> > I still get the error:
> >
> > cannot convert `oAsset' from type `SOME::Object<mriIVisualAsset>' to type
> > `mriIAsset *'
> >
> > -Quinticent
> >
> > "Frank V. Castellucci" wrote:
> >
> > > You were right the first time, SOME::Object is not a class in the
> > > hierarchy and once you instantiate it:
> > >
> > > --> SOME::Object<mriIVisualAsset>oAsset(assets[0]);
> > >
> > > it IS only a SOME::Object/shared_ptr<mriVisualAsset>, but looking at the
> > > shared_ptr, you should be able to:
> > >
> > > --> mriAsset *asset = oAsset;
> > >
> > > which should call the coercion operator on boost::shared_ptr. At least
> > > that's how it behaves (compiles, runs without error) for me in the
> > > attached emulation test.
> > >
> > > "John Palmieri (Quinticent)" wrote:
> > > >
> > > > 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
> > > >
> > > > _______________________________________________
> > > > 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
> > >
> > > ------------------------------------------------------------------------
> > >
> > > #include <iostream>
> > >
> > > template <typename T>
> > > class boostemul
> > > {
> > > public:
> > > boostemul(T *aT)
> > > :
> > > theValue(aT)
> > > {
> > > }
> > > operator T*( void ) const
> > > {
> > > return theValue;
> > > }
> > > private:
> > > T *theValue;
> > > };
> > >
> > > template <typename U>
> > > class somObjemu : public boostemul<U>
> > > {
> > > public:
> > > somObjemu( U *aU )
> > > :
> > > boostemul<U>( aU )
> > > {
> > > }
> > > };
> > >
> > > class mriAsset
> > > {
> > > public:
> > > mriAsset(){}
> > > virtual void render( void ) = 0;
> > > };
> > >
> > > class mriAudioAsset : public mriAsset
> > > {
> > > public:
> > > mriAudioAsset():mriAsset(){}
> > > virtual void render( void )
> > > {
> > > cout << "In audio render." << endl;
> > > }
> > > };
> > >
> > > class mriVisualAsset : public mriAsset
> > > {
> > > public:
> > > mriVisualAsset():mriAsset(){}
> > > virtual void render( void )
> > > {
> > > cout << "In visual render." << endl;
> > > }
> > > };
> > >
> > > int main( void )
> > > {
> > > mriVisualAsset anA2;
> > >
> > > somObjemu<mriVisualAsset> aObj(&anA2);
> > >
> > > mriAsset *pA = aObj;
> > > pA->render();
> > > return 0;
> > > }
> >
> > _______________________________________________
> > 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
|
|
From: John P. <jo...@ma...> - 2000-10-31 14:07:16
|
Ya that compiles. Actualy I negelected to note that mriIVisualAsset is a pure
virtual interface. So the hiarchy goes mriIAsset-->mriIVisualAsset-->mriSpriteAsset
mriSpriteAsset is then loaded using the SOME::Object<mriIVisualAsset>
could this be the problem?
-Quinticent
"Frank V. Castellucci" wrote:
> Did you try the sample code? If you get the same error, what gcc version
> are you using?
>
> Frank
>
> John Palmieri wrote:
> >
> > I still get the error:
> >
> > cannot convert `oAsset' from type `SOME::Object<mriIVisualAsset>' to type
> > `mriIAsset *'
> >
> > -Quinticent
> >
> > "Frank V. Castellucci" wrote:
> >
> > > You were right the first time, SOME::Object is not a class in the
> > > hierarchy and once you instantiate it:
> > >
> > > --> SOME::Object<mriIVisualAsset>oAsset(assets[0]);
> > >
> > > it IS only a SOME::Object/shared_ptr<mriVisualAsset>, but looking at the
> > > shared_ptr, you should be able to:
> > >
> > > --> mriAsset *asset = oAsset;
> > >
> > > which should call the coercion operator on boost::shared_ptr. At least
> > > that's how it behaves (compiles, runs without error) for me in the
> > > attached emulation test.
> > >
> > > "John Palmieri (Quinticent)" wrote:
> > > >
> > > > 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
> > > >
> > > > _______________________________________________
> > > > 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
> > >
> > > ------------------------------------------------------------------------
> > >
> > > #include <iostream>
> > >
> > > template <typename T>
> > > class boostemul
> > > {
> > > public:
> > > boostemul(T *aT)
> > > :
> > > theValue(aT)
> > > {
> > > }
> > > operator T*( void ) const
> > > {
> > > return theValue;
> > > }
> > > private:
> > > T *theValue;
> > > };
> > >
> > > template <typename U>
> > > class somObjemu : public boostemul<U>
> > > {
> > > public:
> > > somObjemu( U *aU )
> > > :
> > > boostemul<U>( aU )
> > > {
> > > }
> > > };
> > >
> > > class mriAsset
> > > {
> > > public:
> > > mriAsset(){}
> > > virtual void render( void ) = 0;
> > > };
> > >
> > > class mriAudioAsset : public mriAsset
> > > {
> > > public:
> > > mriAudioAsset():mriAsset(){}
> > > virtual void render( void )
> > > {
> > > cout << "In audio render." << endl;
> > > }
> > > };
> > >
> > > class mriVisualAsset : public mriAsset
> > > {
> > > public:
> > > mriVisualAsset():mriAsset(){}
> > > virtual void render( void )
> > > {
> > > cout << "In visual render." << endl;
> > > }
> > > };
> > >
> > > int main( void )
> > > {
> > > mriVisualAsset anA2;
> > >
> > > somObjemu<mriVisualAsset> aObj(&anA2);
> > >
> > > mriAsset *pA = aObj;
> > > pA->render();
> > > return 0;
> > > }
> >
> > _______________________________________________
> > 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
|
|
From: Frank V. C. <fr...@co...> - 2000-10-31 13:28:45
|
Did you try the sample code? If you get the same error, what gcc version
are you using?
Frank
John Palmieri wrote:
>
> I still get the error:
>
> cannot convert `oAsset' from type `SOME::Object<mriIVisualAsset>' to type
> `mriIAsset *'
>
> -Quinticent
>
> "Frank V. Castellucci" wrote:
>
> > You were right the first time, SOME::Object is not a class in the
> > hierarchy and once you instantiate it:
> >
> > --> SOME::Object<mriIVisualAsset>oAsset(assets[0]);
> >
> > it IS only a SOME::Object/shared_ptr<mriVisualAsset>, but looking at the
> > shared_ptr, you should be able to:
> >
> > --> mriAsset *asset = oAsset;
> >
> > which should call the coercion operator on boost::shared_ptr. At least
> > that's how it behaves (compiles, runs without error) for me in the
> > attached emulation test.
> >
> > "John Palmieri (Quinticent)" wrote:
> > >
> > > 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
> > >
> > > _______________________________________________
> > > 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
> >
> > ------------------------------------------------------------------------
> >
> > #include <iostream>
> >
> > template <typename T>
> > class boostemul
> > {
> > public:
> > boostemul(T *aT)
> > :
> > theValue(aT)
> > {
> > }
> > operator T*( void ) const
> > {
> > return theValue;
> > }
> > private:
> > T *theValue;
> > };
> >
> > template <typename U>
> > class somObjemu : public boostemul<U>
> > {
> > public:
> > somObjemu( U *aU )
> > :
> > boostemul<U>( aU )
> > {
> > }
> > };
> >
> > class mriAsset
> > {
> > public:
> > mriAsset(){}
> > virtual void render( void ) = 0;
> > };
> >
> > class mriAudioAsset : public mriAsset
> > {
> > public:
> > mriAudioAsset():mriAsset(){}
> > virtual void render( void )
> > {
> > cout << "In audio render." << endl;
> > }
> > };
> >
> > class mriVisualAsset : public mriAsset
> > {
> > public:
> > mriVisualAsset():mriAsset(){}
> > virtual void render( void )
> > {
> > cout << "In visual render." << endl;
> > }
> > };
> >
> > int main( void )
> > {
> > mriVisualAsset anA2;
> >
> > somObjemu<mriVisualAsset> aObj(&anA2);
> >
> > mriAsset *pA = aObj;
> > pA->render();
> > return 0;
> > }
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel
|
|
From: John P. <jo...@ma...> - 2000-10-31 13:19:06
|
I still get the error:
cannot convert `oAsset' from type `SOME::Object<mriIVisualAsset>' to type
`mriIAsset *'
-Quinticent
"Frank V. Castellucci" wrote:
> You were right the first time, SOME::Object is not a class in the
> hierarchy and once you instantiate it:
>
> --> SOME::Object<mriIVisualAsset>oAsset(assets[0]);
>
> it IS only a SOME::Object/shared_ptr<mriVisualAsset>, but looking at the
> shared_ptr, you should be able to:
>
> --> mriAsset *asset = oAsset;
>
> which should call the coercion operator on boost::shared_ptr. At least
> that's how it behaves (compiles, runs without error) for me in the
> attached emulation test.
>
> "John Palmieri (Quinticent)" wrote:
> >
> > 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
> >
> > _______________________________________________
> > 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
>
> ------------------------------------------------------------------------
>
> #include <iostream>
>
> template <typename T>
> class boostemul
> {
> public:
> boostemul(T *aT)
> :
> theValue(aT)
> {
> }
> operator T*( void ) const
> {
> return theValue;
> }
> private:
> T *theValue;
> };
>
> template <typename U>
> class somObjemu : public boostemul<U>
> {
> public:
> somObjemu( U *aU )
> :
> boostemul<U>( aU )
> {
> }
> };
>
> class mriAsset
> {
> public:
> mriAsset(){}
> virtual void render( void ) = 0;
> };
>
> class mriAudioAsset : public mriAsset
> {
> public:
> mriAudioAsset():mriAsset(){}
> virtual void render( void )
> {
> cout << "In audio render." << endl;
> }
> };
>
> class mriVisualAsset : public mriAsset
> {
> public:
> mriVisualAsset():mriAsset(){}
> virtual void render( void )
> {
> cout << "In visual render." << endl;
> }
> };
>
> int main( void )
> {
> mriVisualAsset anA2;
>
> somObjemu<mriVisualAsset> aObj(&anA2);
>
> mriAsset *pA = aObj;
> pA->render();
> return 0;
> }
|
|
From: Frank V. C. <fr...@co...> - 2000-10-31 12:34:36
|
You were right the first time, SOME::Object is not a class in the
hierarchy and once you instantiate it:
--> SOME::Object<mriIVisualAsset>oAsset(assets[0]);
it IS only a SOME::Object/shared_ptr<mriVisualAsset>, but looking at the
shared_ptr, you should be able to:
--> mriAsset *asset = oAsset;
which should call the coercion operator on boost::shared_ptr. At least
that's how it behaves (compiles, runs without error) for me in the
attached emulation test.
"John Palmieri (Quinticent)" wrote:
>
> 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
>
> _______________________________________________
> 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 |
