[omniORB] nested modules and string constants in MSVC++

[Daniel Bell]

Hi,

This is a followup to my original message. I've checked my copy of the C++
standard and I'm pretty sure that the C++ produced by omniidl (Win32,
v3.0.2) is syntactically incorrect (see below in my original message). I
think I've also found where this code is produced in the python code,
namely: 

	lib/python/omniidl_be/cxx/dynskel/typecode.py
	lib/python/omniidl_be/cxx/dynskel/template.py

Firstly, let me state that I HAVE NO KNOWLEDGE OF PYTHON!

It seems that there is an output format specifier in template.py:

	external_linkage = """\
	#if defined(HAS_Cplusplus_Namespace) && defined(_MSC_VER)
	// MSVC++ does not give the constant external linkage otherwise.
	@namespace@
	namespace @scope@ {
	  const CORBA::TypeCode_ptr @tc_unscoped_name@ = @mangled_name@;
	}
	#else
	const CORBA::TypeCode_ptr @tc_name@ = @mangled_name@;
	#endif
	"""

The corresponding external_linkage function is defined in typecode.py, lines
221-270 (I think).

My question is, how to change the python code to produce output of the form:

	namespace A { namespace B { .... }}

instead of 
	
	namespace A::B { .... }

as is being produced currently (and I believe is illegal C++ code).


Thanks,
Daniel


> -----Original Message-----
> I believe I've just come across a bug with nested modules and string
> constants in MSVC++. Consider the following bit of IDL:
> 
> module outer
> {
> 	module inner
> 	{
> 		const string STRING_CONST = "the value";
> 	};
> };
> 
> In the .cpp file produced, the C++ for the initialisation fo 
> the string
> constant is: 
> 
> #if defined(HAS_Cplusplus_Namespace) && defined(_MSC_VER)
> // MSVC++ does not give the constant external linkage othewise.
> namespace outer::inner {
>   extern const char * STRING_CONST="the value";
> }
> #else
> const char * outer::inner::STRING_CONST = "the value";
> #endif
> 
> MSVC++ doesn't like the "namespace outer::inner". However, if this is
> changed to nested namespace calls (ie. namespace outer { 
> namespace inner {
> ... } }), then this works fine.
> 
> Is this a bug or am I missing something? 
> 
> Daniel
> 
> - Daniel Bell
> - Software Engineer, Colorbus Pty Ltd
> - Email: daniel.bell@colorbus.com.au
> - Phone: 61 3 8574 8035
> - WWW:   http://www.colorbus.com
>  
>