Issue 269:  Default constructor for String_var (cxx_revision)
Source:  (, )
Nature:  ENHANCEMENT
Severity:  Medium
Summary: Summary: C++ mapping currently specifies that the default constructor for CORBA::String_var initializes the string to NULL Pointer. This is very inconvenient, in particular for structures

Resolution:  Fixed as suggested by submitter
Revised Text: 
Actions taken:
October 17, 1996: received issue
February 19, 1999: closed issue
Discussion: 

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

Title:    Default constructor for String_var 

Desc: C++ mapping currently specifies that the default constructor for  
          CORBA::String_var initializes the string to NULL Pointer. This is 
          very inconvenient, in particular for structures                   
                                                          
From michi@dstc.edu.au  Thu Oct 17 02:50:42 1996
Received: from trapdoor.dstc.edu.au by amethyst.omg.org.omg.org
(5.4R2.01/1.34)
	id AA08099; Thu, 17 Oct 1996 02:50:42 -0400
Received: from foxtail.dstc.edu.au (foxtail.dstc.edu.au [130.102.176.14]) by
trapdoor.dstc.edu.au (8.6.9/8.6.12) with ESMTP id QAA23574 for
<cxx_revision@omg.org>; Thu, 17 Oct 1996 16:46:58 +1000
Received: (from michi@localhost) by foxtail.dstc.edu.au (8.6.10/8.6.10) id
QAA25084 for cxx_revision@omg.org; Thu, 17 Oct 1996 16:46:58 +1000
From: Michi Henning <michi@dstc.edu.au>
Message-Id: <199610170646.QAA25084@foxtail.dstc.edu.au>
Subject: Default constructor for String_var
To: cxx_revision@omg.org
Date: Thu, 17 Oct 1996 16:46:57 +1000 (EST)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2630      

Hi,

The C++ mapping currently specifies that the default constructor for
CORBA::String_var initializes the string to the NULL pointer (page 16-14):

	"The default constructor creates a T_var containing a null T*."

This is very inconvenient, in particular for structures. Consider the
following IDL:

struct mystruct {
	String	s1;
	String	s2;
	String	s3;
};

interface myinterface {
	void	f(inout mystruct ms);
};

In C++, to legally pass a structure to the operation, I cannot simply
declare a variable of type mystruct and use it, because the string members
inside the structure behave like _var types. In other words, after
declaring the struct, all the string members are NULL. I first have
to initialize the three string members:

	mystruct s;
	s.s1 = (const char *)"";	// Mandatory
	s.s2 = (const char *)"";	// Mandatory
	s.s3 = (const char *)"";	// Mandatory

	myinterface_reference->f(s);

This is really inconvenient, not just for structures, but also for
plain String_var variables, sequences of strings, etc.

Quite often, I don't care about the value. However, I can't legally pass
a NULL pointer across an interface, so I'm forced to initialize all
String_vars. One example where this happens is in the Naming Service.

Each name has both an id and a kind field. However, many applications
are not interested in using the kind field, yet they are still forced
to set them to the empty string explicitly every time.

Considering that an objref_var *guarantees* intialization to the nil
reference by the default constructor, why can't we guarantee initialization
of String_var to the empty string?

I really would like to see this changed. As far as I can see, the new
behaviour would not break any existing applications (because it is
currently illegal to access an uninitialized String_var). The change
would also be trivial to implement and cause a negligible efficiency hit.

In particular, initialization does not need to allocate an empty string.
Instead, make all String_var instances that are default-constructed point
at the same static empty string, and change string_free to avoid freeing
anything if a String_var points at the static empty string.

Is there something I am missing? If there is some subtle reason why this
is not a good idea, could someone please let me know? If there *is* a
subtle reason, could we please at least document it in the spec?


						Thanks,

							Michi.
-- 
Michi Henning              +61 7 33654310
DSTC Pty Ltd               +61 7 33654311 (fax)
University of Qld 4072     michi@dstc.edu.au
AUSTRALIA                  http://www.dstc.edu.au/BDU/staff/michi-henning.html