> Excerpts from hermitte's message of Wed Nov 27 14:44:42 +0100 2013: > > 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) > Historically I was told that C++ was written to "reuse the knowledge > of programmers because C programmers did know C".
This strength is also a weakness. It's easy to add C++ constructs there and there in a C program. But in the end, good practices about programming robust applications are not the same. > So how do you rewrite an application such as Vim using C++ without > rewriting it if you should be using only one of C or C++ ? That's a good question. I've never delved into Vim code, and as such I can't tell you what's best: a complete rewrite or adding things there and there. In case it's of any help: GCC has been migrated to C++ ( https://lwn.net/Articles/542457/ ). > If I choose to create a new artificial language, I possibly could > write something turning C into my new language, then do what I > said to test huge amounts of C code by adding runtime checks. If you write a new language, you'll have two kind of bugs to track down : the ones from your language, and the one from the new-vim application written in that language. This represents a tremendous effort. Moreover, there is a huge risk that (almost) nobody will join until the final product has again enough stability, and community. > Your points are valid. In Haskell I can do: > > data Struct = > name :: String, > list :: List (of) Int, > age :: Int > > deriving (Show, Read) > ^ this is built into the compiler > > $(derive [serialize-to-binary, memory-alloc, memory-check]) > ^ this is "template haskell", which derives class instances for me. > > So how I can I possibly make C++ derive a "new(my struct)" which > calls s.bar.fill('\x0') (and does this for each field of the struct) > ? [I may have not understood your question as I don't know haskell] By using the constructors ? So that nothing will be left uninitialized. One of the good practices in C++ (which is not as spread in C because of C89 inability to have variables declared anywhere but at the beginning of scopes) is to never have variables exist before you are able to initialize them to a pertinent value. If you can initialize them to a final value, it's even better. > > Again. Forget free/delete exist and embrace smart-pointers. Not > > necessarily std::shared_ptr<>, but at least the light and fast > > std::unique_ptr<>. > So you think C++ is more than ever a valid replacement for C in the > Vim case. I twould still be interesting to learn why Yzis failed, and how > to prevent such failure. If you ask me, C++ is a more valid candidate than C for any _new_ development -- the reasons lie in the article I've referenced in my previous post: C++ RAII makes it simple to manage resources. I reserve C for the cases I really have absolutely no other choice (mainly because of client wishes, or because of very exotic platforms). But I don't want to start a flame war, this is not the place. Here, what do you want to do ? Start a new editor from scratch ? Fork vim and have new dynamics regarding patch integration & so on ? In the later case, C++ may not be a solution, at all. Regarding Yzis, I'm not sure the problem was technical. Gathering a community around a forked product that breaks habits (like for instance plugins, didn't it?) is certainly not that trivial. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
