[GiNaC-devel] Compile with MSVC 98% successful

[Alexei Sheplyakov]

Hello,

On Tue, Aug 17, 2010 at 07:41:46AM +0430, Jan Rheinlaender wrote:

> I compiled ginac-1.5.7 with Microsoft Visual C++. You can find an
> account of my adventures on
> http://sourceforge.net/apps/mediawiki/ooo-imath/index.php?title=Installation#Compilation_with_Microsoft_Visual_C.2B.2B 

Could you please post patches instead of clumsy instructions like "edit file
foo, find bar, replace with baz"? Warning: very few of them will be applied
as is, see the comments below.

> Therefore, go to the Makefile again and edit the following entry 

I think editing automatically generated files is kind of pointless; cf.
when fixing a bug one edits the source code, not binaries. Ditto for
fiddling with *.lo files. Perhaps you need to instruct automake to use
asm sources only when compiling with GCC.

> cl_low.h defines extern "C" uint32 mulu32_high;

Which is allowed by the Standard (specifically, [dcl.link]). However,
it also says:

"At most one function with a particular name can have C language linkage. Two
declarations for a function with C language linkage with the same function
name (ignoring the namespace names that qualify it) that appear in different
namespace scopes refer to the same function. Two declarations for an object
with C language linkage with the same name (ignoring the namespace names that
qualify it) that appear in different namespace scopes refer to the same object.
[Note: because of the one definition rule (3.2), only one definition for
a function or object with C linkage may appear in the program; that is, such
a function or object must not be defined in more than one namespace scope."

Thus moving those functions into the global namespace does actually
make sense. However, it's better to prefix functions' names with "cl_"
(or "cln_") to avoid possible name collisions.

> cl_I.h declares 
> extern cl_private_thing cl_I_constructor_from_UL(uint32 wert); 
> extern cl_private_thing cl_I_constructor_from_Q(sint64 wert);
> somewhere in the file
> Comment out these declarations
> Replace them by the following at the beginning of the file:
> extern cln::cl_private_thing cl_I_constructor_from_UL(uint32 wert);
> extern cln::cl_private_thing cl_I_constructor_from_Q(sint64 wert);

Moving these functions outside of namespace cln is certainly unacceptable.

> Edit cl_LF.h, comment out 
> extern const cl_LF cl_I_to_LF (const cl_I& x, uintC len); 
> and add 
> extern const cln::cl_LF cl_I_to_LF (const cln::cl_I& x, uintC len);
> to the beginning of the file, outside the namespace cln

Ditto.

> The other examples need more modifications of the source along the same
> lines to link. Only e.cc presents new problems
> Add #include "../src/float/lfloat/cl_LF.h" to the beginning of the file
> Comment out the extern cl_LF cl_I_to_LF(const cl_I&, uintC);
> declaration lower down

Header files in the src directory are private, and should be included
only by other files in the src directory.

> function.cpp: Change 
> return (new GiNaC::power(*this, power_param))->setflag(status_flags::dynallocated | status_flags::evaluated);
> with
> return (power::power(*this, power_param)).setflag(status_flags::evaluated);

I'm afraid your variant is invalid, since it violates [basic.lookup.qual],
specifically

"1 The name of a class or namespace member can be referred to after the ::
scope resolution operator (5.1) applied to a nested-name-specifier that
nominates its class or namespace. During the lookup for a name preceding
the :: scope resolution operator, object, function, and enumerator names
are ignored. If the name found is not a class-name (clause 9) or namespace-name
(7.3.1), the program is ill-formed."

In the scope of function::power method definition the name `power'
refers to the function::power itself, so it is not a class or a namespace
name, and the program is invalid.

Also this change breaks compilation with GCC 4.5 (for reason explained above).
It's unacceptable, sorry.

> polynomial/primes_factory.h: MSVC does not accept void * as argument of sizeof()
> Edit configure.ac and add a line AC_CHECK_SIZEOF(void*, 1). Run
> autoreconf and re-run configure.

This sounds a bit self-contradictory. AC_CHECK_SIZEOF(void*) certainly invokes
sizeof(void*), so if your compiler doesn't grok sizeof(void*) (which I really
doubt) AC_CHECK_SIZEOF(void*) is not going to work. On the other hand, if
AC_CHECK_SIZEOF(void*) works, you don't actually need this trick.

> External constants must be outside namespaces

I'm afraid the Standard does not enforce this (and we don't want to pollute
the global namespace).

> 56 of 57 tests passed. The one that didn't said:
> 
> time_uvar_gcd.exe:
> timing univarite GCD
> GCD of relatively prime polynomials a and b
> degree(a) = 100, degree(b) = 50
> mod_gcd		: 1 5.96e-002
> heur_gcd	: 1 1.71e-002
> sr_gcd:		: 1 3.73e+001
> Non-trivial GCD, degree(a) = 100, degree(b) = 100
> mod_gcd		: 51 1.70e-001
> heur_gcd	: 51 1.56e-002
> heur_gcd (old)	: 51 2.40e-001
> sr_gcd:		: 51 6.62e+000
> sr_gcd (old)	: 51 1.16e+001
> Non-trivial GCD, degree(a) = 908, degree(b) = 908

Should be:

Non-trivial GCD, degree(a) = 1000, degree(b) = 1000

So it looks like inputs are incorrect (I don't know why).

Best regards,
	Alexei