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

Re: Defining declarations located in main.c

Expand Messages
  • Bram Moolenaar
    ... This is always tricky, various dependencies exist. It s mostly a lot easier to keep everything, and add the thing that you want to test near the end of
    Message 1 of 3 , Apr 2, 2003
    • 0 Attachment
      Walter Briscoe wrote:

      > In a recent thread, it would have been useful to replace Vim's main.c
      > with the following code.
      > /* Dummy Vim to exercise mch_FullName() */
      >
      > typedef unsigned char char_u;
      > # define __ARGS(x) x
      > int mch_FullName __ARGS((char_u *fname, char_u *buf, int len, int force));
      >
      > #include <stdio.h>
      >
      > int main(int argc, char **argv) {
      > char_u buf[256];
      >
      > printf("argc = %d, argv[1] = \"%s\"\n", argc, argv[1]);
      > (void)mch_FullName(argv[1], buf, sizeof buf, 1);
      > printf("buf = \"%s\"\n", buf);
      >
      > return 0;
      > }
      >
      > (What I actually did was construct a one module program with the
      > relevant pieces of Vim; doing this is a tedious process.)

      This is always tricky, various dependencies exist. It's mostly a lot
      easier to keep everything, and add the thing that you want to test near
      the end of main(). That a lot of things won't ever be used is
      irrelevant.

      > Also main() is something of a monolith consisting
      > of about 1800 lines of code. I find it difficult to get a handle on such
      > extended functions and would like to factor out a series of static
      > functions. My preference would be to have all function communication
      > done with parameters; that can look a bit unwieldy; I think it shows the
      > complication inherent in the underlying design. The cost of this is a
      > small amount of communication code, my time in producing it, and the
      > cost of solving any bugs I let out the door. The first extra benefit is
      > that it allows next commands in a debugger to run a chunk of code and
      > step where a closer focus is needed. It also makes any desired change
      > much easier to implement.

      Yes, main() has grown into a very long function, it's not nice. Some
      parts could be split off to separate functions.

      > I have done this in the past for my own purposes; the work got scrapped
      > when I absorbed patches. I want to avoid hitting Bram with a change
      > which requires an extended dialog to establish its value.
      > So, I'm starting the dialog before!

      If you really think this is worth working on, explain me what to change,
      rather than sending a diff. My code is always a few steps ahead and the
      code in main() does change, thus I would have to check every diff you
      send carefully. Making the changes myself is easier and avoids subtle
      mistakes.

      Don't overestimate the advantages of splitting up main(). The resulting
      code won't be simpler, only the overview would be better.

      --
      FATHER: Who are you?
      PRINCE: I'm ... your son ...
      FATHER: Not you.
      LAUNCELOT: I'm ... er ... Sir Launcelot, sir.
      "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
      \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
      \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
    • Walter Briscoe
      In message of Wed, 2 Apr 2003 23:34:37 in , Bram Moolenaar writes ... [snip] ... We agree in
      Message 2 of 3 , Apr 2, 2003
      • 0 Attachment
        In message <200304022134.h32LYb414977@...> of Wed, 2 Apr 2003
        23:34:37 in , Bram Moolenaar <Bram@...> writes
        >
        >Walter Briscoe wrote:
        >
        >> In a recent thread, it would have been useful to replace Vim's main.c
        >> with the following code.
        [snip]
        >
        >This is always tricky, various dependencies exist. It's mostly a lot
        >easier to keep everything, and add the thing that you want to test near
        >the end of main(). That a lot of things won't ever be used is
        >irrelevant.
        >
        >> Also main() is something of a monolith consisting
        >> of about 1800 lines of code. I find it difficult to get a handle on such
        >> extended functions and would like to factor out a series of static
        >> functions. My preference would be to have all function communication
        >> done with parameters; that can look a bit unwieldy; I think it shows the
        >> complication inherent in the underlying design. The cost of this is a
        >> small amount of communication code, my time in producing it, and the
        >> cost of solving any bugs I let out the door. The first extra benefit is
        >> that it allows next commands in a debugger to run a chunk of code and
        >> step where a closer focus is needed. It also makes any desired change
        >> much easier to implement.
        >
        >Yes, main() has grown into a very long function, it's not nice. Some
        >parts could be split off to separate functions.
        We agree in principle.

        >
        >> I have done this in the past for my own purposes; the work got scrapped
        >> when I absorbed patches. I want to avoid hitting Bram with a change
        >> which requires an extended dialog to establish its value.
        >> So, I'm starting the dialog before!
        >
        >If you really think this is worth working on, explain me what to change,
        >rather than sending a diff. My code is always a few steps ahead and the
        >code in main() does change, thus I would have to check every diff you
        >send carefully. Making the changes myself is easier and avoids subtle
        >mistakes.
        I will continue this in private email. The process is likely to be slow;
        I will make small changes and present them as both text and diffs. Let
        us see what we can cook together!

        >
        >Don't overestimate the advantages of splitting up main(). The resulting
        >code won't be simpler, only the overview would be better.
        I think what you say is similar to my words: "... all function
        communication done with parameters; that can look a bit unwieldy; I
        think it shows the complication inherent in the underlying design.".
        --
        Walter Briscoe
      Your message has been successfully submitted and would be delivered to recipients shortly.