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

Why C? If so how is the best way to have simple lists ?

Expand Messages
  • Marc Weber
    Well - I don t want to discuss the topic. I just want to know how to do basic stuff the Vim way efficiently. C++ is not perfect, and probably its easiy to
    Message 1 of 20 , Jun 7, 2013
    View Source
    • 0 Attachment
      Well - I don't want to discuss the topic.

      I just want to know how to do basic stuff "the Vim way" efficiently.

      C++ is not perfect, and probably its easiy to get things wrong.
      But at least it provides standard ways for standard tasks, such as
      arrays/vectors/maps/hashes whatsoever.

      Eg buffer.c contains:


      /*
      * put new buffer at the end of the buffer list
      */
      buf->b_next = NULL;
      if (firstbuf == NULL) /* buffer list is empty */
      {
      buf->b_prev = NULL;
      firstbuf = buf;
      }
      else /* append new buffer at end of list */
      {
      lastbuf->b_next = buf;
      buf->b_prev = lastbuf;
      }
      lastbuf = buf;


      which is not bad. But if you need the same feature again: a linked list
      like whatsoveer structure, it looks like the standard way is to write
      the same code again. Its taking programmers time and is more likely to
      be wrong.

      I personally don't want to spend time on thinking about how to use
      malloc, realoc or such for simple things like lists, maps, ...

      Thus is there a standard way, a preprocessor like library which gets the
      job done? something like:

      define_list(vim_buffer);

      providing functions like
      vim_buffer_list_new()
      vim_buffer_list_add(...)
      vim_buffer_list_remove(...)

      ?

      Does it make sense to port Vim to C++, just to use some very basic C++
      like features, such as vector, map and so on?
      If not - can we document why?

      I know that Vim has a long history, but the future of Vim is likely to
      be longer than its history.

      Does Vim run on any platforms only supporting C, not C++?

      Sorry for having to ask such a stupid question. Its about simple
      features like "make vim populate quickfix in realtime, so that the 4sec
      issue I talked about goes away".

      I expect that Vim's future will be longer than its (long) history was.
      So its worth using simple improvements, too.

      If you think this question is nonsense, make me understand why.

      So which is the reason sticking to C only, and which is the reason not
      introducing a template library for simple things like lists?

      If moving to C++ is not an option, but moving ot a tmeplate library is,
      is there one you would recommend?

      I want to have a native implementation for vim-addon-async for example.

      Marc Weber

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Ben Fritz
      ... If we don t move it, we could at least write some utility modules that we use over and over whenever we need that code. Reuse may not be as nice as a real
      Message 2 of 20 , Jun 7, 2013
      View Source
      • 0 Attachment
        On Friday, June 7, 2013 8:49:12 PM UTC-5, MarcWeber wrote:
        >
        >
        > I personally don't want to spend time on thinking about how to use
        >
        > malloc, realoc or such for simple things like lists, maps, ...
        >
        >
        >
        > Thus is there a standard way, a preprocessor like library which gets the
        >
        > job done? something like:
        >
        >
        >
        > define_list(vim_buffer);
        >
        >
        >
        > providing functions like
        >
        > vim_buffer_list_new()
        >
        > vim_buffer_list_add(...)
        >
        > vim_buffer_list_remove(...)
        >
        >
        >
        > ?
        >
        >
        >
        > Does it make sense to port Vim to C++, just to use some very basic C++
        >
        > like features, such as vector, map and so on?
        >
        > If not - can we document why?
        >

        If we don't move it, we could at least write some utility modules that we use over and over whenever we need that code. Reuse may not be as nice as a real library but it would be better than nothing. And we would have full control of optimizing it, etc., and it would be available on whatever system we put Vim on.

        Some may already be there, I don't really know.

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Nikolay Pavlov
        ... list */ ... It is completely possible to define a linked list in one of the following ways: 1. Use fixed offset in structure: i.e. pointers to next and
        Message 3 of 20 , Jun 8, 2013
        View Source
        • 0 Attachment


          On Jun 8, 2013 5:48 AM, "Marc Weber" <marco-oweber@...> wrote:
          >
          > Well - I don't want to discuss the topic.
          >
          > I just want to know how to do basic stuff "the Vim way" efficiently.
          >
          > C++ is not perfect, and probably its easiy to get things wrong.
          > But at least it provides standard ways for standard tasks, such as
          > arrays/vectors/maps/hashes whatsoever.
          >
          > Eg buffer.c contains:
          >
          >
          >         /*
          >          * put new buffer at the end of the buffer list
          >          */
          >         buf->b_next = NULL;
          >         if (firstbuf == NULL)           /* buffer list is empty */
          >         {
          >             buf->b_prev = NULL;
          >             firstbuf = buf;
          >         }
          >         else                            /* append new buffer at end of list */
          >         {
          >             lastbuf->b_next = buf;
          >             buf->b_prev = lastbuf;
          >         }
          >         lastbuf = buf;
          >
          >
          > which is not bad. But if you need the same feature again: a linked list
          > like whatsoveer structure, it looks like the standard way is to write
          > the same code again. Its taking programmers time and is more likely to
          > be wrong.
          >
          > I personally don't want to spend time on thinking about how to use
          > malloc, realoc or such for simple things like lists, maps, ...
          >
          > Thus is there a standard way, a preprocessor like library which gets the
          > job done? something like:
          >
          >     define_list(vim_buffer);
          >
          > providing functions like
          >     vim_buffer_list_new()
          >     vim_buffer_list_add(...)
          >     vim_buffer_list_remove(...)
          >
          > ?
          >
          > Does it make sense to port Vim to C++, just to use some very basic C++
          > like features, such as vector, map and so on?
          > If not - can we document why?
          >
          > I know that Vim has a long history, but the future of Vim is likely to
          > be longer than its history.
          >
          > Does Vim run on any platforms only supporting C, not C++?
          >
          > Sorry for having to ask such a stupid question. Its about simple
          > features like "make vim populate quickfix in realtime, so that the 4sec
          > issue I talked about goes away".
          >
          > I expect that Vim's future will be longer than its (long) history was.
          > So its worth using simple improvements, too.
          >
          > If you think this question is nonsense, make me understand why.
          >
          > So which is the reason sticking to C only, and which is the reason not
          > introducing a template library for simple things like lists?
          >
          > If moving to C++ is not an option, but moving ot a tmeplate library is,
          > is there one you would recommend?
          >
          > I want to have a native implementation for vim-addon-async for example.
          >
          > Marc Weber

          It is completely possible to define a linked list in one of the following ways:

          1. Use fixed offset in structure: i.e. pointers to next and previous items are always the first one and list-manipulating functions just cast the buf_T* to linked_list_T* which is a structure that has nothing but next and previous pointers. This approach is extensively used in python for PyObject structures.
          2. Your suggestion with preprocessor library. Note though that for portability reasons string concatenation should not be used in this library, limiting its usability. I guess moving to C++ can't be done for the same reasons.

          > --
          > --
          > You received this message from the "vim_dev" maillist.
          > Do not top-post! Type your reply below the text you are replying to.
          > For more information, visit http://www.vim.org/maillist.php
          >
          > ---
          > You received this message because you are subscribed to the Google Groups "vim_dev" group.
          > To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          > For more options, visit https://groups.google.com/groups/opt_out.
          >
          >

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php
           
          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
           
           
        • Mike Williams
          ... See BSD list and tree macros as described and linked from here: http://ivoras.sharanet.org/freebsd/usetree.html ... Since the code base still assumes
          Message 4 of 20 , Jun 8, 2013
          View Source
          • 0 Attachment
            On 08/06/2013 02:49, Marc Weber wrote:
            > Well - I don't want to discuss the topic.
            >
            > I just want to know how to do basic stuff "the Vim way" efficiently.
            >
            > C++ is not perfect, and probably its easiy to get things wrong.
            > But at least it provides standard ways for standard tasks, such as
            > arrays/vectors/maps/hashes whatsoever.
            >
            > Eg buffer.c contains:
            >
            >
            > /*
            > * put new buffer at the end of the buffer list
            > */
            > buf->b_next = NULL;
            > if (firstbuf == NULL) /* buffer list is empty */
            > {
            > buf->b_prev = NULL;
            > firstbuf = buf;
            > }
            > else /* append new buffer at end of list */
            > {
            > lastbuf->b_next = buf;
            > buf->b_prev = lastbuf;
            > }
            > lastbuf = buf;
            >
            >
            > which is not bad. But if you need the same feature again: a linked list
            > like whatsoveer structure, it looks like the standard way is to write
            > the same code again. Its taking programmers time and is more likely to
            > be wrong.
            >
            > I personally don't want to spend time on thinking about how to use
            > malloc, realoc or such for simple things like lists, maps, ...
            >
            > Thus is there a standard way, a preprocessor like library which gets the
            > job done?

            See BSD list and tree macros as described and linked from here:

            http://ivoras.sharanet.org/freebsd/usetree.html

            > something like:
            >
            > define_list(vim_buffer);
            >
            > providing functions like
            > vim_buffer_list_new()
            > vim_buffer_list_add(...)
            > vim_buffer_list_remove(...)
            >
            > ?
            >
            > Does it make sense to port Vim to C++, just to use some very basic C++
            > like features, such as vector, map and so on?
            > If not - can we document why?

            Since the code base still assumes prototypes are not supported, nor some
            long standing basic types like ptrdiff_t, working out the common minimal
            C++ language support at this stage would be a bit of a nightmare.

            Perhaps instead of everyone doing mad dashes to new features we could
            start on starting to refactor the code base for such things with all the
            benefits it could bring.

            2ps worth.

            > I know that Vim has a long history, but the future of Vim is likely to
            > be longer than its history.
            >
            > Does Vim run on any platforms only supporting C, not C++?
            >
            > Sorry for having to ask such a stupid question. Its about simple
            > features like "make vim populate quickfix in realtime, so that the 4sec
            > issue I talked about goes away".
            >
            > I expect that Vim's future will be longer than its (long) history was.
            > So its worth using simple improvements, too.
            >
            > If you think this question is nonsense, make me understand why.
            >
            > So which is the reason sticking to C only, and which is the reason not
            > introducing a template library for simple things like lists?
            >
            > If moving to C++ is not an option, but moving ot a tmeplate library is,
            > is there one you would recommend?
            >
            > I want to have a native implementation for vim-addon-async for example.
            >
            > Marc Weber
            >


            Mike
            --
            This is certainly more fun than being hit with a hammer.

            --
            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Bram Moolenaar
            ... Yeah, basic C is missing containers. There are libraries for them, but there doesn t seem to be one clear winner. ... C++ is incredibly complex. The
            Message 5 of 20 , Jun 8, 2013
            View Source
            • 0 Attachment
              Marc Weber wrote:

              > Well - I don't want to discuss the topic.
              >
              > I just want to know how to do basic stuff "the Vim way" efficiently.
              >
              > C++ is not perfect, and probably its easiy to get things wrong.
              > But at least it provides standard ways for standard tasks, such as
              > arrays/vectors/maps/hashes whatsoever.
              >
              > Eg buffer.c contains:
              >
              >
              > /*
              > * put new buffer at the end of the buffer list
              > */
              > buf->b_next = NULL;
              > if (firstbuf == NULL) /* buffer list is empty */
              > {
              > buf->b_prev = NULL;
              > firstbuf = buf;
              > }
              > else /* append new buffer at end of list */
              > {
              > lastbuf->b_next = buf;
              > buf->b_prev = lastbuf;
              > }
              > lastbuf = buf;
              >
              >
              > which is not bad. But if you need the same feature again: a linked list
              > like whatsoveer structure, it looks like the standard way is to write
              > the same code again. Its taking programmers time and is more likely to
              > be wrong.
              >
              > I personally don't want to spend time on thinking about how to use
              > malloc, realoc or such for simple things like lists, maps, ...
              >
              > Thus is there a standard way, a preprocessor like library which gets the
              > job done? something like:
              >
              > define_list(vim_buffer);
              >
              > providing functions like
              > vim_buffer_list_new()
              > vim_buffer_list_add(...)
              > vim_buffer_list_remove(...)
              >
              > ?

              Yeah, basic C is missing containers. There are libraries for them, but
              there doesn't seem to be one clear winner.

              > Does it make sense to port Vim to C++, just to use some very basic C++
              > like features, such as vector, map and so on?
              > If not - can we document why?

              C++ is incredibly complex. The specification is 2000 pages. Only the
              top programmers can write C++ code that works properly. And then still
              make hard-to-debug mistakes. It's my daily work, I know what I'm
              talking about.

              Java is a lot easier to work with, but has too much overhead and is very
              resource-hungry.


              > I know that Vim has a long history, but the future of Vim is likely to
              > be longer than its history.
              >
              > Does Vim run on any platforms only supporting C, not C++?
              >
              > Sorry for having to ask such a stupid question. Its about simple
              > features like "make vim populate quickfix in realtime, so that the 4sec
              > issue I talked about goes away".
              >
              > I expect that Vim's future will be longer than its (long) history was.
              > So its worth using simple improvements, too.
              >
              > If you think this question is nonsense, make me understand why.
              >
              > So which is the reason sticking to C only, and which is the reason not
              > introducing a template library for simple things like lists?
              >
              > If moving to C++ is not an option, but moving ot a tmeplate library is,
              > is there one you would recommend?
              >
              > I want to have a native implementation for vim-addon-async for example.

              The solution I've been thinking of is www.zimbu.org.
              It produces C code, thus there should be a way to mix some parts written
              in Zimbu and some parts still written in C.

              --
              In a world without walls and borders, who needs windows and gates?

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ an exciting new programming language -- http://www.Zimbu.org ///
              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

              --
              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Shougo
              ... I think Zimbu is not bad choice. Zimbu is developped continuously by Mr.Bram and it fits with Vim development policy(Speed, compatibility, portability).
              Message 6 of 20 , Jun 8, 2013
              View Source
              • 0 Attachment
                2013年6月8日土曜日 19時56分38秒 UTC+9 Bram Moolenaar:
                > Marc Weber wrote:
                >
                >
                >
                > > Well - I don't want to discuss the topic.
                >
                > >
                >
                > > I just want to know how to do basic stuff "the Vim way" efficiently.
                >
                > >
                >
                > > C++ is not perfect, and probably its easiy to get things wrong.
                >
                > > But at least it provides standard ways for standard tasks, such as
                >
                > > arrays/vectors/maps/hashes whatsoever.
                >
                > >
                >
                > > Eg buffer.c contains:
                >
                > >
                >
                > >
                >
                > > /*
                >
                > > * put new buffer at the end of the buffer list
                >
                > > */
                >
                > > buf->b_next = NULL;
                >
                > > if (firstbuf == NULL) /* buffer list is empty */
                >
                > > {
                >
                > > buf->b_prev = NULL;
                >
                > > firstbuf = buf;
                >
                > > }
                >
                > > else /* append new buffer at end of list */
                >
                > > {
                >
                > > lastbuf->b_next = buf;
                >
                > > buf->b_prev = lastbuf;
                >
                > > }
                >
                > > lastbuf = buf;
                >
                > >
                >
                > >
                >
                > > which is not bad. But if you need the same feature again: a linked list
                >
                > > like whatsoveer structure, it looks like the standard way is to write
                >
                > > the same code again. Its taking programmers time and is more likely to
                >
                > > be wrong.
                >
                > >
                >
                > > I personally don't want to spend time on thinking about how to use
                >
                > > malloc, realoc or such for simple things like lists, maps, ...
                >
                > >
                >
                > > Thus is there a standard way, a preprocessor like library which gets the
                >
                > > job done? something like:
                >
                > >
                >
                > > define_list(vim_buffer);
                >
                > >
                >
                > > providing functions like
                >
                > > vim_buffer_list_new()
                >
                > > vim_buffer_list_add(...)
                >
                > > vim_buffer_list_remove(...)
                >
                > >
                >
                > > ?
                >
                >
                >
                > Yeah, basic C is missing containers. There are libraries for them, but
                >
                > there doesn't seem to be one clear winner.
                >
                >
                >
                > > Does it make sense to port Vim to C++, just to use some very basic C++
                >
                > > like features, such as vector, map and so on?
                >
                > > If not - can we document why?
                >
                >
                >
                > C++ is incredibly complex. The specification is 2000 pages. Only the
                >
                > top programmers can write C++ code that works properly. And then still
                >
                > make hard-to-debug mistakes. It's my daily work, I know what I'm
                >
                > talking about.
                >
                >
                >
                > Java is a lot easier to work with, but has too much overhead and is very
                >
                > resource-hungry.
                >
                >
                >
                >
                >
                > > I know that Vim has a long history, but the future of Vim is likely to
                >
                > > be longer than its history.
                >
                > >
                >
                > > Does Vim run on any platforms only supporting C, not C++?
                >
                > >
                >
                > > Sorry for having to ask such a stupid question. Its about simple
                >
                > > features like "make vim populate quickfix in realtime, so that the 4sec
                >
                > > issue I talked about goes away".
                >
                > >
                >
                > > I expect that Vim's future will be longer than its (long) history was.
                >
                > > So its worth using simple improvements, too.
                >
                > >
                >
                > > If you think this question is nonsense, make me understand why.
                >
                > >
                >
                > > So which is the reason sticking to C only, and which is the reason not
                >
                > > introducing a template library for simple things like lists?
                >
                > >
                >
                > > If moving to C++ is not an option, but moving ot a tmeplate library is,
                >
                > > is there one you would recommend?
                >
                > >
                >
                > > I want to have a native implementation for vim-addon-async for example.
                >
                >
                >
                > The solution I've been thinking of is www.zimbu.org.
                >
                > It produces C code, thus there should be a way to mix some parts written
                >
                > in Zimbu and some parts still written in C.

                I think Zimbu is not bad choice.
                Zimbu is developped continuously by Mr.Bram and it fits with Vim development policy(Speed, compatibility, portability).
                http://code.google.com/p/zimbu/source/list
                I can learn Zimbu if it needs for Vim develop.
                But unlike other languages, Zimbu developers are too few.

                How is the Go language?
                I think Go is similar to Zimbu.
                What are Zimbu advantages compared from Go language?

                >
                >
                >
                > --
                >
                > In a world without walls and borders, who needs windows and gates?
                >
                >
                >
                > /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                >
                > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                >
                > \\\ an exciting new programming language -- http://www.Zimbu.org ///
                >
                > \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                --
                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php

                ---
                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Shougo
                ... Sorry, I made mistake your name. ... This is correct: Zimbu is developped continuously by Mr.Moolenaar and it fits with Vim development policy(Speed,
                Message 7 of 20 , Jun 8, 2013
                View Source
                • 0 Attachment
                  2013年6月9日日曜日 2時09分04秒 UTC+9 Shougo:
                  > 2013年6月8日土曜日 19時56分38秒 UTC+9 Bram Moolenaar:
                  >
                  > > Marc Weber wrote:
                  >
                  > >
                  >
                  > >
                  >
                  > >
                  >
                  > > > Well - I don't want to discuss the topic.
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > > I just want to know how to do basic stuff "the Vim way" efficiently.
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > > C++ is not perfect, and probably its easiy to get things wrong.
                  >
                  > >
                  >
                  > > > But at least it provides standard ways for standard tasks, such as
                  >
                  > >
                  >
                  > > > arrays/vectors/maps/hashes whatsoever.
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > > Eg buffer.c contains:
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > > /*
                  >
                  > >
                  >
                  > > > * put new buffer at the end of the buffer list
                  >
                  > >
                  >
                  > > > */
                  >
                  > >
                  >
                  > > > buf->b_next = NULL;
                  >
                  > >
                  >
                  > > > if (firstbuf == NULL) /* buffer list is empty */
                  >
                  > >
                  >
                  > > > {
                  >
                  > >
                  >
                  > > > buf->b_prev = NULL;
                  >
                  > >
                  >
                  > > > firstbuf = buf;
                  >
                  > >
                  >
                  > > > }
                  >
                  > >
                  >
                  > > > else /* append new buffer at end of list */
                  >
                  > >
                  >
                  > > > {
                  >
                  > >
                  >
                  > > > lastbuf->b_next = buf;
                  >
                  > >
                  >
                  > > > buf->b_prev = lastbuf;
                  >
                  > >
                  >
                  > > > }
                  >
                  > >
                  >
                  > > > lastbuf = buf;
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > > which is not bad. But if you need the same feature again: a linked list
                  >
                  > >
                  >
                  > > > like whatsoveer structure, it looks like the standard way is to write
                  >
                  > >
                  >
                  > > > the same code again. Its taking programmers time and is more likely to
                  >
                  > >
                  >
                  > > > be wrong.
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > > I personally don't want to spend time on thinking about how to use
                  >
                  > >
                  >
                  > > > malloc, realoc or such for simple things like lists, maps, ...
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > > Thus is there a standard way, a preprocessor like library which gets the
                  >
                  > >
                  >
                  > > > job done? something like:
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > > define_list(vim_buffer);
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > > providing functions like
                  >
                  > >
                  >
                  > > > vim_buffer_list_new()
                  >
                  > >
                  >
                  > > > vim_buffer_list_add(...)
                  >
                  > >
                  >
                  > > > vim_buffer_list_remove(...)
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > > ?
                  >
                  > >
                  >
                  > >
                  >
                  > >
                  >
                  > > Yeah, basic C is missing containers. There are libraries for them, but
                  >
                  > >
                  >
                  > > there doesn't seem to be one clear winner.
                  >
                  > >
                  >
                  > >
                  >
                  > >
                  >
                  > > > Does it make sense to port Vim to C++, just to use some very basic C++
                  >
                  > >
                  >
                  > > > like features, such as vector, map and so on?
                  >
                  > >
                  >
                  > > > If not - can we document why?
                  >
                  > >
                  >
                  > >
                  >
                  > >
                  >
                  > > C++ is incredibly complex. The specification is 2000 pages. Only the
                  >
                  > >
                  >
                  > > top programmers can write C++ code that works properly. And then still
                  >
                  > >
                  >
                  > > make hard-to-debug mistakes. It's my daily work, I know what I'm
                  >
                  > >
                  >
                  > > talking about.
                  >
                  > >
                  >
                  > >
                  >
                  > >
                  >
                  > > Java is a lot easier to work with, but has too much overhead and is very
                  >
                  > >
                  >
                  > > resource-hungry.
                  >
                  > >
                  >
                  > >
                  >
                  > >
                  >
                  > >
                  >
                  > >
                  >
                  > > > I know that Vim has a long history, but the future of Vim is likely to
                  >
                  > >
                  >
                  > > > be longer than its history.
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > > Does Vim run on any platforms only supporting C, not C++?
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > > Sorry for having to ask such a stupid question. Its about simple
                  >
                  > >
                  >
                  > > > features like "make vim populate quickfix in realtime, so that the 4sec
                  >
                  > >
                  >
                  > > > issue I talked about goes away".
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > > I expect that Vim's future will be longer than its (long) history was.
                  >
                  > >
                  >
                  > > > So its worth using simple improvements, too.
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > > If you think this question is nonsense, make me understand why.
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > > So which is the reason sticking to C only, and which is the reason not
                  >
                  > >
                  >
                  > > > introducing a template library for simple things like lists?
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > > If moving to C++ is not an option, but moving ot a tmeplate library is,
                  >
                  > >
                  >
                  > > > is there one you would recommend?
                  >
                  > >
                  >
                  > > >
                  >
                  > >
                  >
                  > > > I want to have a native implementation for vim-addon-async for example.
                  >
                  > >
                  >
                  > >
                  >
                  > >
                  >
                  > > The solution I've been thinking of is www.zimbu.org.
                  >
                  > >
                  >
                  > > It produces C code, thus there should be a way to mix some parts written
                  >
                  > >
                  >
                  > > in Zimbu and some parts still written in C.
                  >
                  >
                  >
                  > I think Zimbu is not bad choice.
                  >
                  > Zimbu is developped continuously by Mr.Bram and it fits with Vim development policy(Speed, compatibility, portability).
                  >
                  > http://code.google.com/p/zimbu/source/list
                  >
                  > I can learn Zimbu if it needs for Vim develop.
                  >
                  > But unlike other languages, Zimbu developers are too few.
                  >
                  >
                  >
                  > How is the Go language?
                  >
                  > I think Go is similar to Zimbu.
                  >
                  > What are Zimbu advantages compared from Go language?
                  >
                  >
                  >
                  > >
                  >
                  > >
                  >
                  > >
                  >
                  > > --
                  >
                  > >
                  >
                  > > In a world without walls and borders, who needs windows and gates?
                  >
                  > >
                  >
                  > >
                  >
                  > >
                  >
                  > > /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                  >
                  > >
                  >
                  > > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                  >
                  > >
                  >
                  > > \\\ an exciting new programming language -- http://www.Zimbu.org ///
                  >
                  > >
                  >
                  > > \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                  Sorry, I made mistake your name.

                  > Zimbu is developped continuously by Mr.Bram and it fits with Vim development policy(Speed, compatibility, portability).

                  This is correct:

                  Zimbu is developped continuously by Mr.Moolenaar and it fits with Vim development policy(Speed, compatibility, portability).

                  --
                  --
                  You received this message from the "vim_dev" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • Marc Weber
                  ... I didn t ask about introducing all kinds of odities. I know that doing C++ proberly takes 2 years or more studying C++. Now you can shoot yourself into
                  Message 8 of 20 , Jun 8, 2013
                  View Source
                  • 0 Attachment
                    Excerpts from Bram Moolenaar's message of Sat Jun 08 12:56:38 +0200 2013:
                    > C++ is incredibly complex.
                    I didn't ask about introducing all kinds of odities. I know that doing
                    C++ proberly takes 2 years or more studying C++.

                    Now you can shoot yourself into your feet using any language.
                    I just want "sane collections" - and C++ seems to provide them.

                    That's why I consider using a C++ subset to be an option.

                    With zimbu I see one issue: Is it possible to rewirte "one collection
                    list" only which will be found in many files?

                    I guess you have to rewrite the whole .c file using zimbu then.

                    This would also force everybody to learn zimbu. While I may agree that
                    its "yet another nice language" - eg like gnome's vala - I'm not sure
                    its the easiest way to go. It would mean rewriting vim using zimbu
                    partially.

                    I mainly care about introducing some threading.

                    Eg node has also written a 'libvu' abstracting over some issues.
                    I'm not primarly a C programmer (even though I know what pointers are,
                    and that I left Delphi long time ago because there were untyped lists
                    only)

                    Also libnih (from upstart) provides some simple list like iterators, and
                    much more - I think even dbus integration.

                    I don't want to read/write/review/debug list code. We have 2013.
                    That's why I wonder what is best for the project.

                    Eg for the buffer list case - who cares whether you're using a plain
                    array, or a linked list? Who has more than 2000 items? And till 2000
                    items a simple array (and increasing array size by 50% always) should be
                    equally fast - if not faster, because less mallocs have to be done.

                    I also know about the yzis project (vim as component rewritten in C++).
                    But its community is not that strong - and they support only lua (which
                    would not be that bad). While I made it compile the project looked
                    almost dead to me.

                    Marc Weber

                    --
                    --
                    You received this message from the "vim_dev" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php

                    ---
                    You received this message because you are subscribed to the Google Groups "vim_dev" group.
                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  • Marc Weber
                    ... Same problem about Go/whatever? How to upgrade without rewriting everything? I m not asking for a full rewrite, just want to know which is the best way to
                    Message 9 of 20 , Jun 8, 2013
                    View Source
                    • 0 Attachment
                      Excerpts from Shougo's message of Sat Jun 08 19:09:04 +0200 2013:
                      > How is the Go language?
                      > I think Go is similar to Zimbu.
                      > What are Zimbu advantages compared from Go language?
                      Same problem about Go/whatever? How to upgrade without rewriting
                      everything?

                      I'm not asking for a full rewrite, just want to know which is the best way to have
                      collections - a primitive used very frequently by all kinds of software.

                      http://vim-wiki.mawercer.de/wiki/index.html
                      -> improving-language-or-usage-of-it
                      -> breaking-with-the-past (why I'd do so: the list is small, and I think
                      fixing is better than breaking). I added this page for the sake of
                      completeness.

                      If we go that route, we also have to discuss joining any of the existing
                      editors, such as
                      - yzis
                      - yi (Haskell has its flaws, too, so why not settle on "rewriting yi
                      using disciple ?"
                      - or haxe.org (for portibility)
                      - ..
                      (mostly kidding here - possibilities are endless)

                      Ok Bram, we can continue discussing go vs zimbu vs X. But till
                      developers have settled on something (:-)) I'd be interested in a brief list
                      about options you'd consider "acceptable" providing any kind of short
                      abstraction for collections using C.

                      Marc Weber

                      --
                      --
                      You received this message from the "vim_dev" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php

                      ---
                      You received this message because you are subscribed to the Google Groups "vim_dev" group.
                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    • Bram Moolenaar
                      ... There are no options. Vim is written in C and I see no reason to change. Perhaps, when Zimbu is ready I might consider rewriting some pieces in Zimbu,
                      Message 10 of 20 , Jun 8, 2013
                      View Source
                      • 0 Attachment
                        Marc Weber wrote:

                        > Excerpts from Shougo's message of Sat Jun 08 19:09:04 +0200 2013:
                        > > How is the Go language?
                        > > I think Go is similar to Zimbu.
                        > > What are Zimbu advantages compared from Go language?
                        > Same problem about Go/whatever? How to upgrade without rewriting
                        > everything?
                        >
                        > I'm not asking for a full rewrite, just want to know which is the best way to have
                        > collections - a primitive used very frequently by all kinds of software.
                        >
                        > http://vim-wiki.mawercer.de/wiki/index.html
                        > -> improving-language-or-usage-of-it
                        > -> breaking-with-the-past (why I'd do so: the list is small, and I think
                        > fixing is better than breaking). I added this page for the sake of
                        > completeness.
                        >
                        > If we go that route, we also have to discuss joining any of the existing
                        > editors, such as
                        > - yzis
                        > - yi (Haskell has its flaws, too, so why not settle on "rewriting yi
                        > using disciple ?"
                        > - or haxe.org (for portibility)
                        > - ..
                        > (mostly kidding here - possibilities are endless)
                        >
                        > Ok Bram, we can continue discussing go vs zimbu vs X. But till
                        > developers have settled on something (:-)) I'd be interested in a brief list
                        > about options you'd consider "acceptable" providing any kind of short
                        > abstraction for collections using C.

                        There are no options. Vim is written in C and I see no reason to
                        change. Perhaps, when Zimbu is "ready" I might consider rewriting some
                        pieces in Zimbu, but that's going to take several years during which no
                        bugs will be fixed and no new features will be added. For a similar
                        reason Elvis no longer exists...

                        --
                        "A clear conscience is usually the sign of a bad memory."
                        -- Steven Wright

                        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                        \\\ an exciting new programming language -- http://www.Zimbu.org ///
                        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                        --
                        --
                        You received this message from the "vim_dev" maillist.
                        Do not top-post! Type your reply below the text you are replying to.
                        For more information, visit http://www.vim.org/maillist.php

                        ---
                        You received this message because you are subscribed to the Google Groups "vim_dev" group.
                        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                        For more options, visit https://groups.google.com/groups/opt_out.
                      • Bram Moolenaar
                        ... Go has a few nice ideas, but otherwise it s a bit of a mess. Both new and make to create items, and then delete doesn t quite do what you expect. No
                        Message 11 of 20 , Jun 8, 2013
                        View Source
                        • 0 Attachment
                          Shougo wrote:

                          > > The solution I've been thinking of is www.zimbu.org.
                          > > It produces C code, thus there should be a way to mix some parts written
                          > > in Zimbu and some parts still written in C.
                          >
                          > I think Zimbu is not bad choice.
                          > Zimbu is developped continuously by Mr.Bram and it fits with Vim
                          > development policy(Speed, compatibility, portability).
                          > http://code.google.com/p/zimbu/source/list
                          > I can learn Zimbu if it needs for Vim develop.
                          > But unlike other languages, Zimbu developers are too few.
                          >
                          > How is the Go language?
                          > I think Go is similar to Zimbu.
                          > What are Zimbu advantages compared from Go language?

                          Go has a few nice ideas, but otherwise it's a bit of a mess. Both "new"
                          and "make" to create items, and then "delete" doesn't quite do what you
                          expect. No exceptions. No typed containers (at least not yet). No
                          inheritance.

                          For Zimbu I'm trying to gather all the nice things from other languages.
                          From Go I learned about channels (called pipe in Zimbu). Those are a
                          nice way to communicate between threads (or co-routines, if you have
                          them). https://zimbu.googlecode.com/hg/docs/PIPE.Pipe.html

                          I'm also talking with the guy implementing garbage collection in Go,
                          taking some of their ideas for the Zimbu garbage collector (almost
                          done, got stalled because of Vim work...).

                          --
                          Support your right to bare arms! Wear short sleeves!

                          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                          \\\ an exciting new programming language -- http://www.Zimbu.org ///
                          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                          --
                          --
                          You received this message from the "vim_dev" maillist.
                          Do not top-post! Type your reply below the text you are replying to.
                          For more information, visit http://www.vim.org/maillist.php

                          ---
                          You received this message because you are subscribed to the Google Groups "vim_dev" group.
                          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                          For more options, visit https://groups.google.com/groups/opt_out.
                        • Taro MURAOKA
                          ... How about define common containers for Vim by C? And rewriting Vim by using that containers gradually. Absence of common containers in Vim, have caused
                          Message 12 of 20 , Jun 8, 2013
                          View Source
                          • 0 Attachment
                            > Yeah, basic C is missing containers. There are libraries for them, but
                            > there doesn't seem to be one clear winner.

                            How about define common containers for Vim by C?
                            And rewriting Vim by using that containers gradually.

                            Absence of common containers in Vim, have caused duplication of
                            implementations like single linked list.

                            --
                            --
                            You received this message from the "vim_dev" maillist.
                            Do not top-post! Type your reply below the text you are replying to.
                            For more information, visit http://www.vim.org/maillist.php

                            ---
                            You received this message because you are subscribed to the Google Groups "vim_dev" group.
                            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                            For more options, visit https://groups.google.com/groups/opt_out.
                          • Marc Weber
                            ... Your reply is not complete yet. My question was: How to use collections without repeating myself while coding. Vim is about not repating yourself , too.
                            Message 13 of 20 , Jun 8, 2013
                            View Source
                            • 0 Attachment
                              Excerpts from Bram Moolenaar's message of Sat Jun 08 23:48:39 +0200 2013:
                              > There are no options. Vim is written in C and I see no reason to
                              > change.
                              Your reply is not complete yet. My question was:
                              How to use collections without repeating myself while coding.

                              Vim is about "not repating yourself", too. Eg that's why the '.' command
                              exists. I just try to apply what Vim taught me when trying to write
                              features for Vim.

                              If C++ is no option, what about preprocessor macros for lists and the
                              like?

                              You're the guru, so I ask you which way you recommend, because
                              everything I learned tells me "this is not optimal" and I want to avoid
                              pitfalls as much as possible.

                              I want to improve on each patch I provide. That's why I ask. In the end

                              Talking about zimbu:

                              I talked about "me wanting to improve any scripting support", so this
                              would include zimbu.

                              So I will install zimbu, soon. Then we should talk whether its feasable
                              to add if_zimbu support (eg by compiling shared libraries, then loading
                              them if its not possible to have an interpreter. I don't know
                              zimbu well enough yet.

                              Marc Weber

                              --
                              --
                              You received this message from the "vim_dev" maillist.
                              Do not top-post! Type your reply below the text you are replying to.
                              For more information, visit http://www.vim.org/maillist.php

                              ---
                              You received this message because you are subscribed to the Google Groups "vim_dev" group.
                              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                              For more options, visit https://groups.google.com/groups/opt_out.
                            • Shougo
                              ... Thank you for your answer. I got it. And I found previous similar threads in Zimbu ML.
                              Message 14 of 20 , Jun 8, 2013
                              View Source
                              • 0 Attachment
                                2013年6月9日日曜日 6時48分39秒 UTC+9 Bram Moolenaar:
                                > Shougo wrote:
                                >
                                >
                                >
                                > > > The solution I've been thinking of is www.zimbu.org.
                                >
                                > > > It produces C code, thus there should be a way to mix some parts written
                                >
                                > > > in Zimbu and some parts still written in C.
                                >
                                > >
                                >
                                > > I think Zimbu is not bad choice.
                                >
                                > > Zimbu is developped continuously by Mr.Bram and it fits with Vim
                                >
                                > > development policy(Speed, compatibility, portability).
                                >
                                > > http://code.google.com/p/zimbu/source/list
                                >
                                > > I can learn Zimbu if it needs for Vim develop.
                                >
                                > > But unlike other languages, Zimbu developers are too few.
                                >
                                > >
                                >
                                > > How is the Go language?
                                >
                                > > I think Go is similar to Zimbu.
                                >
                                > > What are Zimbu advantages compared from Go language?
                                >
                                >
                                >
                                > Go has a few nice ideas, but otherwise it's a bit of a mess. Both "new"
                                >
                                > and "make" to create items, and then "delete" doesn't quite do what you
                                >
                                > expect. No exceptions. No typed containers (at least not yet). No
                                >
                                > inheritance.
                                >
                                >
                                >
                                > For Zimbu I'm trying to gather all the nice things from other languages.
                                >
                                > From Go I learned about channels (called pipe in Zimbu). Those are a
                                >
                                > nice way to communicate between threads (or co-routines, if you have
                                >
                                > them). https://zimbu.googlecode.com/hg/docs/PIPE.Pipe.html
                                >
                                >
                                >
                                > I'm also talking with the guy implementing garbage collection in Go,
                                >
                                > taking some of their ideas for the Zimbu garbage collector (almost
                                >
                                > done, got stalled because of Vim work...).
                                >
                                >
                                >
                                > --
                                >
                                > Support your right to bare arms! Wear short sleeves!
                                >
                                >
                                >
                                > /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                                >
                                > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                                >
                                > \\\ an exciting new programming language -- http://www.Zimbu.org ///
                                >
                                > \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                                Thank you for your answer.
                                I got it.

                                And I found previous similar threads in Zimbu ML.

                                https://groups.google.com/forum/?fromgroups#!topic/zimbu-discuss/TDg6cdHDm24

                                --
                                --
                                You received this message from the "vim_dev" maillist.
                                Do not top-post! Type your reply below the text you are replying to.
                                For more information, visit http://www.vim.org/maillist.php

                                ---
                                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                For more options, visit https://groups.google.com/groups/opt_out.
                              • Mike Williams
                                ... A down side of container libraries can be memory fragmentation and slow downs due to non-locality of related structures (assuming you mean container
                                Message 15 of 20 , Jun 14, 2013
                                View Source
                                • 0 Attachment
                                  On 08/06/2013 23:48, Taro MURAOKA wrote:
                                  >> Yeah, basic C is missing containers. There are libraries for them, but
                                  >> there doesn't seem to be one clear winner.
                                  >
                                  > How about define common containers for Vim by C?
                                  > And rewriting Vim by using that containers gradually.
                                  >
                                  > Absence of common containers in Vim, have caused duplication of
                                  > implementations like single linked list.

                                  A down side of container libraries can be memory fragmentation and slow
                                  downs due to non-locality of related structures (assuming you mean
                                  container structures with void * pointers to the structures being held
                                  in the container). Maintaining list pointers within structures with
                                  macros/functions implementing basic operations preserves overall
                                  performance and removes the repeated solving of the same problem.

                                  2ps worth and all that.

                                  TTFN

                                  Mike
                                  --
                                  If God had wanted you to go around nude, He would have given you bigger
                                  hands.

                                  --
                                  --
                                  You received this message from the "vim_dev" maillist.
                                  Do not top-post! Type your reply below the text you are replying to.
                                  For more information, visit http://www.vim.org/maillist.php

                                  ---
                                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                  For more options, visit https://groups.google.com/groups/opt_out.
                                • David Larson
                                  ... Aack! Don t do that! We want VIM to stay alive. I personally am not willing to see no advancement in VIM for several years just so that it can be ported to
                                  Message 16 of 20 , Jul 26, 2013
                                  View Source
                                  • 0 Attachment
                                    On Saturday, June 8, 2013 2:48:39 PM UTC-7, Bram Moolenaar wrote:
                                    > There are no options. Vim is written in C and I see no reason to
                                    >
                                    > change. Perhaps, when Zimbu is "ready" I might consider rewriting some
                                    >
                                    > pieces in Zimbu, but that's going to take several years during which no
                                    >
                                    > bugs will be fixed and no new features will be added. For a similar
                                    >
                                    > reason Elvis no longer exists...

                                    Aack! Don't do that! We want VIM to stay alive. I personally am not willing to see no advancement in VIM for several years just so that it can be ported to Zimbu. (Perhaps that was your point...)

                                    It seems somewhat safe to me if the file names were changed from .c to .cpp. That would allow us to leverage basic libraries and simple OOP. We can steer clear of the more esoteric and tricky features of the language.

                                    --
                                    --
                                    You received this message from the "vim_dev" maillist.
                                    Do not top-post! Type your reply below the text you are replying to.
                                    For more information, visit http://www.vim.org/maillist.php

                                    ---
                                    You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                    For more options, visit https://groups.google.com/groups/opt_out.
                                  • Антон Кочков
                                    Why not use Cello library? It have containers, first class functions, etc http://libcello.org/ And it is C only. -- -- You received this message from the
                                    Message 17 of 20 , Jul 27, 2013
                                    View Source
                                    • 0 Attachment
                                      Why not use Cello library? It have containers, first class functions, etc http://libcello.org/
                                      And it is C only.

                                      --
                                      --
                                      You received this message from the "vim_dev" maillist.
                                      Do not top-post! Type your reply below the text you are replying to.
                                      For more information, visit http://www.vim.org/maillist.php

                                      ---
                                      You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                      For more options, visit https://groups.google.com/groups/opt_out.
                                    • Marc Weber
                                      ... But it does not get the task done I talked about: type safe container like stuff. Marc Weber -- -- You received this message from the vim_dev maillist.
                                      Message 18 of 20 , Jul 27, 2013
                                      View Source
                                      • 0 Attachment
                                        Excerpts from Антон Кочков's message of Sat Jul 27 11:42:14 +0000 2013:
                                        > Why not use Cello library? It have containers, first class functions, etc http://libcello.org/
                                        > And it is C only.
                                        But it does not get the task done I talked about: type safe container
                                        like stuff.

                                        Marc Weber

                                        --
                                        --
                                        You received this message from the "vim_dev" maillist.
                                        Do not top-post! Type your reply below the text you are replying to.
                                        For more information, visit http://www.vim.org/maillist.php

                                        ---
                                        You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                        For more options, visit https://groups.google.com/groups/opt_out.
                                      • Marko Mahnič
                                        ... I think it would be hard to create a generic type-safe container library in C. I only see two options: rewrite container manipulation code for every type
                                        Message 19 of 20 , Jul 28, 2013
                                        View Source
                                        • 0 Attachment
                                          > But it does not get the task done I talked about: type safe container
                                          > like stuff.

                                          I think it would be hard to create a generic type-safe container library in C. I only see two options: rewrite container manipulation code for every type of object (as is done in Vim) or define the container code as a set of preprocessor macros. In both cases a lot of code is duplicated either by the programmer or by the compiler. Also a lot of code in Vim relies on linked lists so it would be a huge and error-prone task to change all that.

                                          A solution compatible with the current state of Vim would be to use helpers for various containers. A helper for the linked list would look like:

                                          struct ListHelper
                                          {
                                          void** list_head_ptr;
                                          void** list_tail_ptr;
                                          int offset_of_next;
                                          int offset_of_prev;
                                          };

                                          void
                                          _lsthlpr_add_head(self, item)
                                          ListHelper* self;
                                          void* item;
                                          {
                                          void *pit = *self->list_head_ptr;
                                          *self->list_head_ptr = item;
                                          *(void**)((char*)item + self->offset_of_next) = pit; /* item->next = pit */
                                          if (self->list_tail_ptr && ! *self->list_tail_ptr)
                                          *self->list_tail_ptr = pit;
                                          }

                                          A list of Node structures along with it's helper would be initialized as:

                                          struct Node
                                          {
                                          Node* next;
                                          int data;
                                          };
                                          Node* my_nodes;
                                          ListHelper my_node_list;
                                          my_node_list.list_head_ptr = &my_nodes;
                                          my_node_list.list_tail_ptr = NULL; // we only use the forward pointer
                                          my_node_list.offset_of_next = offsetof(Node, next);
                                          my_node_list.offset_of_prev = -1; // reverse pointer doesn't exist

                                          Node* pnode = createNode();
                                          _lsthlpr_add_head(&my_node_list, pnode);

                                          You can still traverse the list in a type-safe way through my_nodes. The manipulation of the list through the list helper is type unsafe.

                                          If you feel it is absolutely necessary, a kind of run-time type safety could be achieved by adding a typeid member to the beginning of every structure that would be used in a container. The typeid for a structure would be set in a 'constructor' like createNode(). The same typeid would also be set in the helper during initialization. The helper methods would compare the value from the element to the value of the container.

                                          A more complex implementation of the ListHelper is in the file puls_st.c starting around line 108. It's not exactly C (without some preprocessing) but it will give you an idea.

                                          http://code.google.com/r/markomahnic-vim-popuplist/source/browse/src/puls_st.c?name=vim-popuplist

                                          A use example is in puls_st.c around line 2466 (_txmfac_init).

                                          http://code.google.com/r/markomahnic-vim-popuplist/source/browse/src/popuplst.c?name=vim-popuplist

                                          Marko

                                          --
                                          --
                                          You received this message from the "vim_dev" maillist.
                                          Do not top-post! Type your reply below the text you are replying to.
                                          For more information, visit http://www.vim.org/maillist.php

                                          ---
                                          You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                          For more options, visit https://groups.google.com/groups/opt_out.
                                        • Charles Campbell
                                          ... I use some macros... (outofmem() can be removed; it checks if the returned pointer is null, isses the failure message if so, and terminates). These four
                                          Message 20 of 20 , Jul 29, 2013
                                          View Source
                                          • 0 Attachment
                                            David Larson wrote:
                                            > On Saturday, June 8, 2013 2:48:39 PM UTC-7, Bram Moolenaar wrote:
                                            >> There are no options. Vim is written in C and I see no reason to
                                            >>
                                            >> change. Perhaps, when Zimbu is "ready" I might consider rewriting some
                                            >>
                                            >> pieces in Zimbu, but that's going to take several years during which no
                                            >>
                                            >> bugs will be fixed and no new features will be added. For a similar
                                            >>
                                            >> reason Elvis no longer exists...
                                            > Aack! Don't do that! We want VIM to stay alive. I personally am not willing to see no advancement in VIM for several years just so that it can be ported to Zimbu. (Perhaps that was your point...)
                                            >
                                            > It seems somewhat safe to me if the file names were changed from .c to .cpp. That would allow us to leverage basic libraries and simple OOP. We can steer clear of the more esoteric and tricky features of the language.
                                            >
                                            I use some macros... (outofmem() can be removed; it checks if the
                                            returned pointer is null, isses the failure message if so, and
                                            terminates). These four macros presume that there are "nxt" and "prv"
                                            pointers in the structure for linking.

                                            #define double_link(structure,head,tail,fail_msg)
                                            { \
                                            structure *newstr; \
                                            newstr= (structure *)
                                            malloc(sizeof(structure)); \
                                            outofmem((void *)
                                            newstr,"%s\n",fail_msg); \
                                            if(tail) (tail)->nxt=
                                            newstr; \
                                            else head =
                                            newstr; \
                                            newstr->prv= tail; \
                                            newstr->nxt= (structure *)
                                            NULL; \
                                            tail = newstr; \
                                            }
                                            #define delete_double_link(structure,str,head,tail)
                                            { \
                                            structure *old=
                                            str; \
                                            if(old) { \
                                            if(old->prv) old->prv->nxt=
                                            old->nxt; \
                                            else head =
                                            old->nxt; \
                                            if(old->nxt) old->nxt->prv=
                                            old->prv; \
                                            else tail =
                                            old->prv; \
                                            free((char *)
                                            old); \
                                            } \
                                            }
                                            #define only_double_link(structure,newstr,head,tail)
                                            { \
                                            if(tail) (tail)->nxt=
                                            newstr; \
                                            else head =
                                            newstr; \
                                            newstr->prv= tail; \
                                            newstr->nxt= (structure *)
                                            NULL; \
                                            tail = newstr; \
                                            }
                                            #define only_delete_double_link(structure,str,head,tail)
                                            { \
                                            structure *old=
                                            str; \
                                            if(old) { \
                                            if(old->prv) old->prv->nxt=
                                            old->nxt; \
                                            else head =
                                            old->nxt; \
                                            if(old->nxt) old->nxt->prv=
                                            old->prv; \
                                            else tail =
                                            old->prv; \
                                            } \
                                            }

                                            Typical use:

                                            struct ABC_str {
                                            double something;
                                            struct ABC_str *nxt;
                                            struct ABC_str *prv;
                                            } *abchd= NULL, *abctl= NULL;

                                            double_link(struct ABC_str, abchd,abctl,"failed while attempting to
                                            double-link an ABC_str");

                                            struct ABC_str *abc;
                                            delete_double_link(struct ABC_str,abc,abchd,abctl);

                                            Regards,
                                            Chip Campbell

                                            --
                                            --
                                            You received this message from the "vim_dev" maillist.
                                            Do not top-post! Type your reply below the text you are replying to.
                                            For more information, visit http://www.vim.org/maillist.php

                                            ---
                                            You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                            For more options, visit https://groups.google.com/groups/opt_out.
                                          Your message has been successfully submitted and would be delivered to recipients shortly.