[sword-devel] 1.5.3 + optimizations

[Gregg Stubbendieck]

Hi all,

Hope you don't mind an interjection from out of nowhere.  I've only recently
come across your project and am very intrigued about it.  I think that this
project is about the best use of the open source concept that could be
conceived.

isalpha(), et. al., are declared in <ctypes.h>.  They are C functions--not
in std namespace.  This (compiling under 3.0.3) is the reason I subscribed
to the devel mailing list.  In my experience, including ctypes.h in the
offending source file fixes that problem just fine and I think you get to
the link stage before the next problem arises.  My compiler, using gcc
3.0.3, was not able to find the case insensitive versions of the string
functions (stricmp(), etc.).  I've never actually used the case insensitive
versions of the string functions and am led to wonder whether they're part
of the ANSI standard.  I got stuck there since it looks like a fix would
require some research and code change.  I'm curious whether the C++ string
class has the functions that are desired, otherwhise I would consider the
regex library, which does apparently have the advantage of a POSIX standard.

As noted below, as long as there aren't name clashes between the namespaces
in use, it's possible just to put a "using namespace std;" statement at the
top of a pre-standard bit of code.  The problem then becomes conditionally
including that statement depending on the vintage of your compiler.  This
seems like a situation where autoconf and/or automake would be handy.  I
have to believe that autoconf can generate a test for the presence of
namespace std or not.  This solution might approach the desired elegance.
Unfortunately, saying that, I've nearly reached the limits of my expertise
on those tools.

The -march=XXX and -mcpu=XXX flags should only be necessary if you're cross
compiling, right?  If I'm compiling for my system using a locally compiled
version of the compiler (or at least one native to my processor) I should be
able to leave those options off, I think.

Gregg

----- Original Message -----
From: "David White" <dave@whitevine.com>
To: <sword-devel@crosswire.org>
Sent: Tuesday, February 19, 2002 2:20 AM
Subject: Re: [sword-devel] 1.5.3 + optimizations


> This is likely because in C++, all C runtime functions (isalpha,
> isdigit, strcmp, strncpy and so on and so forth) are meant to be in the
> std namespace, rather than in the global namespace. So, you have to use
> std::isalpha instead of isalpha (and likewise for all C runtime
> functions).
>
> Many C++ compilers, including gcc didn't implement this for a long time.
> gcc has only just implemented it in 3.0, and MSVC++ still doesn't,
> although likely will in the next version.
>
> This is a fairly difficult problem to solve elegantly (Note that using
> the declaration "using namespace std;" is *not* elegant :), since the
> code will be expected to compile on both types of compilers (although
> note that lots of older-style compilers have std:: as a synonym for ::,
> so the newer solution should work with them anyway; however I don't
> think this holds for MSVC++. A good article on the topic can be found at
> http://www.gotw.ca/gotw/053.htm although it deals largely with code that
> isn't expected to work on both kinds of compilers.
>
> Of course, the problem can largely be side-stepped by using C++-style
> functions instead of C style functions, which are more typesafe and
> generally better style (imho of course :) than their C equivalents. Of
> course, some C-style functions such as those declared in ctype have no
> C++ equivalent.
>
> Blessings,
>
> -David.
>
> On Tue, 2002-02-19 at 18:55, David Blue wrote:
> > On Wednesday 13 February 2002 06:48 pm, you wrote:
> > > Hello all,
> > > If there is anything else pressing that anyone wants to get in, please
> > > send me a patch soon, or suggest it here on the list and see if anyone
> > > is willing to do it.
> >
> > Not so much as code that needs to go in but will 1.5.3 be compatible
with
> > gcc3? I've got a system that lets me swap back and forth between
gcc3.0.3 and
> > gcc2.96 and sword 1.5.2 refuses to compile under gcc3 it can't find the
> > prototypes for the isalpha function or some such thing. I can produce
the
> > exact error if you need it. I know it's not just my system however,
since it
> > sucessfully compiles under gcc2.96 (though I can't compile chetah with
gcc3
> > if it is apparently ;_;) Oh, and in gcc3 the -m486 switch is deprecated
and
> > now uses -march=ix86 (x can be 3-6) or -mcpu=ix86.
>
>
>