public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "sweetrommie at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/53398] New: feature request: option for overloaded methods order in vtable compatibility with msc
Date: Fri, 18 May 2012 14:28:00 -0000	[thread overview]
Message-ID: <bug-53398-4@http.gcc.gnu.org/bugzilla/> (raw)

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

             Bug #: 53398
           Summary: feature request: option for overloaded methods order
                    in vtable compatibility with msc
    Classification: Unclassified
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: sweetrommie@gmail.com


The target of this topic is about mingw and ms compiler incompatibility.

GCC places overloaded virtual functions in order they appear in class
declaration.
In opposite msc reverts them.

Assuming we have a dll compiled in msc and such header for using the dll:

class A {
 virutal void overl(void) = 0;
 virutal void fun1(void) = 0;
 virutal void overl(int i) = 0;
 virutal void overl(double d) = 0;
 virutal void fun2(void) = 0;
 virutal void overl(char *c) = 0;
};

to use it with mingw compiler we need to change it to

class A {
 virutal void overl(char *c) = 0;
 virutal void fun1(void) = 0;
 virutal void overl(double d) = 0;
 virutal void overl(int i) = 0;
 virutal void fun2(void) = 0;
 virutal void overl(void) = 0;
};

or to portable version, which removes overloading (behave gcc ordering)

class A {
 virutal void overlC(char *c) = 0;
 virutal void fun1(void) = 0;
 virutal void overlD(double d) = 0;
 virutal void overlI(int i) = 0;
 virutal void fun2(void) = 0;
 virutal void overlV(void) = 0;
};

It would be nice to have some option to just say the compiler to use different
order.
We could have an option added to a compiler like -fvisibility-ms-compat or
-fabi-version=n.
Or maybe better by something like pragma pack push, so we can do:

#pragma vtorder(push, reverted)
#include "dll_header.h"
#pragma vtorder(pop)


             reply	other threads:[~2012-05-18 14:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-18 14:28 sweetrommie at gmail dot com [this message]
2012-05-20 19:59 ` [Bug c++/53398] " pinskia at gcc dot gnu.org
2012-05-21 10:34 ` sweetrommie at gmail dot com
2012-05-23  8:34 ` sweetrommie at gmail dot com
2012-05-25 13:34 ` ktietz at gcc dot gnu.org
2012-05-28 15:52 ` sweetrommie at gmail dot com

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=bug-53398-4@http.gcc.gnu.org/bugzilla/ \
    --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).