From: John S. <mai...@ba...> - 2013-04-25 15:17:52
|
On 04/25/2013 04:52 PM, Alexis Lopez Zubieta wrote: > Hello: > > John, we do have a web page for our project but right now its down due to some troubles with the hosting, > if you want to know more about our work take a look at http://es.wikipedia.org/wiki/Nova_%28linux%29. can you also share the link to the currently offline page ? i will look if its reachable in a few days. > > About C++, I have to say that it support in a native form the object oriented programing > what enable to have the data and the functions related to it together and also encourage the code reusage. 1) putting data and functions together is considered harmful http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf but it's perfectably doable in C so i don't see your point 2) that C++ encourages code reusage and C doesn't, is a propaganda lie. the reality looks quite different, C++ adds a lot of hidden dependencies that make code reusage *harder*. think about inherited classes. in order to know how to use them, i have to know all about the involved classes. when some code i'm trying to debug passes around a base class object, i can not be sure which descendant of the class was originally instatiated. this makes debugging C++ code that was written by other people very hard. > And over all it enables to put more of the business logic into the code, (less comments are needed). huh ? citation needed. > Comparing C and C++ in runtime the second is just a bit (very small bit) > more resource hunger wich is the cost of the metadata asociciated to C++ objects. there's much more than that, as soon as you use templates you get a ton of specialised functions (it is sufficient to use STL). in the end, even a dynamically linked binary that uses some form of templates will end much bigger than it's C counterpart. and bigger binary also means bigger RAM consumption since the binary has to be mapped into RAM. > I have done a more detailed comparison but it is in spanish, if you are interested I can translate it to english. sure, would be interesting to read about that. > > In order to avoid that the next LXDE become a giant air ball I propose a monolithic architecture extensible > through modules and use lightweight threading instead of FORK. now you're talking about fork(), i was refering to forking lxde (the last release that works with gtk+2). when you talk about modules, do you think about dlopen() ? P.S. next time you come to IRC, stay a bit longer please :) i am not always in front of the PC... |