CLN and GiNaC patches for Win64 build
Hi, I reviewed Robert's patches and added some of my own, that were necessary for GiNaC to work with CLN on Win64. They can be viewed on Github: === CLN === https://github.com/jrheinlaender/cln/commits/win64 There are two kinds of patches: - Patches required for Win64 platform (e.g. UL is 32 bit type on that platform). Mostly due to Robert (Number 1-10) - Cosmetic patches to avoid unnecessary compiler warnings (e.g. confusion of class and struct) Most patches I surrounded with #ifdef _M_AMD64 so that other platforms will be unaffected === GiNaC === https://github.com/jrheinlaender/ginac/commits/win64 - Here I removed some old patches that are not required any more because of improvements in MSVC 2015 - And added a few constructors from size_t I hope these patches are OK and can be included in master. Am 24.02.2018 um 12:49 schrieb Robert Szalai:
Here is the previous win64 patch set...
---------- Forwarded message ---------- From: "Robert Szalai" <robicjedi@gmail.com <mailto:robicjedi@gmail.com>> Date: Aug 15, 2012 02:22 Subject: Re: [CLN-list] MinGW64 build To: "CLN discussion list" <cln-list@ginac.de <mailto:cln-list@ginac.de>> Cc:
Hi Alexei,
I've splitted the path into 10 parts. There is a bigger one that is only s/long/intptr_t/ and s/unsigned long/uintptr_t/ the rest is very small.
Hopefully this can now be applied.
> Ditto (the corresponding hunk is not quite optimal, though. {s,u}int32 > can be typedef'ed to {,u}int32_t => no need for ugly #if's).
I was thinking of this, however we need exactly the same underlying type as (u)intptr_t for the same sized integer to avoid compiler confusion. So in some cases (e.g. on i686 Linux) stdint.h might define int32_t as int and intptr_t as long and in this case the compiler will complain about multiple definition of the same function.
Bests, Robert
_______________________________________________ CLN-list mailing list CLN-list@ginac.de https://www.cebix.net/mailman/listinfo/cln-list
Hi Richy, here's what the compiler says (sorry my system is German): factor.cpp(2254): error C2440: "Initialisierung": "std::size_t" kann nicht in "GiNaC::numeric" konvertiert werden factor.cpp(2254): note: Quelltyp konnte von keinem Konstruktor angenommen werden, oder die Überladungsauflösung des Konstruktors ist mehrdeutig The code in line 2254 is: numeric modulus = (vnlst.nops() > 3) ? vnlst.nops() : 3; It initializes a numeric from the return value of nops(), which is size_t. Am 01.05.2018 um 20:41 schrieb Richard B. Kreckel:
Hi Jan,
Thanks for the patches!
On 05/01/2018 12:54 PM, Jan Rheinländer wrote:
- And added a few constructors from size_t Interesting. What's the reason these ctors from size_t are needed?
-richy. _______________________________________________ GiNaC-devel mailing list GiNaC-devel@ginac.de https://www.cebix.net/mailman/listinfo/ginac-devel
On 05/02/2018 08:22 PM, Jan Rheinländer wrote:
here's what the compiler says (sorry my system is German):
factor.cpp(2254): error C2440: "Initialisierung": "std::size_t" kann nicht in "GiNaC::numeric" konvertiert werden factor.cpp(2254): note: Quelltyp konnte von keinem Konstruktor angenommen werden, oder die Überladungsauflösung des Konstruktors ist mehrdeutig
The code in line 2254 is:
numeric modulus = (vnlst.nops() > 3) ? vnlst.nops() : 3;
It initializes a numeric from the return value of nops(), which is size_t.
So on Windos, where unsigned int is the same as unsigned long, the two existing overloads of numeric ctor are ambiguous. Bummer. It's better to convert these prototypes to uint32_t, uint64_t from <cstdint> than add more overloads for size_t. This way, we need to maintain two overloads, rather than three. -richy.
Hi, the patch is on https://github.com/jrheinlaender/ginac/commit/d87445c0eaa27669f82bea19bb6993... Am 04.05.2018 um 23:38 schrieb Richard B. Kreckel:
On 05/02/2018 08:22 PM, Jan Rheinländer wrote:
here's what the compiler says (sorry my system is German):
factor.cpp(2254): error C2440: "Initialisierung": "std::size_t" kann nicht in "GiNaC::numeric" konvertiert werden factor.cpp(2254): note: Quelltyp konnte von keinem Konstruktor angenommen werden, oder die Überladungsauflösung des Konstruktors ist mehrdeutig
The code in line 2254 is:
numeric modulus = (vnlst.nops() > 3) ? vnlst.nops() : 3;
It initializes a numeric from the return value of nops(), which is size_t. So on Windos, where unsigned int is the same as unsigned long, the two existing overloads of numeric ctor are ambiguous. Bummer.
It's better to convert these prototypes to uint32_t, uint64_t from <cstdint> than add more overloads for size_t. This way, we need to maintain two overloads, rather than three.
-richy. _______________________________________________ GiNaC-devel mailing list GiNaC-devel@ginac.de https://www.cebix.net/mailman/listinfo/ginac-devel
participants (2)
-
Jan Rheinländer
-
Richard B. Kreckel