[Bug c++/13905] New: Use of __attribute__ ((visibility("X"))) in class and struct declarations

[Bug c++/13905] New: Use of __attribute__ ((visibility("X"))) in class and struct declarations

[s_gccbugzilla at nedprod dot com]

I would like to propose G++ be extended so that you can set all members within a 
class or struct at once with a single __attribute__ specifier eg;

class __attribute__ ((visibility("public"))) PublicClass {
   int foo; // made public
public:
   static void foo2(); // also made public
};

This not uncoincidentally is identical to MSVC's __declspec(dllexport) syntax 
for classes and structs. All the macros currently used in cross-platform code 
can simply use __attribute__ ((visibility("public"))) for the APIEXPORT 
definition, mark the default as symbol hidden and we're done.

Typical arguments against this:

1. This exports too much stuff

On Windows developers for years have been designing the classes defined in 
public to not export extraneous members, using opaque types to hide 
implementation details. Therefore this is a null argument.

Besides you can always set specific members individually, thus overriding the 
class setting.

2. Just because MSVC does it this way why should GCC?

Because like it or not, MSVC is a major compiler. Lots of code has been written 
to use its method of exporting symbols (indeed, any Unix library which compiles 
on Windows). Currently setting them per member data and per member function 
requires editing too much code (plus looks VERY ugly) and I've not seen a single 
project which has bothered. This has caused much namespace pollution, exposure 
of far too much implementation detail and slows loading of apps generated by GCC 
greatly.

3. Specifying a file with symbols to be exported to the linker is good enough.

If that were true, why do Windows applications invariably use the __declspec() 
mechanism? To maintain such a file costs time, it's easy to forget or remove 
symbols with changes and it's a pain in the ass. It's far easier, more 
maintainable and generally nicer to extend the language to support this. Since 
we already agree on this (why else is there __attribute__?), this little 
alteration could make binaries generated by GCC so much nicer.

Cheers,
Niall

-- 
           Summary: Use of __attribute__ ((visibility("X"))) in class and
                    struct declarations
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: s_gccbugzilla at nedprod dot com
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13905

[Bug c++/13905] Use of __attribute__ ((visibility("X"))) in class and struct declarations

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-01-28 22:53 -------
Use struct instead of class then.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13905

