Professional Web Applications Themes

_T in ctype.h -- needed? - Mac Programming

The /usr/include/ctype.h file in Darwin 7.2 has a block of macros (_CTYPE_A, _CTYPE_C, etc.), and then a block of synonyms (_A = _CTYPE_A, etc) with the comment "backward compatibility". Alas, this collides with cross-platform Mac-Win32 goals. Our house has adopted the Win32 convention that _T expands to empty for narrow-char builds and the wide-character "L" prefix for wide-char builds. So the question is... what's this backward compatibility about? I hacked (i.e. commented out) this line in ctype.h but that's not really too clean. We also have straight (non-Mac) FreeBSD installations here (version 4.8), and these one-letter macros do not appear ...

  1. #1

    Default _T in ctype.h -- needed?

    The /usr/include/ctype.h file in Darwin 7.2 has a block of macros
    (_CTYPE_A, _CTYPE_C, etc.), and then a block of synonyms (_A =
    _CTYPE_A, etc) with the comment "backward compatibility".

    Alas, this collides with cross-platform Mac-Win32 goals. Our house has
    adopted the Win32 convention that _T expands to empty for narrow-char
    builds and the wide-character "L" prefix for wide-char builds.

    So the question is... what's this backward compatibility about? I
    hacked (i.e. commented out) this line in ctype.h but that's not really
    too clean. We also have straight (non-Mac) FreeBSD installations here
    (version 4.8), and these one-letter macros do not appear in ctype.h.

    Andrew
    com
    Andrew Guest

  2. #2

    Default Re: _T in ctype.h -- needed?

    In article <google.com>,
    com (Andrew Duncan) wrote:
     

    If you truely desire portable code you'll need to change your
    existing sources to comply with the language standard.

    Essentially the use of leading underscores are reserved for the
    sole use of the compiler vendor.

    For your reference and quoted from the C++ standards doent:

    INTERNATIONAL STANDARD
    ISO.IEC 14882

    PORGRAMMNING LANGUAGES -- C++

    Page 321

    Section 18.4.3.1.2 Global names

    Certain sets of names and functions signatures are always reserved
    to the implementation:

    Each name that contains a double underscore (__) or begins
    with and underscore followed by an uppercase letter (.11) is
    reserved to the implementation for any use.

    Each name that begins with and underscore is reserved to the
    implementation for use in the global namespace.
    lloyd Guest

  3. #3

    Default Re: _T in ctype.h -- needed?

    In article <west.earthlink.net>,
    lloyd <net> wrote:
     [/ref]
     

    True, but in this case one compiler vendor (Apple) conflicts with
    another compiler vendor (Microsoft). Since Apple's use of _T is
    probably not necessary, it'd be nice if their ctype.h didn't include
    that section.

    Unfortunately, I'm not sure there's a good solution other than changing
    every copy of ctype.h on the systems you use.

    -Eric

    --
    Eric Albert stanford.edu
    http://rescomp.stanford.edu/~ejalbert/
    Eric Guest

  4. #4

    Default Re: _T in ctype.h -- needed?

    In article <stanford.edu>,
    Eric Albert <stanford.edu> wrote:
     [/ref]

    >
    > True, but in this case one compiler vendor (Apple) conflicts with
    > another compiler vendor (Microsoft). Since Apple's use of _T is
    > probably not necessary, it'd be nice if their ctype.h didn't include
    > that section.
    >
    > Unfortunately, I'm not sure there's a good solution other than changing
    > every copy of ctype.h on the systems you use.
    >
    > -Eric[/ref]

    It is the compiler venders reserved right, according to the
    standards doent.

    This same conflict will likely recur if, and, or when, they adapt
    another compiler.

    Look, every programmer brought on board the project will need to
    be told, or reminded, that a change is need to the compilers
    system headers after the installation of the development tools.

    Every time!

    The real solution, though the stubborn will probably reject it, is
    to pass valid garenteed non-conflicting symbols to the compiler in
    the first place.

    I've run into this same issue whenever I've started working with
    Windows programmers on an existing project.

    Use the extra effort in the RIGHT place...
    lloyd Guest

  5. #5

    Default Re: _T in ctype.h -- needed?

    Hi Eric,


    Eric Albert <stanford.edu> writes: 

    No. You can't use Microsoft's compiler in conjunction with Apple's
    compiler, so there is no conflict between the two. The _T identifier
    is reserved for the compiler, so Microsoft can define this identifier,
    and it can even tell you to use it, as a non-portable compiler
    extension to be used with Windows-only code.

    But your code can't define it, according to the rules. If you define
    it despite the prohibition, you are on your own and you will get
    conflicts.
     

    You can change your code to remove the bug that it currently has. You
    can e.g. use just T, that's a non-prohibited identifier.


    It would be nice if standard compilers would warn you about such
    illegal identifiers, and a lot of code would be written differently if
    the compilers did that. But that compilers don't bother to diagnose
    this doesn't change the rules.


    benny
    Benjamin Guest

  6. #6

    Default Re: _T in ctype.h -- needed?

    Yes, clearly the "right and proper" thing to do is use our own macro.
    That's a *lot* of search-and-replace, many thousands of occurrences in
    our Win32 code. Currently I'm the only Mac developer so hacking the
    ctype.h works fine...as long as we don't run afoul of the "backward
    compatibility" issue mentioned in the header comment. I was wondering
    if that's a Mac OS 9 thing or some other mysterious FreeBSD thing.
    Andrew Guest

  7. #7

    Default Re: _T in ctype.h -- needed?

    In article <google.com>,
    com (Andrew Duncan) wrote:
     

    Educating the Windows programmers and then changing the source is
    the thing to do. But of the 2, educating the Windows programmers
    is a MUCH harder task than changes to the source files.

    It shouldn't take more than a couple of hours once a convention
    has been agreed upon by all parties.

    If I were you I'd talk to the lead programmers, explain the
    situation - nicely of course, so that they don't feel they are
    being belittled or chastised in any way - and agree upon the new
    convention.
    lloyd Guest

  8. #8

    Default Re: _T in ctype.h -- needed?

    In article <google.com>,
    com (Andrew Duncan) wrote:
     

    It's a FreeBSD thing. Nearly none of the headers under /usr/include on
    Mac OS X are from Mac OS 9.

    -Eric

    --
    Eric Albert stanford.edu
    http://rescomp.stanford.edu/~ejalbert/
    Eric Guest

  9. #9

    Default Re: _T in ctype.h -- needed?

    com (Andrew Duncan) writes: 

    It's a C language thing.
    Benjamin Guest

Similar Threads

  1. LoadControl and CType error
    By Justin Dutoit in forum ASP.NET Building Controls
    Replies: 0
    Last Post: February 23rd, 09:31 AM
  2. Using CType with grid data
    By eagle in forum ASP.NET Data Grid Control
    Replies: 1
    Last Post: August 19th, 01:58 PM
  3. Strange error from: Dim myState As Object() = CType(savedState, Object())
    By lisa@starways.net in forum ASP.NET Building Controls
    Replies: 3
    Last Post: April 11th, 04:56 PM
  4. Replies: 5
    Last Post: July 15th, 01:50 PM
  5. How to check if CType(e.Item.DataItem, DataRowView) is DBNULL
    By Rob Wire in forum ASP.NET Data Grid Control
    Replies: 2
    Last Post: July 30th, 04:24 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139