Issue 223:  Storage ownership issue (cxx_revision)
Source:  (, )
Nature:  Uncategorized
Severity:  MEDIUM
Summary: Summary: CORBA2.0 Care must be taken to avoid using T_var types with these extraction operators. They will try to assume responsibility for deleting storage owned by Any. Problem in mapping.

Resolution: Close with no change. That's how the mapping was designed to work.
Revised Text: In section 20.16.3 (Extraction from any), replace the sentence: 

     Care must be taken to avoid using T_var types with these extraction operators, since they will try to assume
     responsibility for deleting the storage owned by the any. 

In its place, add the following sentence: 

     An attempt to extract to a _var type is non-conforming and must cause a compile-time error. 


Actions taken:
October 14, 1996: received issue
June 13, 2000: closed issue
Discussion: 

End of Annotations:=====
This is issue # 223


CORBA2.0 Care must be taken to avoid using T_var types with these 
          extraction operators. They will try to assume responsibility for  
          deleting storage owned by Any. Problem in mapping.     


-Juergen


Date: Tue, 19 Oct 1999 17:37:58 -0400
From: Paul H Kyzivat <paulk@roguewave.com>
Organization: NobleNet
X-Mailer: Mozilla 4.0 [en] (WinNT; I)
MIME-Version: 1.0
To: Steve Vinoski <vinoski@iona.com>
CC: cxx_revision@omg.org
Subject: Re: C++ RTF Vote 1
X-Priority: 3 (Normal)
References: <4.1.19991019035709.00dc8100@mail.boston.iona.ie>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: P>@e9h_$"!+kC!!EZ2e9

Rogue Wave votes YES on all the issues in this ballot except for
Issue#223. On that one I vote no.

The issue isn't very clear, but I presume it is talking about
extracted
from an Any into any of the types that can be managed by var types,
such
as strings and object references. For these types, the mapping is
error
prone - people accustomed to using var types will be inclined to do so
in this case as well, and there will be no warnings telling them of
their mistake. Instead, the failure may come at some random time in
the
future.

It seems that something could be done to help with this. It would be
nice if we could always return const pointers or references, but there
are problems in doing so. An alternative would be to generate explicit
declarations of extraction operators with a _var type argument that
are
intentionally not implemented. E.g.

	// implemented:
	Boolean operator>>=(const Any&, char*&);

	// unimplemented:
	void operator>>=(const Any&, const String_var&);
Date: Tue, 26 Oct 1999 11:06:22 -0400
From: Paul H Kyzivat <paulk@roguewave.com>
Organization: NobleNet
X-Mailer: Mozilla 4.0 [en] (WinNT; I)
MIME-Version: 1.0
To: Steve Vinoski <vinoski@iona.com>
CC: cxx_revision@omg.org
Subject: (Counter)Proposal for Issue#223
X-Priority: 3 (Normal)
References: <4.1.19991025185441.01ae8690@mail.boston.amer.iona.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: ?*K!!TT[!!:Qj!!ElPe9

Steve Vinoski wrote:
> 
> For 223, I think it would be best to add the text regarding
> compilation errors that Paul has suggested. 
> Paul, can you make a formal counter proposal here?

Proposed Resolution:

In section 20.16.3 (Extraction from any), replace the sentence "Care
must be taken to avoid using T_var types with these extraction
operators, since they will try to assume responsibility for deleting
the
storage owned by the any". In its place, add the following sentence:

"An attempt to extract to a _var type is non-conforming and must cause
a
compile-time error."