Loading ...
Sorry, an error occurred while loading the content.

Preprocessor problems (C/C++)

Expand Messages
  • Tim
    Hi all I ve been noticing some various problems with the way Vim (or the syntax file, I m not too familiar with this stuff) some of this. For example: int
    Message 1 of 4 , Feb 4, 2000
    • 0 Attachment
      Hi all

      I've been noticing some various "problems" with the way Vim (or the syntax
      file, I'm not too familiar with this stuff) some of this. For example:

      int foo(
      #ifdef _WIN32
      HWND h )
      #else
      int n ) <-- this bracket is highlighed as an error
      #end

      Can we possibly fix that? I'm not sure where to begin...

      Another thing, which I'm sure a lot of people do:

      #ifdef __cplusplus
      extern "C" {
      #endif
      // if cindent (or ai) is on, then these always get indented.

      Is it possible, since the protection around C++ is so popular, to exempt
      this? We got around this by defining a macro for extern "C" { - sort of
      hackish...

      In general, if people do funny things with these ifdefs, Vim will do funny
      things...like if braces or brackets don't "match" because of ifdefs, then %
      on a bracket don't work...

      I'm not sure if this is fixable at all, or how difficult it would be, or
      whether its a syntax file change only, or involves some source changes...

      What do you guys think about this? There's prolly more preprocessor
      obscurities that other people have experienced...

      Thanks

      - Tim
    • Johannes Zellner
      On Sat, 5 Feb 2000, Tim wrote: [...] ... [...] here s just a quick workaround: #ifdef __cplusplus extern C { // } (keep vim happy) #endif you can do that
      Message 2 of 4 , Feb 4, 2000
      • 0 Attachment
        On Sat, 5 Feb 2000, Tim wrote:

        [...]
        > #ifdef __cplusplus
        > extern "C" {
        > #endif
        [...]

        here's just a quick workaround:

        #ifdef __cplusplus
        extern "C" { // } (keep vim happy)
        #endif

        you can do that with the other ()'s too naturally.

        --
        Johannes
      • Robert Webb
        ... This works, but if the code is shared with other people not using vim, or if you re just browsing someone else s source code, you can t really go adding
        Message 3 of 4 , Feb 7, 2000
        • 0 Attachment
          > On Sat, 5 Feb 2000, Tim wrote:
          >
          > [...]
          > > #ifdef __cplusplus
          > > extern "C" {
          > > #endif
          > [...]
          >
          > here's just a quick workaround:
          >
          > #ifdef __cplusplus
          > extern "C" { // } (keep vim happy)
          > #endif

          This works, but if the code is shared with other people not using vim, or if
          you're just browsing someone else's source code, you can't really go adding
          bizarre constructs like this to the code.

          And vim's "%" command doesn't work anymore with the above braces anyway.

          Rob.
        • Bram Moolenaar
          ... No, this cannot be fixed. It s near to impossible to take the preprocessor into account for syntax highlighting. Perhaps in the example you give it could
          Message 4 of 4 , Feb 9, 2000
          • 0 Attachment
            Tim wrote:

            > I've been noticing some various "problems" with the way Vim (or the syntax
            > file, I'm not too familiar with this stuff) some of this. For example:
            >
            > int foo(
            > #ifdef _WIN32
            > HWND h )
            > #else
            > int n ) <-- this bracket is highlighed as an error
            > #end
            >
            > Can we possibly fix that? I'm not sure where to begin...

            No, this cannot be fixed. It's near to impossible to take the preprocessor
            into account for syntax highlighting. Perhaps in the example you give it
            could work, but not for this one:

            int foo(
            #ifdef _WIN32
            HWND h )
            #endif
            #ifdef UNIX
            int n ) <-- this bracket is highlighed as an error
            #end

            The best solution is to move the bracket outside of the #ifdef:

            int foo(
            #ifdef _WIN32
            HWND h
            #else
            int n
            #end
            )

            > Another thing, which I'm sure a lot of people do:
            >
            > #ifdef __cplusplus
            > extern "C" {
            > #endif
            > // if cindent (or ai) is on, then these always get indented.
            >
            > Is it possible, since the protection around C++ is so popular, to exempt
            > this? We got around this by defining a macro for extern "C" { - sort of
            > hackish...

            It is a hack. I consider this a problem in C++. One of the reasons I don't
            like C++....

            I don't really like to handle specific cases like this. The indenting code is
            quite complicated already. Adding more magic to it makes it more messy.

            You could use this trick: put this in a separate file (or at the end of a
            header file that's always included):

            #ifdef __cplusplus
            # define CPPSTART extern "C" { /* matching } */
            #else
            # define CPPSTART /* empty */
            #endif

            And use "CPPSTART" in the file.

            > In general, if people do funny things with these ifdefs, Vim will do funny
            > things...like if braces or brackets don't "match" because of ifdefs, then %
            > on a bracket don't work...

            Right. You can use a bracket in a comment to match it, when needed. Like in
            the example above.

            > I'm not sure if this is fixable at all, or how difficult it would be, or
            > whether its a syntax file change only, or involves some source changes...
            >
            > What do you guys think about this? There's prolly more preprocessor
            > obscurities that other people have experienced...

            The preprocessor is a nice tool to create a mess. That's why it was banned
            when Java was designed. It's needed for C and C++ though, to make the code
            portable. Java is portable without these tricks. Java does have other
            problems though...

            --
            (letter from Mark to Mike, about the film's probale certificate)
            For an 'A' we would have to: Lose as may shits as possible Take Jesus
            Christ out, if possible Loose "I fart in your general direction" Lose
            "the oral sex" Lose "oh, fuck off" Lose "We make castanets out of your
            testicles"
            "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

            /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
            \ \ Vim: http://www.vim.org ICCF Holland: http://www.vim.org/iccf / /
          Your message has been successfully submitted and would be delivered to recipients shortly.