Hi Pete, 

I entered Jira's for the remaining issue I raised (listed below). I
think we will be able to contribute some patches as well.

Thanks,

Michael

TUSCANY-1370 - C++ SDO spec compliance/portability: DataObject
TUSCANY-1371 - C++ SDO spec compliance/portability:
DataObject::getInstanceProperty(const std::string& prop)
TUSCANY-1372 - C++ SDO spec compliance/portability: DataFactory
TUSCANY-1373 - C++ SDO spec compliance/portability:
DataFactory::setDefault
TUSCANY-1374 - C++ SDO spec portability: DataObjectInstance
TUSCANY-1375 - C++ SDO spec portability: C++ type definition API
TUSCANY-1376 - C++ SDO spec portability: RefCountingPointer
 

-----Original Message-----
From: Pete Robbins [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 22, 2007 6:16 AM
To: [email protected]
Subject: Re: C++ SDO spec portability: RefCountingPointer

Michael, I strongly suspect that the operator T*() ws put in for a good
reason. It may be a good idea to remove this but it may be non-trivial.

The ostream operator << is very useful and there is a default
implementation in RefCountingObject so that objects inheriting from
RefCounting object do not need to implement anything... but they can if
appropriate.

You are raising a lot if issues which is great and it would be excellent
to get Tuscany SDO up to 2.1 spec level. I suspect there will be
hundreds of issues some of which may require large re-writes/refactoring
of the Tuscany SDO Code!! Raising these as Jiras is the best thing to do
so we can track them. Helping fix them by submitting patches would be
even better ;-)

Cheers,

On 22/06/07, Michael Yoder <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> In looking at C++ SDO portabilty, we found the the Tuscany C++ SDO 
> class RefCountingPointer has functions used externally by SCA:
>
>        operator T*() {return pointee;}
>        friend std::ostream& operator<< (std::ostream &os, const 
> RefCountingPointer<T>& ptr)
>
> It looks like the conversion to T* function may have been put in 
> originally as a porting alternative to a member function template, but

> may not be needed any more since the member template is now included 
> outside the #ifdef.
>
> Exposing the dumb pointer is undesirable since it raises object 
> lifetime issues and allows other unwanted operations. Having a 
> conversion to bool is convenient however, and can be implemented 
> safely using a member function pointer trick (see:
> http://www.artima.com/cppsource/safebool.html).
>
> The shift operator also seems undesireable since it places a burden on

> all classes which use smart pointers to implement toString 
> functionality.
>
> How does it sound to raise a Jira to have these member functions 
> removed?
>
> Thanks,
> Michael Yoder
> Rogue Wave Software - [EMAIL PROTECTED] Software Developer - 
> HydraSDO
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Pete

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to