I would imagine we can map the contents of the Operation into an SDO. Would this cope with "pass by reference" semantics? Would we be storing copies of the parameters in the SDO or pointers to them as is the case now with the Operation class? If so do we still get the same memory management problems as today?
It seems a long time ago since we came up with the Operation class. I recall the interesting problems were around parameters and return values that are pointers or references ... and who allocates/frees the memory. Can we optimise this for local calls (pass by reference) or do we always pass by value? This area certainly needs a fresh brain to look at it ;-) Cheers, On 27/09/2007, Brady Johnson <[EMAIL PROTECTED]> wrote: > > I've been looking at how the Operation class works and have been > considering refactoring it since it has some memory leaks and should use > STL templates, and I came to the realization that its duplicating a lot > of what SDO does. The Operation class seems to serve 2 purposes: > - Store the Operation Name > - Store the Operation Parameters > > All of the Operation setReturnValue(), addParameter(), and > getParameter() methods are duplicating what an SDO DataObject does, so > why not just use an SDO? The method signatures that use the Operation > class can be changed to take a std::string for the operationName and to > take a DataObjectPtr for the parameters. The DataObjectPtr can contain a > DataObjectPtr child for each WSDL message part. Additionally, I suggest > adding a 3rd argument, which would be the output message, so the > resulting ServiceWrapper::invoke() signature would look like this: > > void ServiceWrapper::invoke( const std::string &operationName, > DataObjectPtr input, DataObjectPtr output ); > > If we take this approach, the affected areas will be the samples > (anywhere a ServiceWrapper is used) and scagen. > > Any opinions? > > -------------------- > Brady Johnson > Lead Software Developer - HydraSCA > Rogue Wave Software - [EMAIL PROTECTED] > > -- Pete --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
