Simon Boivin wrote:
We had some problems to install Gecode on our new parallel computer
with Intel Compiler 64 bits which crash when compiling the
library :
icpc -I. -I. -DNDEBUG -fPIC -ggdb -O3 -fno-strict-aliasing -
DNDEBUG -fPIC -ggdb
-O3 -fno-strict-aliasing \
-c -o gecode/int/var/imp.o gecode/int/var/imp.cc
../gecode/kernel/core.icc(1605): error #1556: conversion from
inaccessible
base class "Gecode::ActorLink" is not allowed
t[0] = static_cast<Propagator*>(f[0]->prev());;
which is an internal error of the compiler.
Actually, this is not an internal error, but a proper error in the
code (at least icpc thinks it is).
According to the c++ expert from Intel the program is not c++
standard conforming.
So, to install the library we must modified the class Space as :
[...]
- class Actor : public ActorDeleteLink {
+ class Actor : private ActorDeleteLink {
Yes, I also noticed that recently. However, we are quite sure that
our code is legal C++ and Intel does not implement that correctly.
All the classes down the hierarchy (Propagator, Actor,
ActorDeleteLink, and ActorLink) have friend declarations with the
Variable class, where the error occurs - so the base class ActorLink
really shouldn't be inaccessible here. Both gcc and the Microsoft C++
compiler handle this without problems.
The minimal example that shows this problem is:
template <class X> class C;
class A {};
class B : private A { template <class X> friend class C; };
template <class X> class C { public: C(A* a) { B* b = static_cast<B*>
(a); } };
class D { D() { C<int> c(0); } };
If you make class C a non-template class, everything works. If you
have contact to the icpc developers, please forward this example to
them, maybe they can explain whether we misinterpreted the C++
standard or it's a bug in their compiler. I'm really interested what
they say.
A slightly cleaner workaround would be to add a private function
Propagator* fromActorLink(ActorLink* a) { return
static_cast<Propagator*>(a); }
to the Propagator class, which just does the static_cast. That way,
you could stick with private inheritance.
Cheers,
Guido
--
Guido Tack
Programming Systems Lab, Saarland University, Germany
http://www.ps.uni-sb.de/~tack
_______________________________________________
Gecode users mailing list
[EMAIL PROTECTED]
https://www.gecode.org/mailman/listinfo/gecode-users
