public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "s_gccbugzilla at nedprod dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/13905] New: Use of __attribute__ ((visibility("X"))) in class and struct declarations
Date: Wed, 28 Jan 2004 22:50:00 -0000	[thread overview]
Message-ID: <20040128224951.13905.s_gccbugzilla@nedprod.com> (raw)

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


             reply	other threads:[~2004-01-28 22:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-28 22:50 s_gccbugzilla at nedprod dot com [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040128224951.13905.s_gccbugzilla@nedprod.com \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).