Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Fri, 2 Dec 2011 18:56:32 -0700

> The point is that it is *pure* virtual (destructor)

Destructors are actually a special case because the compiler will generate
one if none is supplied.

So the issue is whether a standards compliant compiler can require explicit
(not implicit) definition of the destructor in the derived class. So I had a
look at what the latest working draft for C++11 says. Here it is (from
section 12.4 which is titled Destructors). The original standard seems to
say this also but is somewhat less clear on this point. 

> 8) A destructor can be declared virtual (10.3) or pure virtual (10.4); if 
> any objects of that class or any derived class are created in the 
> program, the destructor shall be defined. 

> 5) A destructor that is defaulted and not defined as deleted is implicitly

> defined when it is odr-used (3.2) to destroy an object of its class type 
> (3.7) or when it is explicitly defaulted after its first declaration.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf

Nevertheless, if it's an issue with the old sun compiler then I will commit
a workaround.

> Your code is correct, the bug is in the ctime or time.h system header.
> But importing the std namespace before including ctime fixes the problem.

I am going to guess that moving the "#include <ctime>" to be first in the
stack as follows might take care of this, and that this might be less of a
mess (messes accumulate) compared to interspersing the import from namespace
std into the middle of the #include list which might cause issues on other
compilers.

#include <ctime>
#include <cstddef>
#include <cstdio>
#include <cmath>
#include <climits>
#include <cstring>

We have, it seems, one of everything old here including an old Solaris
machine so I was trying to reproduce the issue here. The old perl upgrade
install on our old solaris is finally done. Now the EPICS R3.14 latest build
is failing I suspect because gnu make 3.79.1 is installed. Hopefully will
get this reproduced soon on Monday. However, if you can try the above idea
first it might be easier and faster.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925

