[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: old-style cast warnings
From: |
Daniel J Sebald |
Subject: |
Re: old-style cast warnings |
Date: |
Wed, 05 Sep 2012 13:35:57 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
On 09/05/2012 12:33 PM, Rik wrote:
9/5/12
Dan,
I don't know if you're still bothered by it, but I think I know a way to
mask the warnings in the parse-tree directory. The problem is that we use
auto-generated code from the outside utilities Flex and Yacc. These
programs are going to be using old-style casts and there isn't much we can
do about that.
In the current build system there is a rule which attempts to turn off the
old-style cast warning. It is in parse-tree/module.mk and is shown below.
lex.lo lex.o oct-parse.lo oct-parse.o: \
AM_CXXFLAGS := $(filter-out -Wold-style-cast, $(AM_CXXFLAGS))
The problem is that Automake does not support per-object compilation rules
so the two lines above do nothing. But, Automake does detail how to
emulate per-object rules here
(http://www.gnu.org/software/automake/manual/html_node/Per_002dObject-Flags.html).
This looks like a good strategy for smaller projects. But with Octave
where there are many Makefiles I wonder if the idea could get lost in
the mix.
It would be quite easy to use their strategy and turn off the warnings for
these particular files which we know are going to have old code constructs.
Plus, it seems to me that suppressing the warnings is skirting the issue
slightly. I'm fine with leaving in warnings so long as their purpose
serves the same as does a "FIXME", i.e., something to eventually be
addressed. (There has been a bit too liberal use of both these.)
The issue boils down to the following. Both Flex and Qhull were written
with C in mind, not C++. They really aren't intended to be compiled
under C++, although that works. Both of these "libraries" have C++
interfaces under development. At first glimpse, I'd say the Flex C++
interface is further along and better designed than is the Qhull interface.
My suggestion would be:
1) Leave Flex warnings in place and aim for utilizing Flex C++ a year
from now, say, another TODO summer-of-code project. Since Octave is
predominantly C++ now and Flex is a key component, it seems worthwhile
that someone attempt that and see how it goes.
2) Qhull, I don't know. Convex hull is sort of a small feature of
Octave. Also, written as it is using macros is really in the C realm.
Macros are an approach that creates really dense, efficient
code--assembly, C, embedded, that sort of thing. I don't see the
benefit of moving this to C++ realm by attempting the Qhull C++
interface. There needs to be a more compelling reason for messing with
that code. Given that, I would think though that if Qhull could be
compiled under "C" as opposed to C++ (i.e., convert it to a ".c" file)
then having some simple hook for which C++ code can call the routines
might be a good way to address the warnings.
If you're interested this seems like a reasonable solution or we can just
let it ride.
Quoting C.F.Turner, "let it ride". But thanks.
Dan
PS: Will followup with gl2ps post, another TODO list candidate.