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 i
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 preve
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 instan
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
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
wond
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 is
Mike Stump <[EMAIL PROTECTED]> writes:
| 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 ac
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, befor
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 nam
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. I
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),
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 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 unsp
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
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 mirro
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 wha
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
Geoffrey Keating <[EMAIL PROTECTED]> writes:
| 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
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 function
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 t
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 n
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 d
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 ty
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 tran
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 th
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 exp
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
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
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 nam
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)
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 incon
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 err
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 appli
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 typ
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:
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
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
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
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
| lin
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
| >
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 i
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 C
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 ab
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 instan
(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 doesn'
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 th
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 functio
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 membe
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 code
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 a
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. T
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 i
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
>
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 code
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 e
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 code; I assume
that's the us
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 visibilit
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__ ((vi
58 matches
Mail list logo
