Re: old-style cast warnings

[Daniel J Sebald]

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.