[GiNaC-list] msvc support patch (Was: use of STL iterators in GiNaC)

Alexei Sheplyakov varg at metalica.kh.ua
Tue Apr 21 10:02:38 CEST 2009


On Sun, Apr 19, 2009 at 11:26:26PM +0100, Michael Goffioul wrote:

> The main problem when compiling packages with VC++ is not the
> compiler itself, which is pretty C/C++ compliant,

Actually CLN itself is not quite standard compliant. It used to rely on 
non-standard compiler and linker features, such as GNU inline semantics
(which is IMHO much better than one imposed by C++ and C99), weak symbols
support, etc. Although most of these issues are already fixed there are
definitely quite a number of GCC'isms left.

[skipped auto* tools rant]

> For the specific case of CLN, there were a couple of issues I also had
> to take care of:
> objects as being "class", while there are actually "struct"; VC++ generates
> different mangled names for struct and class, so you end up with unresolved
> references.

AFAIK struct and class are synonymous, the standard says:

4 A structure is a class defined with the class-key struct; its members
  and base classes (clause 10) are public by default (clause 11).

Anyway, if your compiler doesn't care about standards, please submit a patch.
Note: please take care to write proper comments (i.e. why patch is necessary
at all, what problem[s] it solves, etc.) and not break compilation on a primary
platform (GNU/Linux). Also it would be nice if you separate unrelated changes
and post them as individual patches (as opposed to all-in-one patch).

> The same happen for const/non-const (forward declare as
> non-const, but define as const).

Very interesting. [basic.type.qualifier] says:

The cv-qualified or cv-unqualified versions of a type are distinct types;
however, they shall have the same representation and alignment requirements

The same representation and alignment requirements are meant to imply
interchangeability as arguments to functions, return values from functions,
and members of unions.

I don't quite understand how it's possible for cv-qualified and non-cv-qualified
type to have different mangled names without violating the above requirements.

Anyway, please submit a patch.

> - assembly code: here I cheated a little bit and used gcc to compile the
> .S file; this required some hacks in the Makefile

> - some namespace issues: apparently, declaring a function inside the
> body of another method, which is parted of the cln namespace, does not
> make VC++ to tag the declared function with the cln namespace;

This is definitely a compiler bug.

> for instance in number.h, I had to move the "extern" statements of
> CL_DEFINE_LONG_CONSTRUCTOR out of the method bodies.

I'm afraid such an approach is unacceptable. Those functions are intended
for internal usage only, and they are hidden from users for a reason
(otherwise it would be very difficult to guarantee binary compatibility).
We could export them only for msvc, but then we can't guarantee binary
(and source-level) compatibility any more.

Best regards,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
URL: <http://www.cebix.net/pipermail/ginac-list/attachments/20090421/e6908e20/attachment.sig>

More information about the GiNaC-list mailing list