public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/13905] New: Use of __attribute__ ((visibility("X"))) in class and struct declarations
@ 2004-01-28 22:50 s_gccbugzilla at nedprod dot com
  2004-01-28 22:53 ` [Bug c++/13905] " pinskia at gcc dot gnu dot org
                   ` (11 more replies)
  0 siblings, 12 replies; 13+ messages in thread
From: s_gccbugzilla at nedprod dot com @ 2004-01-28 22:50 UTC (permalink / raw)
  To: gcc-bugs

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


^ permalink raw reply	[flat|nested] 13+ messages in thread
end of thread, other threads:[~2004-01-30  4:35 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-28 22:50 [Bug c++/13905] New: Use of __attribute__ ((visibility("X"))) in class and struct declarations s_gccbugzilla at nedprod dot com
2004-01-28 22:53 ` [Bug c++/13905] " pinskia at gcc dot gnu dot org
2004-01-28 23:07 ` s_gccbugzilla at nedprod dot com
2004-01-28 23:12 ` pinskia at gcc dot gnu dot org
2004-01-28 23:14 ` s_gccbugzilla at nedprod dot com
2004-01-28 23:16 ` s_gccbugzilla at nedprod dot com
2004-01-28 23:19 ` pinskia at gcc dot gnu dot org
2004-01-28 23:52 ` s_gccbugzilla at nedprod dot com
2004-01-29  3:16 ` giovannibajo at libero dot it
2004-01-29  3:25 ` pinskia at gcc dot gnu dot org
2004-01-29 20:01 ` s_gccbugzilla at nedprod dot com
2004-01-30  2:52 ` giovannibajo at libero dot it
2004-01-30  4:35 ` dannysmith at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).