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

[Alexei Sheplyakov]

Hi!

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:

\begin{quote}
[class]
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).
\end{quote}

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:

\begin{quote}
The cv-qualified or cv-unqualified versions of a type are distinct types;
however, they shall have the same representation and alignment requirements
(3.9)^46)

46)
The same representation and alignment requirements are meant to imply
interchangeability as arguments to functions, return values from functions,
and members of unions.
\end{quote}

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,
	Alexei

-------------- 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>