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... ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
