Thread: [Opentnl-general] I've been making some updates recently... they will break your code!
Brought to you by:
mark_frohnmayer,
s_alanet
From: Mark F. <ma...@ga...> - 2005-02-22 09:55:20
|
The CVS repo now has a bunch of RPC-related changes in. The new RPC/journal/ThreadQueue macros have an extra parameter which is the argument name list -- so TNL_IMPLEMENT_RPC(SomeObject, SomeMethod, (S32 someArg1, U32 someArg2), ...) becomes TNL_IMPLEMENT_RPC(SomeObject, SomeMethod, (S32 someArg1, U32 someArg2), (someArg1, someArg2), ...) The reason for this is that the functions for parsing the RPC arg lists, marshalling and unmarshalling RPC call data and the assembly language dispatch functions have all been removed and replaced by a template based system. The new system is substantially more stable and extensible to new data types. Visual C++ 6.0 is no longer a TNL supported compiler. I'll be updating the packages as well as the documentation over the next while... - Mark |
From: Brad K. <br...@wi...> - 2005-02-28 23:00:32
Attachments:
method-dispatch-multiple-inheritance.patch
|
I'm new to opentnl, so please forgive me if I fail some list etiquette... With regard to the new RPC-related code, the FunctorDecl template classes do not support multiple inheritance, I've attached a patch to add support. However, I'm not sure that this patch doesn't break assumptions made elsewhere. In particular, I switched Functor::dispatch to take an Object* for the argument instead of a void*. This caused no breakage for me, but it seems like it was clearly unintended in the design of the Functor class. Anyways here's my first attempt at a patch. In the absence of the formal contribution form (http://www.opentnl.org/assignment.html), I don't know what to do from here though. -Brad Kittenbrink br...@wi... Mark Frohnmayer wrote: > The CVS repo now has a bunch of RPC-related changes in. The new > RPC/journal/ThreadQueue macros have an extra parameter which is the > argument name list -- so > > TNL_IMPLEMENT_RPC(SomeObject, SomeMethod, (S32 someArg1, U32 > someArg2), ...) > > becomes > > TNL_IMPLEMENT_RPC(SomeObject, SomeMethod, (S32 someArg1, U32 > someArg2), (someArg1, someArg2), ...) > > The reason for this is that the functions for parsing the RPC arg > lists, marshalling and unmarshalling RPC call data and the assembly > language dispatch functions have all been removed and replaced by a > template based system. The new system is substantially more stable > and extensible to new data types. Visual C++ 6.0 is no longer a TNL > supported compiler. > > I'll be updating the packages as well as the documentation over the > next while... > > - Mark > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Opentnl-general mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentnl-general > > |
From: Ville A. B. <vbe...@cc...> - 2005-03-23 16:42:18
|
On Tue, 22 Feb 2005, Mark Frohnmayer wrote: > The CVS repo now has a bunch of RPC-related changes in. The new > RPC/journal/ThreadQueue macros have an extra parameter which is the argument > name list -- so > > TNL_IMPLEMENT_RPC(SomeObject, SomeMethod, (S32 someArg1, U32 someArg2), ...) > > becomes > > TNL_IMPLEMENT_RPC(SomeObject, SomeMethod, (S32 someArg1, U32 someArg2), > (someArg1, someArg2), ...) > > The reason for this is that the functions for parsing the RPC arg lists, > marshalling and unmarshalling RPC call data and the assembly language > dispatch functions have all been removed and replaced by a template based > system. The new system is substantially more stable and extensible to new > data types. Visual C++ 6.0 is no longer a TNL supported compiler. > > I'll be updating the packages as well as the documentation over the next > while... Hi, Have you also changed the RPC system so that you cannot use c-strings as RPC arguments anymore? I have an RPC method with the parameter list (S8 from, S8 to, const char *msg). I changed the implementation macro as explained above. This is what I get when compiling (using OpenTNL 1.5.0 headers): g++ -c -O -Wall -mwindows -D__WIN32__ -DSDL -DHWRENDER -I../include n_connection.cpp -o ../objs/n_connection.o ../include/tnl/tnlMethodDispatch.h: In function `void Types::read(TNL::BitStream&, T*) [with T = const char*]': ../include/tnl/tnlMethodDispatch.h:234: instantiated from `void TNL::FunctorDecl<void (T::*)(A, B, C)>::read(TNL::BitStream&) [with T = LConnection, A = signed char, B = signed char, C = const char*]' ../include/g_pawn.h:177: instantiated from here ../include/tnl/tnlMethodDispatch.h:85: no matching function for call to ` TNL::BitStream::read(const char**&)' ../include/tnl/tnlBitStream.h:211: candidates are: bool TNL::BitStream::read(TNL::ByteBuffer*) ../include/tnl/tnlBitStream.h:238: bool TNL::BitStream::read(bool*) ../include/tnl/tnlBitStream.h:331: bool TNL::BitStream::read(unsigned int, void*) ../include/tnl/tnlBitStream.h:260: bool TNL::BitStream::read(U8*) ../include/tnl/tnlBitStream.h:261: bool TNL::BitStream::read(S8*) ../include/tnl/tnlBitStream.h:262: bool TNL::BitStream::read(U16*) ../include/tnl/tnlBitStream.h:263: bool TNL::BitStream::read(S16*) ../include/tnl/tnlBitStream.h:264: bool TNL::BitStream::read(U32*) ../include/tnl/tnlBitStream.h:265: bool TNL::BitStream::read(S32*) ../include/tnl/tnlBitStream.h:266: bool TNL::BitStream::read(S64*) ../include/tnl/tnlBitStream.h:267: bool TNL::BitStream::read(U64*) ../include/tnl/tnlBitStream.h:268: bool TNL::BitStream::read(F32*) ../include/tnl/tnlBitStream.h:269: bool TNL::BitStream::read(F64*) Regards, Ville Bergholm |
From: Mark F. <ma...@ga...> - 2005-03-24 00:37:29
|
Yes. You have to use the StringPtr type with the new RPC code. > Have you also changed the RPC system so that you cannot use c-strings > as RPC arguments anymore? > > I have an RPC method with the parameter list (S8 from, S8 to, const > char *msg). > I changed the implementation macro as explained above. > This is what I get when compiling (using OpenTNL 1.5.0 headers): > > > g++ -c -O -Wall -mwindows -D__WIN32__ -DSDL -DHWRENDER -I../include > n_connection.cpp -o ../objs/n_connection.o > ../include/tnl/tnlMethodDispatch.h: In function `void > Types::read(TNL::BitStream&, T*) [with T = const char*]': > ../include/tnl/tnlMethodDispatch.h:234: instantiated from `void > TNL::FunctorDecl<void (T::*)(A, B, C)>::read(TNL::BitStream&) [with T > = LConnection, A = signed char, B = signed char, C = const char*]' > ../include/g_pawn.h:177: instantiated from here > ../include/tnl/tnlMethodDispatch.h:85: no matching function for call to ` > TNL::BitStream::read(const char**&)' > ../include/tnl/tnlBitStream.h:211: candidates are: bool > TNL::BitStream::read(TNL::ByteBuffer*) > ../include/tnl/tnlBitStream.h:238: bool > TNL::BitStream::read(bool*) > ../include/tnl/tnlBitStream.h:331: bool > TNL::BitStream::read(unsigned int, void*) > ../include/tnl/tnlBitStream.h:260: bool > TNL::BitStream::read(U8*) > ../include/tnl/tnlBitStream.h:261: bool > TNL::BitStream::read(S8*) > ../include/tnl/tnlBitStream.h:262: bool > TNL::BitStream::read(U16*) > ../include/tnl/tnlBitStream.h:263: bool > TNL::BitStream::read(S16*) > ../include/tnl/tnlBitStream.h:264: bool > TNL::BitStream::read(U32*) > ../include/tnl/tnlBitStream.h:265: bool > TNL::BitStream::read(S32*) > ../include/tnl/tnlBitStream.h:266: bool > TNL::BitStream::read(S64*) > ../include/tnl/tnlBitStream.h:267: bool > TNL::BitStream::read(U64*) > ../include/tnl/tnlBitStream.h:268: bool > TNL::BitStream::read(F32*) > ../include/tnl/tnlBitStream.h:269: bool > TNL::BitStream::read(F64*) |