Re: [Stlport-devel] patches for HP-UX/aCC
Brought to you by:
complement
From: Boris G. <Bor...@hp...> - 2006-08-16 20:03:07
|
Ulrich Eckhardt wrote: > > Now about your example I'm again not sure. The thing is that the > second foo is > clearly a function defined in namespace N, while the first foo is > in fact a > global function. Well, at least that's my understanding. So, your > example > above should compile! Let's look at the example again: namespace N { extern "C" void foo() {} void foo() {} } According to 3.5 - Program and linkage [basic.link] para 6 (attached) the second 'void foo() {}' "inherits" the extern "C" linkage from the first one, hence 'function "N::foo" has already been defined' compilation error. I've asked our C++ standard representative to verify, that 3.5 para 6 applies here (it talks about "block scope" and it was not immediately clear to us whether the intention was namespace scope also). " 3.5 - Program and linkage [basic.link] -6- The name of a function declared in block scope, and the name of an object declared by a block scope extern declaration, have linkage. If there is a visible declaration of an entity with linkage having the same name and type, ignoring entities declared outside the innermost enclosing namespace scope, the block scope declaration declares that same entity and receives the linkage of the previous declaration. If there is more than one such matching entity, the program is ill-formed. Otherwise, if no matching entity is found, the block scope entity receives external linkage. " Lippman C++ Primer, 3rd edition, p.366 states it in a more human-readable fashion: " If a function is declared more than once in the same file, the linkage directive can appear on every declaration. It can also appear only on the first declaration of the function, in which case the second and following declarations receive the linkage specified by the linkage directive on the first declaration. " Another, probably, better quote from the standard for this case is 7.5 para 5: " A function can be declared without a linkage specification after an explicit linkage specification has been seen; the linkage explicitly specified in the earlier declaration is not affected by such a function declaration. " > > The gist of the info I gleaned from clc++m was that you simply > can't put an > extern "C" function into a namespace, they are always globals. > They are globals, but you can put it in a namespace, which is what STLport does. Whether or not it makes sense to put extern "C" function in a namespace is a different question, but, technically, you can. The program below should compile cleanly and output "foo()". extern "C" int puts(const char*); namespace N { extern "C" void foo(); } namespace M { extern "C" void foo(); } extern "C" void foo() { puts("foo()"); } using namespace N; using namespace M; int main() { foo(); // no ambiguity } If you think, that the C++ standard prohibits putting an extern "C" function in a namespace or this is implementation-defined behaviour, please, send me a pointer to the relevant section of the standard. > In fact I'd rather test with the same code that STLport has, i.e. a > function > declared as extern "C" and in a namespace and another function defined > without extern "C" at the global level. If I understand things correctly, > the > declaration there matches the definition. > No, they would be different functions: the first function would be a function with a C linkage declared in a namespace scope. The second function would be a function with a C++ linkage in the global namespace. The program below should compile cleanly and output "::foo" followed by "N::foo". extern "C" int puts(const char*); namespace N { extern "C" void foo() { puts("N::foo"); } } void foo() { puts("::foo"); } int main() { foo(); N::foo(); } I don't know if Microsoft platforms have a tool like nm, but if you look at the object file, you'll see symbol "foo" for the first function and some mangled name for the second. With aCC6, it would be "_Z3foov". Without the namespace, the program above would be illegal because, as we discussed, second 'foo' would receive extern "C" linkage from the first one and you'd end up with multiple definitions of the same function. As I said in one of the previous replies, our aCC6 compiler (which is available only on ia64) is using the EDG front end (our Tru64 and OpenVMS compilers are using the EDG front end also). If you want to see how the EDG would interpret a certain language construct, you can try it on Comeau C/C++ Online Test Drive available at <http://www.comeaucomputing.com/tryitout> Comeau is EDG-based compiler and the chances are good, that our compilers will exhibit the same behaviour. We always appreciate problem reports. If you suspect, that the there is a bug in the compiler, please, send a test program to me and we'll investigate. >> This is to be consistent with how the functions are declared in >> src/c_locale.h. > > ...and therefore these declarations are bad because they are misleading. In my May patch, I've disabled namespace in the header. For aCC only, of course. In the current patch, I made the module consistent with the header. If you fix it in a general way, then, perhaps, no HP-UX-specific fix in this area will be needed. My goal was to make it work on HP-UX without affecting other platforms. Thanks, Boris Gubenko HP C/C++ team ----- Original Message ----- From: "Ulrich Eckhardt" <eck...@sa...> To: <stl...@li...> Sent: Wednesday, August 16, 2006 3:00 AM Subject: Re: [Stlport-devel] patches for HP-UX/aCC > On Tuesday 15 August 2006 19:06, Boris Gubenko wrote: >> Ulrich Eckhardt wrote: >> > 2. aCC seems to have a problem recognizing that the declared extern >> > "C" function matches the global function that gets defined[1]. Boris, >> > I would investigate if this should be silently ignored or requires a >> > diagnostic. >> > >> > [1] It is not an overload because it is in the same namespace, it is >> > just missing the extern "C" on the definition. >> >> If I understand your problem description correctly, I don't think we >> have this problem: >> >> bash-3.00$ cat x.cpp >> namespace N { >> extern "C" void foo() {} >> void foo() {} >> } >> bash-3.00$ aCC -c x.cpp >> "x.cpp", line 3: error #2247: function "N::foo" has already been defined >> void foo() {} >> ^ > > Hmmmm. Double hmmm.... > > In fact I'd rather test with the same code that STLport has, i.e. a > function > declared as extern "C" and in a namespace and another function defined > without extern "C" at the global level. If I understand things correctly, > the > declaration there matches the definition. > > Now about your example I'm again not sure. The thing is that the second > foo is > clearly a function defined in namespace N, while the first foo is in fact > a > global function. Well, at least that's my understanding. So, your example > above should compile! > >> In c_locale_dummy.c, I added conditionalization which a) puts the >> functions into namespace and b) makes them extern "C" functions. > > The gist of the info I gleaned from clc++m was that you simply can't put > an > extern "C" function into a namespace, they are always globals. > >> This is to be consistent with how the functions are declared in >> src/c_locale.h. > > ...and therefore these declarations are bad because they are misleading. > > I'll take a look at the standard and forward this second example to > clc++m, > too. > > Uli > > **************************************************** > Visit our website at <http://www.domino-printing.com/> > **************************************************** > This Email and any files transmitted with it are intended only for the > person or entity to which it is addressed and may contain confidential > and/or privileged material. Any reading, redistribution, disclosure or > other use of, or taking of any action in r > eliance upon, this information by persons or entities other than the > intended recipient is prohibited. If you are not the intended recipient > please contact the sender immediately and delete the material from your > computer. > > E-mail may be susceptible to data corruption, interception, viruses and > unauthorised amendment and Domino UK Limited does not accept liability for > any such corruption, interception, viruses or amendment or their > consequences. > **************************************************** > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Stlport-devel mailing list > Stl...@li... > https://lists.sourceforge.net/lists/listinfo/stlport-devel > > |