> 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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment