Either me or Boris, whoever gets to it first.

At present it is there only for boxed valuetypes, still need to add it for the 
rest.

will be handled by Remedy

accept

to Kees

to pool

The actual implimentation of the _copy_value call has to be provided by the end user when he derives his ultimate type from the generated types.

All other "generated" _copy_value calls would be complete "rubbish" placeholders that would not get called.  This is why no-one has changed TAO to be CORBA complient in this reguard.  (ValueBase should have _copy_value as pure virtual, where we have it as a virtual with sa default implimention of an assert if called).

Basically:
the ValueBase _copy_value() should be pure virtual, and therefore would HAVE to be implemented in ALL derived types up the hierarchy, ultimately to the top level where YOUR application implementation of the ValueType would be required to implement HOW the _copy_value() actually performs this work.

Normally via "return new derivedValueType(this->a(), this->b(), this->c()...)" or similar.

The point here is that ultimately it is YOUR responsibility to provide the correct way to implement _copy_value() in YOUR top level derived class that implements the actual value type, the lower level do not actually know HOW to copy the value type correctly.

If this feature was corrected according to the spec, and made pure virtual, ALL levels of the hierarchy inside TAO would have to provide a "rubbish" implementation of _copy_value() which considering that TAO does not generate any code that uses this function would be redundant.

Anys take a copy of valuetypes in TAO by referance counting increaments, not by calling _copy_value() which is an implimentation issue. _copy_value is not used by any of TAO internally and so it currently does not enforce the requirement for the end user to over-ride this method. Since TAO does provide a default "assert" implementation in the code for ValueBase._copy_value() so that if it is never overridden and the end user calls it anyway, it will fault correctly with an assert (in debug builds).

From: Jeff Parsons [mailto:j.parsons@vanderbilt.edu] 
Sent: Wednesday, 1 May 2013 14:09
To: Simon Massey
Subject: RE: Bug 1391 Value type _copy_value implimentation.

In general, I like your idea ;-), but I’m not sure what latitude the user would have in implementing copy_value(). The valuetype’s operations, if any, have to be user-implemented, sure, but as for the datatypes, how many ways are there to do a deep copy? Personally, I think reference counting is much better, of course, but it seems like purely a matter of compliance. I don’t see what problems a customer would have with reference counting.

---

“Their problem with reference counting”  No idea….

Basiclaly I agree, yes it should be provided as a basic data copying item but it isn’t really possible; the user provided derived type is the only place you know which type to new  and this is in their own derived type cope not the supertypes generated by the idl compiler etc.  And if the _copy_value was corrected to be pure virtual, they would have to provide it, even if they didn’t use it themselves anyway in their own user type.   Nothing should be calling the _copy_value() of ANY of the generated or staticly provided code inside TAO so why provide it or enfore the pure virtual nature of the original CORBA spec.

---

From: Jeff Parsons [mailto:j.parsons@vanderbilt.edu] 
Sent: Wednesday, 1 May 2013 14:39
To: Simon Massey
Subject: RE: Bug 1391 Value type _copy_value implimentation.

I agree

OK there is a requirement for _copy_value to be generated in the OBV_* class under the sole conditions when the valuetype (IDL) has no (non-init) externally provided interface functions.

In this single case (basically the Valuetype simply has data accessors and possiably some factory init functions but no other external functions) the _copy_value() call needs to be generated by the IDL compiler. This needs basically to deep copy / clone the value type by newing with the default construtor (if no data is held by the valuetype) or the fully parameterised constructor (if the value type holds data).

The values of each parameter for this constructor should come from the accessors of the current valuetype's data (with any nested valuetype data elements calling their own _copy_value()).

In all other cases where the end user provides the final derived type with the implimentation of the non-init functions, they have to provide the implimentation of the _copy_value() call in their derived class themselves also.

Fri May 17 13:40:00 UTC 2013  Simon Massey  <simon dot massey at prismtech dot com>

        * NEWS:
        * TAO_IDL/be/be_visitor_valuetype/any_op_cs.cpp:
        * TAO_IDL/be/be_visitor_valuetype/valuetype_cs.cpp:
        * TAO_IDL/be/be_visitor_valuetype/valuetype_ch.cpp:
        * TAO_IDL/be/be_visitor_valuetype/valuetype_obv_ch.cpp:
        * TAO_IDL/be/be_visitor_valuetype/valuetype_obv_cs.cpp:
        * TAO_IDL/be_include/be_visitor_valuetype/valuetype_obv_cs.h:
        * tao/Valuetype/ValueBase.cpp:
        * tao/Valuetype/ValueBase.h:

          Fix for Buzilla 1391. Valuetypes now generate a _copy_value()
          method where appliciable. This is now treated as a pure
          virtual function (as per the CORBA spec). Build TAO with
          #define TAO_VALUETYPE_COPY_VALUE_IS_NOT_PURE  in effect to
          return to the previous "not required" behaviour.

        * tao/ObjRefTemplate/ObjectReferenceTemplate_i.h:
        * tao/ObjRefTemplate/ObjectReferenceTemplate_i.cpp:
        * tao/DynamicInterface/AMH_DSI_Response_Handler.cpp:
        * tao/DynamicInterface/AMH_DSI_Response_Handler.h:
        * orbsvcs/orbsvcs/LoadBalancing/LB_ObjectReferenceFactory.h:
        * orbsvcs/orbsvcs/LoadBalancing/LB_ObjectReferenceFactory.cpp:
        * DevGuideExamples/ValueTypes/Messenger/Message_i.h:
        * DevGuideExamples/ValueTypes/Messenger/Message_i.cpp:
        * DevGuideExamples/ValueTypes/Bank/client.cpp:
        * DevGuideExamples/ValueTypes/Bank/server.cpp:
        * tests/OBV/Forward/TreeController.idl:
        * tests/OBV/Truncatable/client.cpp:
        * tests/OBV/Indirection/Factory.cpp:
        * tests/OBV/Collocated/Forward/TreeController.idl:
        * tests/ORT/ObjectReferenceFactory.cpp:
        * tests/ORT/ObjectReferenceFactory.h:
        * tests/Bug_2791_Regression/Message_i.h:
        * tests/Bug_2791_Regression/Message_i.cpp:
        * examples/OBV/Typed_Events/Event_Types_impl.cpp:
        * examples/OBV/Typed_Events/Event_Types_impl.h:
        * orbsvcs/DevGuideExamples/ValueTypes/Notify/Event_i.h:
        * orbsvcs/examples/ORT/Gateway_ObjRef_Factory.cpp:
        * orbsvcs/examples/ORT/Gateway_ObjRef_Factory.h:

          Add _copy_value() implimentation where necessary in the examples
          and ensure all Valuetypes are HEAP allocated, (as all valuetypes
          are reference counted, they are required to be deletable, not
          STACK based).