Mark Mitchell [EMAIL PROTECTED] writes:
Jason Merrill wrote:
It seems that you have a different mental model of type visibility.
I've gotten a little lost in this thread. Is there a clear proposal for
the semantics that we're leaning towards at this point?
One meta-note is that
Jason Merrill wrote:
OK, you've convinced me that the compiler shouldn't override or complain
about explicit visibility attributes. Do you have a problem with
implicit propagation of visibility in the absence of an attribute?
Specifically:
Do you agree with implicitly giving template
Hi,
On Sat, 15 Jul 2006, Gabriel Dos Reis wrote:
| I don't see how they get past this issue. I've had some claim, but
| it's a feature, not a bug.
|
| The basic question is, are two unrelated types in different dlls the
| same, just because they have the same name? How do you prevent
Geoffrey Keating wrote:
Jason Merrill [EMAIL PROTECTED] writes:
Benjamin Smedberg wrote:
Also, do you agree with warning about a class with greater
visibility than its data members/bases?
Sure... I would really like to disable this warning if possible,
since it will be produced thousands
Gabriel Dos Reis [EMAIL PROTECTED] writes:
Jason Merrill [EMAIL PROTECTED] writes:
[...]
| | - I don't recall suggesting that
| | multiple types with the same name should be able to exist.
| then you have to consider that suggestion and come with an answer.
|
| I don't see why.
Tristan Wibberley [EMAIL PROTECTED] writes:
The types are defined in headers and are thus known
to exist - no visibility attributes will or should change that.
The question here is not whether the types exist, but which types are
the same as which other types.
I think that what you want is a
Jason Merrill [EMAIL PROTECTED] writes:
Benjamin Smedberg wrote:
Jason Merrill wrote:
Do you agree with implicitly giving template instantiations the
minimum visibility of the template and arguments unless explicitly
overridden?
This is not what I would naturally expect, coming from
Joe Buck [EMAIL PROTECTED] writes:
I wrote [for two classes S with visibility == hidden ]
| | We can have two distinct
| | classes named S, and no one can tell. Each bit of code will see one
| | definition of S.
Jason Merrill [EMAIL PROTECTED] writes:
| I think that Joe's point is
Jason Merrill [EMAIL PROTECTED] writes:
Gabriel Dos Reis wrote:
Jason Merrill [EMAIL PROTECTED] writes:
So, -concretely- what happens to a class S (e.g. associated type
info object
address, address of member functions, etc.) with external linkage,
defined in multiple translation units,
On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
I'm not clear about you can't compare them.
Surely, I can take the address of typeid(S) and pass it around to
a function in another translation unit. I can do
typeinfo1-before(*typeinfo2), where typeinfo1 and
Joe Buck [EMAIL PROTECTED] writes:
On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
I'm not clear about you can't compare them.
Surely, I can take the address of typeid(S) and pass it around to
a function in another translation unit. I can do
First of all, thank you for seeing the problem I was trying to
communicate.
Geoffrey Keating [EMAIL PROTECTED] writes:
| Joe Buck [EMAIL PROTECTED] writes:
|
| I wrote [for two classes S with visibility == hidden ]
| | | We can have two distinct
| | | classes named S, and no one can
Geoffrey Keating [EMAIL PROTECTED] writes:
| Joe Buck [EMAIL PROTECTED] writes:
|
| On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
| I'm not clear about you can't compare them.
|
| Surely, I can take the address of typeid(S) and pass it around to
| a function
Geoffrey Keating [EMAIL PROTECTED] writes:
| Jason Merrill [EMAIL PROTECTED] writes:
|
| Gabriel Dos Reis wrote:
| Jason Merrill [EMAIL PROTECTED] writes:
| So, -concretely- what happens to a class S (e.g. associated type
| info object
| address, address of member functions, etc.) with
On 14/07/2006, at 3:01 PM, Gabriel Dos Reis wrote:
First of all, thank you for seeing the problem I was trying to
communicate.
Geoffrey Keating [EMAIL PROTECTED] writes:
| Joe Buck [EMAIL PROTECTED] writes:
|
| I wrote [for two classes S with visibility == hidden ]
| | | We can have two
On Jul 14, 2006, at 3:01 PM, Gabriel Dos Reis wrote:
That would mirror how C++ handles classes in unnamed namspaces. In
other words, the visibility would have to be part of the mangled name.
Can't do that and preserve the abi, also, there is no concept in gcc
currently to so name it, and
Geoffrey Keating [EMAIL PROTECTED] writes:
[...]
| | I don't think you can say 'no piece of code knows about both of
| them'.
| | What you can say is that these two classes are both named S but
| | they're different, just as if they were in different namespaces.
|
| That would mirror how
Mike Stump [EMAIL PROTECTED] writes:
[...]
| All in all, we should just agree to not worry about non-merged
| typeinfo name, or remove support for it.
If we remove support for it, then that indeed simplifies the issue.
-- Gaby
On Sat, Jul 15, 2006 at 12:19:40AM +0200, Gabriel Dos Reis wrote:
On platfoms where __GXX_MERGED_TYPEINFO_NAMES is not defined, before()
is defined in terms of the mangled names of the types. I'm unable to
find the mangled names are different.
Which is why we should just say that it is
Joe Buck [EMAIL PROTECTED] writes:
| On Sat, Jul 15, 2006 at 12:19:40AM +0200, Gabriel Dos Reis wrote:
| On platfoms where __GXX_MERGED_TYPEINFO_NAMES is not defined, before()
| is defined in terms of the mangled names of the types. I'm unable to
| find the mangled names are different.
|
|
On Jul 14, 2006, at 3:50 PM, Gabriel Dos Reis wrote:
I seem to remember a PR posted by Adobe people kind of related to
this, but maybe I'm remembering wrong. I have to dig up bugzilla.
If it is a bug that describes how matching doesn't work across dylibs
on older darwin systems (pre-tiger),
On Jul 14, 2006, at 4:03 PM, Gabriel Dos Reis wrote:
What that concretely means is that it alienates, for example, codes
based on Factory desigbn pattern using typeinfo objects.
I'd love some input from the MS VC++ programming crowd on this
issue. I don't see how they get past this issue.
On Sat, Jul 15, 2006 at 01:03:46AM +0200, Gabriel Dos Reis wrote:
Joe Buck [EMAIL PROTECTED] writes:
| On Sat, Jul 15, 2006 at 12:19:40AM +0200, Gabriel Dos Reis wrote:
| On platfoms where __GXX_MERGED_TYPEINFO_NAMES is not defined, before()
| is defined in terms of the mangled names of
Joe Buck [EMAIL PROTECTED] writes:
| On Sat, Jul 15, 2006 at 01:03:46AM +0200, Gabriel Dos Reis wrote:
| Joe Buck [EMAIL PROTECTED] writes:
|
| | On Sat, Jul 15, 2006 at 12:19:40AM +0200, Gabriel Dos Reis wrote:
| | On platfoms where __GXX_MERGED_TYPEINFO_NAMES is not defined, before()
| |
Mike Stump [EMAIL PROTECTED] writes:
| On Jul 14, 2006, at 4:03 PM, Gabriel Dos Reis wrote:
| What that concretely means is that it alienates, for example, codes
| based on Factory desigbn pattern using typeinfo objects.
|
| I'd love some input from the MS VC++ programming crowd on this
Jason Merrill wrote:
It seems that you have a different mental model of type visibility.
I've gotten a little lost in this thread. Is there a clear proposal for
the semantics that we're leaning towards at this point?
One meta-note is that we're not the first people to consider this. I
Gabriel Dos Reis wrote:
Joe Buck wrote:
Now, this being a conscious decision for ODR violation, it would
probably need to be documented because then we may have
typeinfo1 != typeinfo2
and yet
!typeinfo1.before(typeinfo2) !typeinfo2.before(typeinfo1)
There are probably other
Jason Merrill [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Joe Buck wrote:
| Now, this being a conscious decision for ODR violation, it would
| probably need to be documented because then we may have
| typeinfo1 != typeinfo2
| and yet
| !typeinfo1.before(typeinfo2)
I wrote [for two classes S with visibility == hidden ]
| | We can have two distinct
| | classes named S, and no one can tell. Each bit of code will see one
| | definition of S.
Jason Merrill [EMAIL PROTECTED] writes:
| I think that Joe's point is that IF you have two classes named S,
On Jul 12, 2006, at 10:04 AM, Tristan Wibberley wrote:
This isn't type visibility. Shared objects don't export types
they export symbols. The types are defined in headers and are
thus known to exist - no visibility attributes will or should
change that.
Actually in C++, they are
Daniel Jacobowitz wrote:
On Wed, Jul 12, 2006 at 02:04:37AM +0100, Tristan Wibberley wrote:
If the programmer had intended that the type should appear to not exist.
it wouldn't be defined in a header #include-able by client code. The
GCC doesn't know if the header is includable by client
On Wed, Jul 12, 2006 at 07:49:21PM +0100, Tristan Wibberley wrote:
No, that's why we need programmer provided attributes. The programmer says:
the client code needs to know about the existence of this type so it
can get pointers and references to instances and pass them back in later
and
On Jul 12, 2006, at 11:49 AM, Tristan Wibberley wrote:
the client code needs to know about the existence of this type so
it can get pointers and references to instances and pass them back
in later and maybe be able to call virtual member functions and
access non-static members by putting it
Tristan Wibberley [EMAIL PROTECTED] writes:
| Daniel Jacobowitz wrote:
| On Wed, Jul 12, 2006 at 02:04:37AM +0100, Tristan Wibberley wrote:
| If the programmer had intended that the type should appear to not
| exist. it wouldn't be defined in a header #include-able by client
| code. The
|
Daniel Jacobowitz [EMAIL PROTECTED] writes:
[...]
| I just don't get it. Why should it matter whether a member function is
| virtual or not in order to be able to call it from outside this shared
| object? Either you can access the public members of the class, or you
| can't. Being able to
Daniel Jacobowitz wrote:
On Wed, Jul 12, 2006 at 02:04:37AM +0100, Tristan Wibberley wrote:
If the programmer had intended that the type should appear to not exist.
it wouldn't be defined in a header #include-able by client code. The
GCC doesn't know if the header is includable by client
Mike Stump wrote:
On Jul 12, 2006, at 11:49 AM, Tristan Wibberley wrote:
the client code needs to know about the existence of this type so it
can get pointers and references to instances and pass them back in
later and maybe be able to call virtual member functions and access
non-static
Gabriel Dos Reis wrote:
Tristan Wibberley [EMAIL PROTECTED] writes:
| The programmer says:
|
| the client code needs to know about the existence of this type so it
| can get pointers and references to instances and pass them back in
| later and maybe be able to call virtual member functions
Daniel Jacobowitz wrote:
On Wed, Jul 12, 2006 at 07:49:21PM +0100, Tristan Wibberley wrote:
No, that's why we need programmer provided attributes. The programmer says:
the client code needs to know about the existence of this type so it
can get pointers and references to instances and pass
(copying your mail to the gcc mailing list again)
Benjamin Smedberg wrote:
Jason Merrill wrote:
It seems that you have a different mental model of type visibility.
The way I was thinking about it, if a type has hidden visibility, we
can't refer to it from outside its object. Thus, it
Jason Merrill wrote:
OK, you've convinced me that the compiler shouldn't override or complain
about explicit visibility attributes. Do you have a problem with
implicit propagation of visibility in the absence of an attribute?
Specifically:
Do you agree with implicitly giving template
Tristan Wibberley [EMAIL PROTECTED] writes:
| Mike Stump wrote:
| On Jul 12, 2006, at 11:49 AM, Tristan Wibberley wrote:
| the client code needs to know about the existence of this type so
| it can get pointers and references to instances and pass them back
| in later and maybe be able to
Tristan Wibberley [EMAIL PROTECTED] writes:
[...]
| I am suggesting that visibility attributes should *not* touch the C++
| type system in any way.
But then, at the same time you're talking of polymorphic types
(e.g. vtables).
| Since C++ doesn't have a notion of module a
| class that the
Benjamin Smedberg wrote:
Jason Merrill wrote:
Do you agree with implicitly giving template instantiations the
minimum visibility of the template and arguments unless explicitly
overridden?
This is not what I would naturally expect, coming from a
dllimport/export mindset, but I don't think
Gabriel Dos Reis wrote:
Tristan Wibberley [EMAIL PROTECTED] writes:
| Mike Stump wrote:
| On Jul 12, 2006, at 11:49 AM, Tristan Wibberley wrote:
| the client code needs to know about the existence of this type so
| it can get pointers and references to instances and pass them back
| in
Jason Merrill [EMAIL PROTECTED] writes:
[...]
| | - I don't recall suggesting that
| | multiple types with the same name should be able to exist.
| then you have to consider that suggestion and come with an answer.
|
| I don't see why. The point is that visibility is orthogonal to
|
On Thu, Jul 13, 2006 at 01:36:46AM +0200, Gabriel Dos Reis wrote:
So, -concretely- what happens to a class S (e.g. associated type info object
address, address of member functions, etc.) with external linkage,
defined in multiple translation units, with say hidden visibility?
Well, there are
Joe Buck [EMAIL PROTECTED] writes:
| On Thu, Jul 13, 2006 at 01:36:46AM +0200, Gabriel Dos Reis wrote:
| So, -concretely- what happens to a class S (e.g. associated type info object
| address, address of member functions, etc.) with external linkage,
| defined in multiple translation units,
Gabriel Dos Reis wrote:
Jason Merrill [EMAIL PROTECTED] writes:
So, -concretely- what happens to a class S (e.g. associated type info object
address, address of member functions, etc.) with external linkage,
defined in multiple translation units, with say hidden visibility?
If it has hidden
Gabriel Dos Reis wrote:
Joe Buck [EMAIL PROTECTED] writes:
| On Thu, Jul 13, 2006 at 01:36:46AM +0200, Gabriel Dos Reis wrote:
| So, -concretely- what happens to a class S (e.g. associated type info object
| address, address of member functions, etc.) with external linkage,
| defined in
Gabriel Dos Reis wrote:
Tristan Wibberley [EMAIL PROTECTED] writes:
[...]
| I am suggesting that visibility attributes should *not* touch the C++
| type system in any way.
But then, at the same time you're talking of polymorphic types
(e.g. vtables).
vtables happen to just work with
Tristan Wibberley [EMAIL PROTECTED] writes:
But I think it is important that there are three places where
visibility is a factor (as a concept of being able to see things
rather than the attribute).
I think it would help if you wrote down the rules for the visibility
attributes as applied to
Daniel Jacobowitz wrote:
I just don't get it. Why should it matter whether a member function is
virtual or not in order to be able to call it from outside this shared
object? Either you can access the public members of the class, or you
can't. Being able to access some of them and get link
Benjamin Smedberg wrote:
Jason, I'm sorry to email you directly, as I don't know which email list
I should be discussing on. I've built gcc trunk after your visibility
patch landed, and there are some serious issues with compiling Mozilla now:
Take the following code:
class __attribute__
Jason Merrill wrote:
It seems that you have a different mental model of type visibility. The
way I was thinking about it, if a type has hidden visibility, we can't
refer to it from outside its object. Thus, it doesn't make sense for
members or objects with that type to have greater
55 matches
Mail list logo