[Bug c++/13905] Use of __attribute__ ((visibility("X"))) in class and struct declarations

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-01-28 23:07 -------
(In reply to comment #1)
> Use struct instead of class then.

Neither structs nor classes have this feature yet under any G++ I've tested. 
Unless you know something I don't ...

Cheers,
Niall


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13905

[Bug c++/13905] Use of __attribute__ ((visibility("X"))) in class and struct declarations

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-01-28 23:12 -------
We are no going to do it.  The point is that it makes things look werid like:

class __attribute__((visibility("public"))) T {
private:
int i; //is this public or private?
};

The point I was trying to make is that if you want the default accessor to be public use struct 
instead of class.

Also I forgot to mention we should not always follow M$ and their crappy compilers.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13905

[Bug c++/13905] Use of __attribute__ ((visibility("X"))) in class and struct declarations

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-01-28 23:14 -------
(In reply to comment #0)

> class __attribute__ ((visibility("public"))) PublicClass {

I should add that I made a mistake here - "public" is not a valid ELF symbol 
export specification. The choices are:

external, default, protected, hidden, internal.

Therefore I really meant to say there:

class __attribute__ ((visibility("external"))) PublicClass {

... meaning that all members (data and functions) are /exported/ ie; present in 
the ELF export symbol table.

My apologies for any confusion caused.

Cheers,
Niall


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13905

[Bug c++/13905] Use of __attribute__ ((visibility("X"))) in class and struct declarations

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-01-28 23:16 -------
Reopening due to my mistake. Sorry for the confusion - I should check my ELF 
specs before typing (it's late, and I'm tired sorry).


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13905

[Bug c++/13905] Use of __attribute__ ((visibility("X"))) in class and struct declarations

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-01-28 23:19 -------
But every thing is default to export, sorry try again.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13905

[Bug c++/13905] Use of __attribute__ ((visibility("X"))) in class and struct declarations

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-01-28 23:52 -------
(In reply to comment #6)
> But every thing is default to export, sorry try again.

I had actually thought there was already a -fvisibility command line option in 
GCC, but I was wrong. Ok to restate (this time clearly):

1. Addition of:

-fvisibility=external
-fvisibility=default
-fvisibility=protected
-fvisibility=hidden
-fvisibility=internal

... to available command line options in GCC. These are chosen for compatibility 
with Intel's C++ compiler. When specified, the default attribute for all symbols 
is whichever.

2. Addition of being able to specify __attribute__ ((visibility("X"))) in class 
and struct declarations where X is one of:

external, default, protected, hidden, internal.

Now you can specify -fvisibility=hidden to GCC. All symbols will by default be 
hidden in the ELF export table unless the code manually specifies __attribute__ 
((visibility("export"))).

The result: much cleaner ELF images output. Faster dynamic linking times. More 
scope for GCC to optimise object files as it now knows what RTTI info it can 
discard as well as improved COMDAT folding etc.

I in particular suffer from this as GCC generates binaries nearly twice as big 
than MSVC for identical code :( (I think it's the RTTI info for all the 
templates plus not being able to COMDAT fold most of the symbols)

References: http://people.redhat.com/drepper/dsohowto.pdf

Cheers,
Niall


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13905

[Bug c++/13905] Use of __attribute__ ((visibility("X"))) in class and struct declarations

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-01-29 03:16 -------
Makes sense to me. I *suppose* there must be some reason for not allowing the 
attribute at the class level, but until I hear a convincing technical argument 
for that, I'll support this.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |giovannibajo at gcc dot gnu
                   |                            |dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-01-29 03:16:22
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13905

[Bug c++/13905] Use of __attribute__ ((visibility("X"))) in class and struct declarations

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-01-29 03:25 -------
This is a dup of bug 9283.

*** This bug has been marked as a duplicate of 9283 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13905

[Bug c++/13905] Use of __attribute__ ((visibility("X"))) in class and struct declarations

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-01-29 20:01 -------
(In reply to comment #9)
> This is a dup of bug 9283.
> 
> *** This bug has been marked as a duplicate of 9283 ***

Can you mark #9283 as the resolved duplicate as I think I'm right in saying that 
this one supersedes #9283 whereas the reverse is not true?

To explain: #9283 wants the ability to mark classes and structs as hidden but 
this is bad DLL interface design. By default *everything* should be hidden and 
you should mark things as visible. That way if you forget anything you notice 
real quick - however you also by default *don't* export things. Lastly these 
semantics (hidden by default) are the ones Windows uses, which benefits cygwin, 
mingw and all cross-platform apps.

Also, #9283 has the major failing of not letting the compiler optimise the 
object files knowing that many symbols can be elided. See http://people.redhat.
com/drepper/dsohowto.pdf for more on this.

I may take a stab at this myself once v3.4 is more stable. It takes many hours 
for me to download it and every time I have so far it won't compile completely :
(

Cheers,
Niall


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13905

[Bug c++/13905] Use of __attribute__ ((visibility("X"))) in class and struct declarations

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-01-30 02:52 -------
Niall, this bug is *TOO* confusing. You posted it wrong, then reopened it with 
the wrong correction, and then fixed the correction yourself (and it was still 
wrong). Now you're saying that it's better than #9283, which is a cristal clear 
enhancement request.

I'm closing this bug for the last time. If you think #9283 is missing 
something, please add a comment to it, illustrating additional features you may 
like. Otherwise, please file a completely new bug report where you explain 
*correctly* the problem again, from scratch.

>I may take a stab at this myself once v3.4 is more stable. It takes 
>many hours for me to download it and every time I have so far it 
>won't compile completely :(

3.4 should be stable right now, but cygwin is not a stable platform for GCC 
development.

*** This bug has been marked as a duplicate of 9283 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13905

[Bug c++/13905] Use of __attribute__ ((visibility("X"))) in class and struct declarations

[dannysmith at gcc dot gnu dot org]

------- Additional Comments From dannysmith at gcc dot gnu dot org  2004-01-30 04:35 -------
Giovanni wrote:
'3.4 should be stable right now, but cygwin is not a stable platform for GCC 
development'

And one of the major instabilities in cygwin and mingw target is the 
non-portable 'class __attribute__((dll[im/ex]port)) Foo' semantics, on which 
this enhancement request seems to be based.  Dllimport  of classes causes
major headaches (FWIW, MS's own MFC framework uses .def files ("3. Specifying a 
file with symbols to be exported to the linker is good enough.") to buid shared 
libaries.

dllimport/export is really a decl attribute.  Applying it to user-defined types 
causes the problems.  I suspect the the same would occur with visibility 
attribute.

Danny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13905