Jason Merrill wrote:
> Hmm, I'm starting to be convinced that ignoring #pragma visibility for
> all template instantiations and specializations will be a simpler rule
> for users to understand.
I think I argued for that earlier; in any case, I agree.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTE
Hmm, I'm starting to be convinced that ignoring #pragma visibility for
all template instantiations and specializations will be a simpler rule
for users to understand. So the #pragma affects namespace-scope
declarations, but not declarations that in any sense "belong" to another
namespace-scope
On Wed, Jun 28, 2006 at 10:24:27PM -0400, Geoffrey Keating wrote:
> Suppose a library template has (my syntax may not be quite right):
>
> template struct foo __attribute__((visibility("default"))) {
> static T my_var;
> T inc (T x) { return my_var += x; }
> };
>
> The intention is that all
On 28/06/2006, at 2:21 PM, Jason Merrill wrote:
Geoffrey Keating wrote:
[#pragma visibility affecting explicit instantiations]
A consequence of this is that if a user instantiates a template that
they don't 'own' (that is, a template from a different module), they
must make sure that no #pra
Geoffrey Keating wrote:
[#pragma visibility affecting explicit instantiations]
A consequence of this is that if a user instantiates a template that
they don't 'own' (that is, a template from a different module), they
must make sure that no #pragma is in effect, because the other module
may hav
Geoffrey Keating wrote:
> In the traditional declaration/definition model, if you try to change
> the linkage of something you get an error...
Indeed, if you consider visibility to be an intrinsic property of the
template (like its type, say), you could argue:
(1) the template gets to specify th
Jason Merrill <[EMAIL PROTECTED]> writes:
> Gabriel Dos Reis wrote:
> > Mark Mitchell <[EMAIL PROTECTED]> writes:
> > | I'm just not comfortable with the idea of #pragmas affecting
> > | instantiations. (I'm OK with them affecting specializations, though; in
> > | that case, the original template
Jason Merrill wrote:
> Yep. I'm sympathetic to Mark's position, but still tend to believe that
> the #pragma should affect explicit instantiations.
I don't feel strongly enough to care; let's do make sure, however, that
we clearly document the precedence, so that people know what to expect.
Tha
Gabriel Dos Reis wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
| I'm just not comfortable with the idea of #pragmas affecting
| instantiations. (I'm OK with them affecting specializations, though; in
| that case, the original template has basically no impact, so I think
| it's fine to treat t
Mark Mitchell <[EMAIL PROTECTED]> writes:
[...]
| And, "extern template" is a GNU
| extension which says "there's an explicit instantiation elsewhere; you
| needn't bother implicitly instantiating here".
FWIW, "extern template" is now part of C++0x.
| I'm
Ian Lance Taylor wrote:
> Don't you still have to deal with this case?
>
> #pragma GCC visibility push(hidden)
> template T f(T);
> #pragma GCC visibility pop
> ...
> #pragma GCC visibility push(default)
> extern template int f(int);
> #pragma GCC visibility pop
>
> Personally I wouldn't mind sa
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Jason Merrill wrote:
> > Now, templates:
> >
> > template __attribute((visibility ("hidden")) T f(T);
> > #pragma GCC visibility push(default)
> > extern template int f(int);
> > #pragma GCC visibility pop
> >
> > This could really go either wa
Jason Merrill wrote:
Nice to see this stuff getting improved!
> #pragma GCC visibility push(hidden)
> class __attribute((visibility("default"))) A
> {
> void f ();
> };
>
> void A::f() { }
>
> Here I think we'd all agree that f should get default visibility.
Agreed.
> class A
I'm currently working on a massive overhaul of the visibility code to
make it play nice with C++. One of the issues I've run into is the
question of priority of #pragma visibility versus other sources of
visibility information.
Consider:
#pragma GCC visibility push(hidden)
class __attrib
14 matches
Mail list logo