> -----Original Message-----
> From: Dirk Zimoch [mailto:[email protected]]
> Sent: Friday, December 02, 2011 1:34 AM
> To: Jeff Hill
> Cc: EPICS; Andrew Johnson
> Subject: Re: EPICS Base 3.14.12.2-rc1 available for testing
> 
> Hi Jeff
> 
> Jeff Hill wrote:
> >> I wonder why no other compiler complains? Even though the C++ standard
> >> states that the system will generate a destructor for you if you don't,
> >> declaring the destructor pure virtual in the base class clearly
> requests
> >> that the user defines one.
> >
> > If the function is virtual in the base class then of course it must be
> > virtual in any derived class - independent of whether the virtual
> keyword is
> > present or not. Of course virtual destructors are special and if there
> is a
> > virtual destructor in the base then there must also be one in the
> derived,
> > but I know of no restriction which prevents the compiler from implicitly
> > generating a virtual destructor. Nevertheless, if it causes issues we
> will
> > attend to it.
> 
> The point is that it is *pure* virtual (i.e. unimplemented): ... = 0;
> This makes the base class abstract and no instance can be made. Derived
> classes stay abstract unless all pure virtual functions are defined.
> Here, the destructor is pure virtual and thus must be defined before the
> derived class can be used.
> 
> That a virtual function stays virtual in derived classes has little to
> do with this problem. The question is not if the destructor is virtual.
> The problem is that there is no destructor at all.
> 
> >
> >> "/usr/include/sys/time.h", line 50: Error: Type name expected instead
> of
> >> "time_t".
> >
> > I do always try to explicitly import from the standard name space when
> using
> > the "#include <ctime>" form, which is the correct approach for
> maximizing
> > portability, but obviously neglected to do so in this situation.
> 
> Your code is correct, the bug is in the ctime or time.h system header.
> But importing the std namespace before including ctime fixes the problem.
> 
> Dirk
> 
> 
> >
> > Andrew: are you attending to this? If not, I will take care of it. I can
> > have a look at the casStreamOS.cc", line 304, issue also.
> >
> > Jeff
> > ______________________________________________________
> > Jeffrey O. Hill           Email        [email protected]
> > LANL MS H820              Voice        505 665 1831
> > Los Alamos NM 87545 USA   FAX          505 665 5107
> >
> > Message content: TSPA
> >
> >
> >> -----Original Message-----
> >> From: [email protected] [mailto:tech-talk-
> [email protected]]
> >> On Behalf Of Dirk Zimoch
> >> Sent: Wednesday, November 30, 2011 8:57 AM
> >> To: Andrew Johnson
> >> Cc: EPICS tech-talk
> >> Subject: Re: EPICS Base 3.14.12.2-rc1 available for testing
> >>
> >> Andrew Johnson wrote:
> >>> The first release candidate for the 3.14.12.2 version of Base is now
> >> available
> >>> on the website for general testing.  Links to the tarfile and Release
> >> Notes
> >>> can be found at http://www.aps.anl.gov/epics/base/R3-14/12.php
> >>>
> >>> Please report any problems you find to tech-talk.  If no major issues
> >> are
> >>> discovered before December 12th we will release 3.14.12.2 on that
> date.
> >>>
> >>> Thanks to everyone who has helped with this process.
> >>>
> >>> - Andrew
> >> I tried it on my old sun solaris. It failed with:
> >>
> >>
> >> /afs/psi.ch/sys/@sys/sepp/bin/CC -c  -D_POSIX_C_SOURCE=199506L
> >> -D_XOPEN_SOURCE=500            -DUNIX  -DSOLARIS=8 -mt  -
> D__EXTENSIONS__
> >>    -O   +w             -I. -I../O.Common -I. -I..
> >> -I../../../include/os/solaris -I../../../include        ../casw.cpp
> >> "../udpiiu.h", line 158: Error: Cannot declare a member of the abstract
> >> type udpiiu::M_repeaterTimerNotify.
> >> "../casw.cpp", line 306: Warning: statement is unreachable.
> >> 1 Error(s) and 1 Warning(s) detected.
> >> make[3]: *** [casw.o] Error 1
> >> make[3]: Leaving directory
> >> `/afs/psi.ch/group/8431/dirk/solaris/base-3.14.12.2-
> rc1/src/ca/O.solaris-
> >> sparc'
> >> make[2]: *** [install.solaris-sparc] Error 2
> >>
> >> The reason is that the base class repeaterTimerNotify has a pure
> virtual
> >> destructor  (virtual ~repeaterTimerNotify () = 0;) which is not
> >> overwritten by udpiiu::M_repeaterTimerNotify. Thus
> >> udpiiu::M_repeaterTimerNotify is still abstract and cannot be
> >> instantiated.
> >>
> >> Add: ~M_repeaterTimerNotify () {};
> >>
> >> I wonder why no other compiler complains? Even though the C++ standard
> >> states that the system will generate a destructor for you if you don't,
> >> declaring the destructor pure virtual in the base class clearly
> requests
> >> that the user defines one.
> >>
> >> After fixing this I get:
> >>
> >> /afs/psi.ch/sys/@sys/sepp/bin/CC -c  -D_POSIX_C_SOURCE=199506L
> >> -D_XOPEN_SOURCE=500            -DUNIX  -DSOLARIS=8 -mt  -
> D__EXTENSIONS__
> >>    -O   +w             -I. -I../O.Common -I. -I..
> >> -I../../../../include/os/solaris -I../../../../include
> >> ../epicsTimeTest.cpp
> >> "/usr/include/sys/time.h", line 50: Error: Type name expected instead
> of
> >> "time_t".
> >> 1 Error(s) detected.
> >> make[3]: *** [epicsTimeTest.o] Error 1
> >>
> >> The problem is a bug in the way the solaris compiler handles the
> >> standard C header file time.h when included from C++ via ctime. It
> hides
> >> the typedef long time_t; into namespace std and later in the same
> header
> >> file fails to find it.
> >>
> >> To fix this, I had to move
> >> using namespace std;
> >> in front of
> >> #include <ctime>
> >>
> >>
> >> Next problem:
> >> /afs/psi.ch/sys/@sys/sepp/bin/CC -c  -D_POSIX_C_SOURCE=199506L
> >> -D_XOPEN_SOURCE=500            -DUNIX  -DSOLARIS=8 -mt  -
> D__EXTENSIONS__
> >>    -O   +w           -xcode=pic32  -I. -I../O.Common -I. -I..
> >> -I../../../../src/cas/generic -I../../../../src/cas/io/bsdSocket
> >> -I../../../../src/cas/generic/st -I../../../../src/cas/../ca
> >> -I../../../../include/os/solaris -I../../../../include
> >> ../../../../src/cas/generic/st/casStreamOS.cc
> >> "../../../../src/cas/generic/st/casStreamOS.cc", line 304: Error:
> >> "casStreamOS::armRecv()" has already been called and cannot be defined
> >> inline.
> >> 1 Error(s) detected.
> >> make[4]: *** [casStreamOS.o] Error 1
> >>
> >> Damn, why is this an error instead of a warning? Anyway:
> >> Put inline void casStreamOS::armRecv() before
> casStreamIOWakeup::expire().
> >>
> >>
> >>
> >> cap5 does not work at all because my perl version has been compiled
> with
> >> a different compiler and all the compiler options don't work. The
> reason
> >> was that I needed a newer perl version to compile EPICS than the one
> >> that was already installed. It seems the guy who compiled perl 5.8.8
> >> used gcc instead of the system compiler.
> >>
> >> Maybe the cap5/Makefile should check for compatibility between the
> >> current compiler and the options returned from perlConfig.pl
> >> (perlConfig.pl cc) or change not only CFLAGS but CC too.
> >>
> >>
> >> Otherwise all is fine :-)
> >>
> >> I successfully compiled for
> >> vxWorks 5.5 ppc604 (aka Tornado 2.2)
> >> vxWorks 6.3 ppc603 (used on cRIO)
> >> vxWorks 6.7 ppc604
> >> linux xscale_be (Montavista gcc version 3.4.3)
> >> linux ppc405 (embedded in Virtex 5, Crosstool gcc version 4.0.2)
> >> Scientific Linux 5.1 x86
> >> Scientific Linux 6.0 x86_64
> >> Scientific Linux 6.0 x86 (cross build on 64 bit machine)
> >>
> >>
> >> For your info:
> >>  > perl -v
> >> This is perl, v5.8.8 built for sun4-solaris
> >>  > perl perlConfig.pl cc
> >> gcc
> >>  > /afs/psi.ch/sys/@sys/sepp/bin/cc -V
> >> cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15
> >>  > uname -a
> >> SunOS pssvxw.psi.ch 5.8 Generic_108528-19 sun4u sparc SUNW,Sun-Blade-
> 100
> >>
> >>
> >> Dirk
> >
> >

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System