Re: improving Vim - Kickstarter - brainstorming - goals - who wants to join?

It is nice to see someone which actually knows C++ once in a while...
In my environment there is no-one.

On Wed, Nov 27, 2013 at 2:44 PM, <hermitte@free.fr> wrote:
> Hello,
>
>
>> But let me give you an example:
>>
>> sturt foo {
>> char bar[LENGTH]
>> int something_else;
>> }
>>
>> foo s;
>>
>> for (i = 0, i <= LENGTH, i++){
>> s.bar[i] = '\x0';
>> }
>> [...]
>> How could such be fixed?
>> Now tell me how I can do that with C/C++?
>
> This is a easy one: embrace C++11 !
> struct foo {
> std::array<char, LENGTH> bar;
> int somethine_else;
> };
>
> Then, you have the choice between the following buffer-overrun-resistant solutions:
> - s.bar.fill('\x0');
> - for(char & c : s.bar) c = '\x0';
> - std::fill(begin(s.bar), end(s.bar), '\x0')
>
> There are other solutions based on iterators where typographic errors may have the same overflow result
> for (char *c = std::begin(s.bar), E=std::end(s.bar)
> ; c != E // <- here, old school developers may write c<E, or worse: c<=E
> ; ++c)
> *c = '\x0';
>
>
> The difficulty with C++, is to force ourselves to forget we also know C.
> (BTW, C/C++ is a beast that shall be hunt down. Either code in C, or in C++. Never try to import C good practices in C++ because they don't apply)
>
> You could also have used plain static arrays, the second and third solutions would have still worked.
>
>
>> Maybe such solutions exist. I'm pretty confident that such tooling
>> built into a compiler does help gitting stable code much more than
>> valgrind.
>
> Indeed. It's always better to find errors at compilation stage, or at least in test units.
>
>
>> Now you can continue with
>>
>> foo a = new(); // and get the debug layout eventually.
>> free(a): // and this would check that no memory corruption happened.
>
> Again. Forget free/delete exist and embrace smart-pointers. Not necessarily std::shared_ptr<>, but at least the light and fast std::unique_ptr<>.
>
>
>> But if you know a tool which is as smart as I told above, let me know
>> and teach me, please. I know that this can be done. And in fact I
>> want to do that. Thus if thus tooling is not available yet, I have to
>> write it.
>
> The way that C++ is taught is the problem. One of the most interesting article that indirectly demonstrates why we should embrace other ways to organize our code is the following : http://ra3s.com/wordpress/dysfunctional-programming/return-code-vs-exception-handling/
>
> Anyway. Use whatever language you master. But don't invent/create a new one for this project -- I hope I misread the first message about choosing a new language to implement this fork of vim.
>
> ------
>
> On another topic as a plugin writer that has always forced himself to stick to viml (for portability issues), it would be nice to have viml supported (for ascendant compatibility). I've written to many things, and I don't want to leave and loose everything.
>
>
> --
> Luc Hermitte
> http://lh-vim.googlecode.com/
>
> --
> --
> You received this message from the "vim_use" 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_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.