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, <[email protected]> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
