Sorry to contradict you, but--in Europe--we have a plethora of Bluetooth comaptible phones. The latest devices from Nokia, SonyEricsson and Siemens are BT-enabled. E.g. SE T68i, Nokia 7650, 6310i and many many others (really I just stopped listing them...).
Safe Language-Systems vs. KDE, Gnome, Linux
on
KDE Strikes Back
·
· Score: 2
The article says:
> "If gnome-hackers [a mailing list] was archived, you could have a whole debate
> about a very classical problem of C programming : when a function returns a
> char*, who owns the char*? Does the caller have to free it? This is just about
> the most basic problem you can find with C programming. And they're thinking
> about it just now, after 3 years of development. KDE doesn't have such a
> problem, it has QString.
>
> "This is only an example of a more general trend: their C base puts them in
> front of a lot of problems which KDE doesn't even face. Of course, KDE has
> C++-specific problems, but nothing as fundamental as this."
Well this problem is not solved in c++ as well. This problem stems from a really big architectural problem of general c programming and operating systems. There is no provision for garbage collection and strong typing. I am pretty sure that c++ has - maybe - more refined and precise disposal guidelines for caller/callee then plain-c. Unfortunately, guidelines aren't worth a cent in this case. In a component-oriented, object-oriented environment no-one can keep track of the uses and references to the objects. I mean, no one except the memory manager that could deploy automatic memory reclamation. Of course, reliable memory management (heap-memory, I mean) can be obtained through strong typing: no pointer arithmetic is allowed and each pointer is bound to an object (usually called reference).
A language-system can be considered safe with respect to memory, if it support strong typing *and* it doesn't allow for manual disposal of dynamic memory.
All this, in order to say that it is very childish to argue between c and c++, since both aren't safe languages (a.k.a. they suck, excuse my French), thus both sharing the same pitfalls. This is for example one of the problems that require hardware memory protection to be solved (separate address spaces). Actually, it could have been solved earlier with a better language and system design, without the (at this point) avoidable overhead of heavy-weight processes.
Slashdot Mirror
Sorry to contradict you, but--in Europe--we have a plethora of Bluetooth comaptible phones. The latest devices from Nokia, SonyEricsson and Siemens are BT-enabled. E.g. SE T68i, Nokia 7650, 6310i and many many others (really I just stopped listing them...).
> "If gnome-hackers [a mailing list] was archived, you could have a whole debate
> about a very classical problem of C programming : when a function returns a
> char*, who owns the char*? Does the caller have to free it? This is just about
> the most basic problem you can find with C programming. And they're thinking
> about it just now, after 3 years of development. KDE doesn't have such a
> problem, it has QString.
>
> "This is only an example of a more general trend: their C base puts them in
> front of a lot of problems which KDE doesn't even face. Of course, KDE has
> C++-specific problems, but nothing as fundamental as this."
Well this problem is not solved in c++ as well. This problem stems from a really big architectural problem of general c programming and operating systems. There is no provision for garbage collection and strong typing. I am pretty sure that c++ has - maybe - more refined and precise disposal guidelines for caller/callee then plain-c. Unfortunately, guidelines aren't worth a cent in this case. In a component-oriented, object-oriented environment no-one can keep track of the uses and references to the objects. I mean, no one except the memory manager that could deploy automatic memory reclamation. Of course, reliable memory management (heap-memory, I mean) can be obtained through strong typing: no pointer arithmetic is allowed and each pointer is bound to an object (usually called reference). A language-system can be considered safe with respect to memory, if it support strong typing *and* it doesn't allow for manual disposal of dynamic memory.
All this, in order to say that it is very childish to argue between c and c++, since both aren't safe languages (a.k.a. they suck, excuse my French), thus both sharing the same pitfalls. This is for example one of the problems that require hardware memory protection to be solved (separate address spaces). Actually, it could have been solved earlier with a better language and system design, without the (at this point) avoidable overhead of heavy-weight processes.