Issue 3616: CORBA::Environment for EH compilers (cxx_revision) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: Question: Is it legal to do the following if I use a C++ mapping that uses C++ exceptions instead of using CORBA::Environment to handle errors? CORBA::Environment my_env; The spec says (page 114): The C++-PIDL specification differs from the C-PIDL specification as follows: [...] Supports a default constructor that initializes it to hold no exception information. However, the class definition that follows does *not* show the default constructor. So, the text disagrees with the class definition that is shown because "supports a default constructor" does not have a "may" or "might", so the text would appear to make the default constructor mandatory for *both* EH and non-EH mappings. Resolution: Revised Text: Actions taken: May 16, 2000: received issue Discussion: deferred in June 2011 to the next RTF End of Annotations:===== Date: Tue, 16 May 2000 10:00:27 +1000 (EST) From: Michi Henning Reply-To: C++ Revision Task Force To: C++ Revision Task Force cc: issues@omg.org Subject: CORBA::Environment for EH compilers Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: n7:e9#'_d9$JJe9f<]d9 Question: Is it legal to do the following if I use a C++ mapping that uses C++ exceptions instead of using CORBA::Environment to handle errors? CORBA::Environment my_env; The spec says (page 114): The C++-PIDL specification differs from the C-PIDL specification as follows: [...] Supports a default constructor that initializes it to hold no exception information. However, the class definition that follows does *not* show the default constructor. So, the text disagrees with the class definition that is shown because "supports a default constructor" does not have a "may" or "might", so the text would appear to make the default constructor mandatory for *both* EH and non-EH mappings. Page 127: Added create_environment. Unlike the struct version, Environment requires a construction operation. (Since this is overly constraining for implementations that do not support real C++ exceptions, these implementations may allow Environment to be declared on the stack. See Section 1.42.2, Without Exception Handling, on page 1-169 for details.) >From this, I read that the default constructor was intended to be provided only for non-EH environments, and even then, it is optional. ("... *may* allow Environment to be declared on the stack...") This in itself is bad because I don't have a guarantee that I can (in a non-EH environment) declare a stack Environment variable, so I can't write portable code. But it's also in conflict with the text on page 114, which unconditionally requires the default constructor to be present. Page 170: Section 1.33, ORB, on page 1-125 specifies that Environment must be created using ORB::create_environment, but this is overly constraining for implementations requiring an Environment to be passed as an argument to each method invocation. For implementations that do not support real C++ exceptions, Environment may be allocated as a static, automatic, or heap variable. For example, all of the following are legal declarations on a non-EH C++ environment: Here it says that that "for implementations that do not support real C++ exceptions", Environment *may* be allocated as a static, etc... This is not consistent, because the final sentence then (without qualification) says that "... the following *are legal* declarations on a non-EH C++ environment." The problem is that none of this really says anything about what must happen for EH environments. In addition, even for non-EH environments, it provides no useful guarantee. My opinion is that, for EH environments, allowing Environment to be instantiated without calling ORB::create_environment() should be made illegal, and CORBA::Environment should not have a default constructor. The reasons for this opinion are - consistency: all other pseudo-objects require a factory call - implementation issues: it's a proper mess to ensure that I can safely instantiate this things at a time when the ORB is not initialized yet, and that I can tear them down again safely if the ORB is destroyed already - semantic problems: without a factory call, it's not clear what ORB instance the environment is associated with if I use multiple ORBs. This may not be much of an issue right now, but could become one eventually, as we get more fancy with what I can do with multiple ORBs. For non-EH mappings (are there still any left?), I think that the default constructor *must* be supported, otherwise portability isn't guaranteed. (But, personally, I don't care much about non-EH mappings anymore -- they are rapidly becoming obsolete.) Opinions? Cheers, Michi. X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 15 May 2000 20:39:30 -0400 To: C++ Revision Task Force From: Steve Vinoski Subject: Re: CORBA::Environment for EH compilers In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: ?@_d9A$!e98b^!!mnl!! At 10:00 AM 5/16/00 +1000, Michi Henning wrote: My opinion is that, for EH environments, allowing Environment to be instantiated without calling ORB::create_environment() should be made illegal, and CORBA::Environment should not have a default constructor. This was precisely the original intent. --steve Date: Tue, 16 May 2000 11:05:00 +1000 (EST) From: Michi Henning To: Steve Vinoski cc: C++ Revision Task Force Subject: Re: CORBA::Environment for EH compilers In-Reply-To: <4.3.2.20000515203850.0218d300@mail.boston.amer.iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ZBid9LNid9&L-e9_^2!! On Mon, 15 May 2000, Steve Vinoski wrote: > At 10:00 AM 5/16/00 +1000, Michi Henning wrote: > >My opinion is that, for EH environments, allowing Environment to be > >instantiated without calling ORB::create_environment() should be made > >illegal, and CORBA::Environment should not have a default constructor. > > This was precisely the original intent. I thought so too. What about non-EH environments? *Must* a non-EH mapping allow instatiating an Environment variable directly? Or was that meant to be optional? (If it's optional, it's a little bit hard to see how it would be useful for writing portable code.) On the other hand, if I'm in a non-EH mapping, and call ORB::create_environment(), I get a _ptr reference back. However, the signature for operations accepts a parameter of type Environment &. So, how can I use an environment that is obtained from create_environment() to make an operation invocation? The following is dubious: CORBA::Environment_ptr ev_ptr = CORBA::Environment::_nil(); orb->create_environment(ev_ptr); foo_reference->some_op(*ev_ptr); // Dubious!!! How do I get from the reference (Environment_ptr) to the servant (Environment)? Dereferencing the _ptr reference is not something that's allowed now, is it? (Because _ptr references may not be C++ pointers and a * operator need not be supported, yes?) All this would indicate that, for non-EH mappings, I *must* use a directly instantiated Environment if I invoke an operation, and that I cannot use an Environment obtained from create_environment(), because that would be non-portable. Correct? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 17 May 2000 17:27:44 -0400 To: Michi Henning From: Steve Vinoski Subject: Re: CORBA::Environment for EH compilers Cc: C++ Revision Task Force In-Reply-To: References: <4.3.2.20000515203850.0218d300@mail.boston.amer.iona.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: 9$Pe989k!!&ZOe9jiWd9 At 11:05 AM 5/16/00 +1000, Michi Henning wrote: On Mon, 15 May 2000, Steve Vinoski wrote: > At 10:00 AM 5/16/00 +1000, Michi Henning wrote: > >My opinion is that, for EH environments, allowing Environment to be > >instantiated without calling ORB::create_environment() should be made > >illegal, and CORBA::Environment should not have a default constructor. > > This was precisely the original intent. I thought so too. What about non-EH environments? *Must* a non-EH mapping allow instatiating an Environment variable directly? Or was that meant to be optional? (If it's optional, it's a little bit hard to see how it would be useful for writing portable code.) No, it was intended to be mandatory. On the other hand, if I'm in a non-EH mapping, and call ORB::create_environment(), I get a _ptr reference back. However, the signature for operations accepts a parameter of type Environment &. So, how can I use an environment that is obtained from create_environment() to make an operation invocation? The following is dubious: CORBA::Environment_ptr ev_ptr = CORBA::Environment::_nil(); orb->create_environment(ev_ptr); foo_reference->some_op(*ev_ptr); // Dubious!!! How do I get from the reference (Environment_ptr) to the servant (Environment)? Dereferencing the _ptr reference is not something that's allowed now, is it? (Because _ptr references may not be C++ pointers and a * operator need not be supported, yes?) All this would indicate that, for non-EH mappings, I *must* use a directly instantiated Environment if I invoke an operation, and that I cannot use an Environment obtained from create_environment(), because that would be non-portable. Correct? All correct. --steve