octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: isascii/toascii with MSVC


From: John W. Eaton
Subject: Re: isascii/toascii with MSVC
Date: Mon, 25 Feb 2008 16:29:30 -0500

On 25-Feb-2008, Michael Goffioul wrote:

| On 2/25/08, John W. Eaton <address@hidden> wrote:
| > | >  #include <cctype>
| > | >
| > | >  inline int xisascii (int c) { return isascii (c); }
| > | >  inline int xtoascii (int c) { return toascii (c); }
| > | >
| > | >  #undef isascii
| > | >  #undef toascii
| > |
| > | This should be fine: put this into some lo-cctype.h header and
| > | include it in ov-base.h should be enough to make MSVC happy
| > | (I'll merge my repo with yours and try to recompile once you
| > | commit the change).
| >
| > OK, after looking at this some more I noticed that there could be some
| > trouble if we use the method I outlined above.  So I made the
| > following change instead.  I didn't really want to have to rename the
| > octave_value mapper methods (to xisascii, etc.) but I really don't see
| > any other solution that will work reliably if some vendor converts
| > other functions declared in ctype.h to be macros.
| 
| Just for the record, what did not work with the solution above?
| (I thought it would work OK).

It looked like trouble to me if <cctype> happened to be included
somewhere before lo-cctype.h, or if some other header file included
after lo-cctype expected to see the names that are now undefined.
Also, if other ctype functions were defined as macros, those would
also need to be undefined in lo-cctype.h, and then all uses in the
Octave sources would have to change to use the X name.  It just seemed
better to avoid those potential problems.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]