Discussion:
[omniORB] IDL : parameter clashes with identifier
Nicolas Olivier
2009-10-20 15:48:14 UTC
Permalink
Hello,

I encounter an error parsing an idl on the following declaration :

void getMLSNPP(
in globaldefs::NamingAttributes_T mLSNPPName,
out mLSNPP::MultiLayerSNPP_T mLSNPP)
raises(globaldefs::ProcessingFailureException);

The error is :
Declaration of parameter 'mLSNPP' clashes with use of identifier 'mLSNPP'

I've read in the FAQ that two identifiers must differ in case, but in
this declaration, mLSNPP is a scope, and MultiLayerSNPP_T is, from my
point of view, the identifier.

Is it really the behaviour expected, in case I fix the idl ?

omniORB used is 4.1.4

Regards
Duncan Grisby
2009-10-20 17:11:05 UTC
Permalink
Post by Nicolas Olivier
void getMLSNPP(
in globaldefs::NamingAttributes_T mLSNPPName,
out mLSNPP::MultiLayerSNPP_T mLSNPP)
raises(globaldefs::ProcessingFailureException);
Declaration of parameter 'mLSNPP' clashes with use of identifier 'mLSNPP'
I've read in the FAQ that two identifiers must differ in case, but in
this declaration, mLSNPP is a scope, and MultiLayerSNPP_T is, from my
point of view, the identifier.
Is it really the behaviour expected, in case I fix the idl ?
Yes, it's expected, and omniidl is correct in saying your IDL is
invalid. Section 3.15.2 of the CORBA 2.6 spec says:

-----
An identifier from a surrounding scope is introduced into a scope if it
is used in that scope. An identifier is not introduced into a scope by
merely being visible in that scope. The use of a scoped name introduces
the identifier of the outermost scope of the scoped name. For example
in:

module M {
module Inner1 {
typedef string S1;
};
module Inner2 {
typedef string inner1; // OK
};
}

The declaration of Inner2::inner1 is OK because the identifier Inner1,
while visible in module Inner2, has not been introduced into module
Inner2 by actual use of it. On the other hand, if module Inner2 were:

module Inner2{
typedef Inner1::S1 S2; // Inner1 introduced
typedef string inner1; // Error
typedef string S1; // OK
};

The definition of inner1 is now an error because the identifier Inner1
referring to the module Inner1 has been introduced in the scope of
module Inner2 in the first line of the module declaration. Also, the
declaration of S1 in the last line is OK since the identifier S1 was not
introduced into the scope by the use of Inner1::S1 in the first line.

Only the first identifier in a qualified name is introduced into the
current scope. This is illustrated by Inner1::S1 in the example above,
which introduces "Inner1" into the scope of "Inner2" but does not
introduce "S1." A qualified name of the form "::X::Y::Z" does not cause
"X" to be introduced, but a qualified name of the form "X::Y::Z" does.
-----


Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --
Nicolas Olivier
2009-10-20 17:30:11 UTC
Permalink
Post by Duncan Grisby
Post by Nicolas Olivier
void getMLSNPP(
? in globaldefs::NamingAttributes_T mLSNPPName,
? out mLSNPP::MultiLayerSNPP_T mLSNPP)
?raises(globaldefs::ProcessingFailureException);
Declaration of parameter 'mLSNPP' clashes with use of identifier 'mLSNPP'
I've read in the FAQ that two identifiers must differ in case, but in
this declaration, mLSNPP is a scope, and MultiLayerSNPP_T is, from my
point of view, the identifier.
Is it really the behaviour expected, in case I fix the idl ?
Yes, it's expected, and omniidl is correct in saying your IDL is
-----
An identifier from a surrounding scope is introduced into a scope if it
is used in that scope. An identifier is not introduced into a scope by
merely being visible in that scope. The use of a scoped name introduces
the identifier of the outermost scope of the scoped name. For example
module M {
? ? ?module Inner1 {
? ? ? ? ?typedef string S1;
? ? ?};
? ? ?module Inner2 {
? ? ? ? ?typedef string inner1; ? ? ? ? ? ?// OK
? ? ?};
}
The declaration of Inner2::inner1 is OK because the identifier Inner1,
while visible in module Inner2, has not been introduced into module
module Inner2{
? ? ?typedef Inner1::S1 S2; ? ? ? ? ? // Inner1 introduced
? ? ?typedef string inner1; ? ? ? ? ? // Error
? ? ?typedef string S1; ? ? ? ? ? ? ? // OK
};
The definition of inner1 is now an error because the identifier Inner1
referring to the module Inner1 has been introduced in the scope of
module Inner2 in the first line of the module declaration. Also, the
declaration of S1 in the last line is OK since the identifier S1 was not
introduced into the scope by the use of Inner1::S1 in the first line.
Only the first identifier in a qualified name is introduced into the
current scope. This is illustrated by Inner1::S1 in the example above,
which introduces "Inner1" into the scope of "Inner2" but does not
introduce "S1." A qualified name of the form "::X::Y::Z" does not cause
"X" to be introduced, but a qualified name of the form "X::Y::Z" does.
-----
Cheers,
Duncan.
--
?-- Duncan Grisby ? ? ? ? --
? -- http://www.grisby.org --
Ok, thanks for the quick answer.

Regards,
Nikolas

Loading...