Originally posted by erendorn
View Post
Announcement
Collapse
No announcement yet.
Lots Of Ubuntu Mir Changes Expected Next Week
Collapse
X
-
Oh Hai, I saw your flamewar and thought I'd fan the flames a bit...
Comment
-
Originally posted by jayrulez View PostIt is your lack of knowledge about that topic that leads to that conclusion. The year is 2013, not a point in the 90s.
Remember the concept of low level programming is not related on how close or far is to the kernel but how close to the actual hardware you have to operate.
In the case of Wayland you have to manage memory allocations and buffering[SHM/EGL/Others] and it interacts very closely with KMS/DRM/ioctls/syscalls/etc which are kernel elements, you have to handle elements of IPC directly from input devices through EVDEV, etc. So certainly C++ is possible but since everything around wayland is very close to the hardware and is in C already, C is a very good design choice here that allow you fine tune and go as close to hardware/kernel as possible when needed and you save a lot ofCode:extern "C"
now to interact with wayland and superior i consider C++ a better option since the closer you get to GUI level OOB programming is more efficient and less complicated given is done right of course.
My point in resume is use the right tool for the job, for example
* need to manage kernel data or memory specialization make a C library to use from C++
* need to implement logic/gui use c++ and call your C library for lowlevel operations
* need GUI design QML or related no need to use a nuke against an ant
* need small object or widgets for the user to interact with small data, use python/perl/ruby/etc the performance penalty is neglible and will save lots of your hair
thereis no such thing as perfect language for every possible situation, just good tools for each level and the trick is learn to use them effectively
Comment
-
Originally posted by dee. View Post
Comment
-
Originally posted by jrch2k8 View Postwell is a bit extreme but could be a good guide about what not to do in C++, well one thing is true tho C++ in hands of a bad developer can be horrible and more more visual than C since the flexibility of C++ works against it ironically but well used can be beatiful
Comment
-
Originally posted by erendorn View PostYou really have no clue, do you? How will client side support for application (QMir or any other) help a DE in making a shell, compositor and display server for Mir?
Comment
-
People saying C++ is bad where C is good doesn't know what they are talking about.
Good written C code are perfectly valid C++ code.
People saying that a display server is vary low level close to the kernel are again
not knowing what they talk about.
The kernel basically only talks with the hardware. The display server does not
talk with the hardware.
The kernel have to handle itself, it have nothing but hardware under it, a
display server get a lot of stuff free from the kernel and the graphic driver.
A display server is closer to tool-kits like QT, GTK, Motif and whatever than
to the kernel.
Comment
-
Originally posted by Pajn View PostPeople saying C++ is bad where C is good doesn't know what they are talking about.
Good written C code are perfectly valid C++ code.
Comment
-
Originally posted by Pajn View PostPeople saying C++ is bad where C is good doesn't know what they are talking about.
Good written C code are perfectly valid C++ code.
People saying that a display server is vary low level close to the kernel are again
not knowing what they talk about.
The kernel basically only talks with the hardware. The display server does not
talk with the hardware.
The kernel have to handle itself, it have nothing but hardware under it, a
display server get a lot of stuff free from the kernel and the graphic driver.
A display server is closer to tool-kits like QT, GTK, Motif and whatever than
to the kernel.
2.) this has more shade of gray than black or white
3.) kernel have many layers and only 1 of them talk to the hardware
4.) partially correct
5.) is exactly in the middle no more no less
to short answer 2,4, is true that an display servers don't query the graphic card / input directly in C/ASM/registers like a kernel module would do but is true also this module for many operations just pipe the raw hardware data to an upper layer as is also true you are still close enough to the hardware to need hardware/kernel layer compliant data structures. sure the kernels provide small layers in between to provide some normalization for know operations but even so is closer to kernel/hardware than to high level userspace
to explain 5, wayland and most display server have 2 faces which is why they are in the middle, the first face is hell lot closer to the kernel/hardware than any toolkit ever be and the other face is the definition of the user accesible API which abstract the whole lot of kernel/hardware operations to be used for toolkits that by definition of abstraction is very far from the kernel/hardware
Comment
-
Originally posted by allenmaher View PostHere the answer is simple Mir is a compositor and display server with an API, not a protocol like the wayland approach. It does not need each DE to write it's own compositor and display sever.
Even if we grant your premise, however, DEs still need a stable API that is written to work with many DEs. Mir, on the other hand, pretty much guarantees an unstable API written to work with one and only one DE.
Comment
Comment