* pragma import ambiguity @ 2006-09-06 16:05 tmoran 2006-09-06 16:39 ` bubble 2006-09-06 17:34 ` Frank J. Lhota 0 siblings, 2 replies; 10+ messages in thread From: tmoran @ 2006-09-06 16:05 UTC (permalink / raw) One Ada compiler accepts this, another doesn't. I agree with the one that objects. Are we wrong? procedure testimp is type logicopenm is ( clear, gl_and); procedure clear(mask:integer); pragma import(stdcall,clear,"glclear"); begin null; end testimp; ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pragma import ambiguity 2006-09-06 16:05 pragma import ambiguity tmoran @ 2006-09-06 16:39 ` bubble 2006-09-06 16:42 ` bubble ` (2 more replies) 2006-09-06 17:34 ` Frank J. Lhota 1 sibling, 3 replies; 10+ messages in thread From: bubble @ 2006-09-06 16:39 UTC (permalink / raw) are you mean there are the same name symbols in a library? I assume your library is standard winapi and writing in C not C++. the C++ have name decoration problem to avoid the name decoration problem you "may" use external "C" to solve it. like #ifdef __cplusplus external "{" #end if __declspec(dllexport) int clear; int __declspec(dllexport) __stdcall clear(); #ifdef __cplusplus } end if I think your C/C++ compiler should allow to compiler it because C does not allow the same name in code. another way. you should create a def file and there are alias names in it. tmoran@acm.org 寫道: > One Ada compiler accepts this, another doesn't. I agree with the one that > objects. Are we wrong? > procedure testimp is > type logicopenm is ( clear, gl_and); > procedure clear(mask:integer); > pragma import(stdcall,clear,"glclear"); > begin > null; > end testimp; ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pragma import ambiguity 2006-09-06 16:39 ` bubble @ 2006-09-06 16:42 ` bubble 2006-09-06 17:47 ` Pascal Obry 2006-09-21 1:26 ` Dave Thompson 2 siblings, 0 replies; 10+ messages in thread From: bubble @ 2006-09-06 16:42 UTC (permalink / raw) I think your C/C++ compiler should "NOT" allow to compiler it because C does not allow the same name in code. sorry missing "NOT". bubble 寫道: > are you mean there are the same name symbols in a library? > > I assume your library is standard winapi and writing in C not C++. > the C++ have name decoration problem > to avoid the name decoration problem > > you "may" use external "C" to solve it. > > like > > #ifdef __cplusplus > external "{" > #end if > __declspec(dllexport) int clear; > int __declspec(dllexport) __stdcall clear(); > > > #ifdef __cplusplus > } > end if > > I think your C/C++ compiler should allow to compiler it because C does > not allow the same name in code. > > > > another way. > you should create a def file and there are alias names in it. > > > > > > tmoran@acm.org 寫道: > > > One Ada compiler accepts this, another doesn't. I agree with the one that > > objects. Are we wrong? > > procedure testimp is > > type logicopenm is ( clear, gl_and); > > procedure clear(mask:integer); > > pragma import(stdcall,clear,"glclear"); > > begin > > null; > > end testimp; ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pragma import ambiguity 2006-09-06 16:39 ` bubble 2006-09-06 16:42 ` bubble @ 2006-09-06 17:47 ` Pascal Obry 2006-09-21 1:26 ` Dave Thompson 2 siblings, 0 replies; 10+ messages in thread From: Pascal Obry @ 2006-09-06 17:47 UTC (permalink / raw) To: bubble bubble a écrit : > are you mean there are the same name symbols in a library? ... I think you got this wrong. The OP problem is that Clear is a procedure and also a value of the enumerated type logicopenm. I think the program is ok. A pragma import takes a local_name and this can't be an enumeration_literal_specification. So the clear in the pragma import is not ambigus as it can only apply to the procedure Clear. Now it is said in RM 3.5.1(11): << When called, the parameterless function associated with an enumeration literal returns the corresponding value of the enumeration type. >> But I don't think this implicit function should be taken into account here. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pragma import ambiguity 2006-09-06 16:39 ` bubble 2006-09-06 16:42 ` bubble 2006-09-06 17:47 ` Pascal Obry @ 2006-09-21 1:26 ` Dave Thompson 2 siblings, 0 replies; 10+ messages in thread From: Dave Thompson @ 2006-09-21 1:26 UTC (permalink / raw) On 6 Sep 2006 09:39:30 -0700, "bubble" <kuan_long@hotmail.com> wrote: (topposted, not worth the trouble of correcting) > are you mean there are the same name symbols in a library? > > I assume your library is standard winapi and writing in C not C++. > the C++ have name decoration problem > to avoid the name decoration problem > This wasn't the OP's problem (which was within the Ada) and he(WLOG) didn't say anything to indicate he is using C++. But even if so: > you "may" use external "C" to solve it. > > like > > #ifdef __cplusplus > external "{" extern "C" { > #end if #endif > __declspec(dllexport) int clear; > int __declspec(dllexport) __stdcall clear(); > Non-standard Windows-only; but the OP _did_ imply Windows. > > #ifdef __cplusplus > } > end if > #endif > I think your C/C++ compiler should allow to compiler it because C does > not allow the same name in code. > Neither does C++ when using extern "C", formally called C linkage. And even in "real C++", you can't have both a function/routine and variable with the same name in the same namespace; overloading only works among function/routines, not for variables or typenames. - David.Thompson1 at worldnet.att.net ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pragma import ambiguity 2006-09-06 16:05 pragma import ambiguity tmoran 2006-09-06 16:39 ` bubble @ 2006-09-06 17:34 ` Frank J. Lhota 2006-09-06 18:06 ` Gautier ` (2 more replies) 1 sibling, 3 replies; 10+ messages in thread From: Frank J. Lhota @ 2006-09-06 17:34 UTC (permalink / raw) tmoran@acm.org wrote: > One Ada compiler accepts this, another doesn't. I agree with the one that > objects. Are we wrong? > procedure testimp is > type logicopenm is ( clear, gl_and); > procedure clear(mask:integer); > pragma import(stdcall,clear,"glclear"); > begin > null; > end testimp; This is a tough call. Technically, an enumeration literal such as "clear" in type logicopenm is ( clear, gl_and); is an implicit, parameterless function. Section B.1 of the ARM states "If the local_name denotes more than one entity, then the pragma Import is the completion of all of them", so one could argue that the import clause imports a subprogram for *both* the clear procedure and the enumeration literal. This is clearly not possible: the "clear" enumeration literal must be implicit. Of course, one may argue that B.1 should not apply to enumeration literals, but even so, this kind of overloading is not recommended. My advice would be to give the enumeration literal and the procedure separate names. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pragma import ambiguity 2006-09-06 17:34 ` Frank J. Lhota @ 2006-09-06 18:06 ` Gautier 2006-09-07 7:53 ` Dmitry A. Kazakov 2006-09-07 19:35 ` Adam Beneschan 2 siblings, 0 replies; 10+ messages in thread From: Gautier @ 2006-09-06 18:06 UTC (permalink / raw) Frank J. Lhota: > My advice would be to give the enumeration literal and the > procedure separate names. And when not possible, the workaround is (marked *): procedure testimp is type logicopenm is ( clear, gl_and); procedure clear(mask:integer); procedure glClear(mask:integer); procedure clear(mask:integer) renames glClear; -- * pragma import(stdcall,glClear,"glclear"); -- * begin null; end testimp; ______________________________________________________________ Gautier -- http://www.mysunrise.ch/users/gdm/index.htm Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm NB: For a direct answer, e-mail address on the Web site! ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pragma import ambiguity 2006-09-06 17:34 ` Frank J. Lhota 2006-09-06 18:06 ` Gautier @ 2006-09-07 7:53 ` Dmitry A. Kazakov 2006-09-07 19:35 ` Adam Beneschan 2 siblings, 0 replies; 10+ messages in thread From: Dmitry A. Kazakov @ 2006-09-07 7:53 UTC (permalink / raw) On Wed, 06 Sep 2006 13:34:27 -0400, Frank J. Lhota wrote: > tmoran@acm.org wrote: >> One Ada compiler accepts this, another doesn't. I agree with the one that >> objects. Are we wrong? >> procedure testimp is >> type logicopenm is ( clear, gl_and); >> procedure clear(mask:integer); >> pragma import(stdcall,clear,"glclear"); >> begin >> null; >> end testimp; > > Of course, one may argue that B.1 should not apply to enumeration > literals, but even so, this kind of overloading is not recommended. My > advice would be to give the enumeration literal and the procedure > separate names. procedure Testimp is procedure Clear (mask:integer); pragma Import (stdcall, clear, "glclear"); type logicopenm is (clear, gl_and); begin null; end Testimp; -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pragma import ambiguity 2006-09-06 17:34 ` Frank J. Lhota 2006-09-06 18:06 ` Gautier 2006-09-07 7:53 ` Dmitry A. Kazakov @ 2006-09-07 19:35 ` Adam Beneschan 2006-09-08 3:48 ` Randy Brukardt 2 siblings, 1 reply; 10+ messages in thread From: Adam Beneschan @ 2006-09-07 19:35 UTC (permalink / raw) Frank J. Lhota wrote: > tmoran@acm.org wrote: > > One Ada compiler accepts this, another doesn't. I agree with the one that > > objects. Are we wrong? > > procedure testimp is > > type logicopenm is ( clear, gl_and); > > procedure clear(mask:integer); > > pragma import(stdcall,clear,"glclear"); > > begin > > null; > > end testimp; > > This is a tough call. Technically, an enumeration literal such as "clear" in > > type logicopenm is ( clear, gl_and); > > is an implicit, parameterless function. Section B.1 of the ARM states > "If the local_name denotes more than one entity, then the pragma Import > is the completion of all of them", so one could argue that the import > clause imports a subprogram for *both* the clear procedure and the > enumeration literal. This is clearly not possible: the "clear" > enumeration literal must be implicit. Not quite; 3.5.1(6) says that the declaration of "clear" is explicit. This makes a difference because of 3.11.1, which says that implicit declarations may not have completions, but completions are allowed "in principle" for any kind of explicit declaration, but only if there is an implementation for that sort of declaration (B.1(22)). Also, 6.3.1 says that the function declaration that arises from the enumeration literal declaration has a default calling convention of Intrinsic, but it also says that default calling conventions can be overridden, although I can't see how it could make sense to override the default calling convention for an enumeration literal, or for that matter most or all of the other types of subprograms whose default calling convention is Intrinsic. So I'm not sure why the language allows this "in principle". Anyway, the language isn't clear on whether Import can be applied to an enumeration literal. I do believe, though, that it would be wrong for a compiler to reject this: type logicopennm is (clear, gl_and); pragma import (stdcall, clear, "glclear"); when there's no overloading involved, but to accept the same pragma when it can be applied both to a subprogram named "clear" and to the enumeration literal. The language does say that Import is the completion of all entities denoted by the name, and if such a completion is illegal for any denoted entity, then the compiler has to reject the pragma. -- Adam ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: pragma import ambiguity 2006-09-07 19:35 ` Adam Beneschan @ 2006-09-08 3:48 ` Randy Brukardt 0 siblings, 0 replies; 10+ messages in thread From: Randy Brukardt @ 2006-09-08 3:48 UTC (permalink / raw) "Adam Beneschan" <adam@irvine.com> wrote in message news:1157657721.734036.128160@h48g2000cwc.googlegroups.com... > Also, 6.3.1 > says that the function declaration that arises from the enumeration > literal declaration has a default calling convention of Intrinsic, but > it also says that default calling conventions can be overridden, > although I can't see how it could make sense to override the default > calling convention for an enumeration literal, or for that matter most > or all of the other types of subprograms whose default calling > convention is Intrinsic. So I'm not sure why the language allows this > "in principle". Probably because there are Intrinsic routines where it does make sense to override the calling convention (i.e. inherited routines). > Anyway, the language isn't clear on whether Import can be applied to an enumeration literal. My understanding is that the intent is that the language allows Import/Export to be applied to *any* entity. The theory being that we didn't want to predict what we might be able to interface with in the future. For instance, it might make sense to Import an exception on some implementations (say, if C++ and Ada exceptions are implemented the same way). Similarly, it might make sense to import literal values from another language, so I suppose it could mean something somewhere. But of course, these pragmas are required to work only for limited set of entities, and enumeration literals isn't one of them. > I do believe, though, that it would be wrong for a compiler to reject this: > > type logicopennm is (clear, gl_and); > pragma import (stdcall, clear, "glclear"); > > when there's no overloading involved, but to accept the same pragma > when it can be applied both to a subprogram named "clear" and to the > enumeration literal. The language does say that Import is the > completion of all entities denoted by the name, and if such a > completion is illegal for any denoted entity, then the compiler has to > reject the pragma. I agree with this. Randy. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2006-09-21 1:26 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-09-06 16:05 pragma import ambiguity tmoran 2006-09-06 16:39 ` bubble 2006-09-06 16:42 ` bubble 2006-09-06 17:47 ` Pascal Obry 2006-09-21 1:26 ` Dave Thompson 2006-09-06 17:34 ` Frank J. Lhota 2006-09-06 18:06 ` Gautier 2006-09-07 7:53 ` Dmitry A. Kazakov 2006-09-07 19:35 ` Adam Beneschan 2006-09-08 3:48 ` Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox