On Mon, May 05, 2008, Scott Brozell wrote:
> Apparently management decided boost was worth the cost,
come on...you know that Wei (not "management") decides what happens with
gleap. I don't have a clue about how/why boost is needed for gleap, nor how
we merge boost bugfixes into our code, nor what we will do when Wei gets run
over by a bus and no one else understands how that code works.
Let's at least get a check in configure_at for version 1.1 that checks for
gcc/g++ >=3.4 on cygwin/linux (and maybe version 4.x on Solaris and MacOSX),
and skips gleap compilation with an appropriate informational message if a
compliant compiler is not available. (Not clear to me where we stand
with AIX.)
> Management cant face that C++ is a better C.
My point: C++ allows (encourages) people to write code that I can't read or
debug. And I'm not the only one in this situation. If you get good returns
by allowing flexible code, or less susceptibility to errors, fine. Too often,
what you get looks like elsize.cc:
> The elsize.cc code mixes C and C++ headers, mixes iostreams with fprintf
> statements, and still calls malloc/calloc to allocate arrays. As far as I can
> see, it sends the wrong type arguments to calloc(). It provides a facility
> for making natoms an unsigned long long variable(!), but never bothers to
> check the return from calloc(), which might seem prudent if your system has
> more than 4 billion atoms. and so on.
For *this particular problem* (read a data file, calculate and print a result,
quit) my view is that the language bears some of the responsibility here.
Plus, it is the only program in Amber10 that requires C++: we could reduce our
compiler requirements to just Fortran90 and C if this could be rewritten.
But let's quit all this and get some real work done. There is no way that NAB
will become C++, and no way that gleap or dock will not be C++. Right now, no
one is willing to work on bondtype.C or elsize.cc, so those questions are
moot.
Received on Wed May 07 2008 - 06:07:43 PDT
