faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Cool
by anon on Thursday 23/Sep/2004, @13:58
|
> ...until the get hacked or crash!
C libraries are in the insecurity news all the time.
While it's true that C++ provides quite a bit more safety over C, it's still as easy to produce insecure code with C++ as much as it is with C.
Perhaps we should move away from systems-level languages like C and C++.
> Now we have a C rewrite of DCOP by the gnomes. Its two steps backwards and a waste of time.
I don't think it'll be a waste of time in the future as more and more system-level daemons start using dbus. Oh yeah, being able to interoperate with various GNOME apps is good too. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Cool
by M on Thursday 23/Sep/2004, @14:15
|
> While it's true that C++ provides quite a bit more safety over C, it's still
> as easy to produce insecure code with C++ as much as it is with C.
Do you actually read what you type? You dont make sense.
It is way easier to write (and read!) C++ code than C, while C++ can even be slightly faster than C.
But my point is not that C++ is the best language ever made (even though its pretty good), my point is that you should not use a 30-40 years old technology like C for todays programs.
|
[
Reply To This | View ]
|
Re: Cool
by Anonymous on Thursday 23/Sep/2004, @15:50
|
Since C is an almost complete subset of C++, most C statements are valid C++ and your niffty C++ code probably uses quite some elements from that subset. The anonymous poster is right in saying that producing insecure C++ code is very easy. Of course you can always compensate this insecurity by using strict conventions, but this is possible in C as well. Bashing some project just because it is developed using a certain language is quite unhelpful to say the least. Remember your trustworthy Linux kernel is C code as well and even the C++ based KDE had security issues in the past. That being said I consider myself a C++ programmer but not the kind of language fascist that you seem to be.
|
[
Reply To This | View ]
|
Re: Cool
by nl on Thursday 23/Sep/2004, @17:29
|
I cant agree with this. It not the existing features that make C bad (outdated) its the missing ones! You can use better programming strategies that dont exist in C.
And I wouldn't really call the linux kernel trustworthy...
|
[
Reply To This | View ]
|
Re: Cool
by Lars Roland on Thursday 23/Sep/2004, @16:08
|
Ahh I love the C vs. C++ fight.
I wonder if any of you people have even looked at the dbus code ?? - I have and it looks well written, so why not just accept that some cool programs is written in C and others in C++ (and Haskell, and Java, and C#, and ....).
As for the 30-40 year old technology, I can tell you that this old stuff powers most of the operating system kernels around the world today (inluding Linux, FreeBSD and big parts of the NT kernel) - but then again you can always try to convince Linus, Alan and the rest of the Linux gang to rewrite it in C++.
Ohh do you really mean that reading C++ is easier than C ?. Given that the grammars/lexical defenitions for C++ is much more complex than C, and most people writing programs in C++ only have marginal understaning of the language.
|
[
Reply To This | View ]
|
Re: Cool
by peter neuberger on Thursday 23/Sep/2004, @17:43
|
> I wonder if any of you people have even looked at the dbus code ?? - I have and it looks well written, so why not just accept that some cool programs is written in C and others in C++ (and Haskell, and Java, and C#, and ....).
last time I checked there was glib code pasted into it, but that was like a year ago or so. Overall I wasn't impressed.
> Ohh do you really mean that reading C++ is easier than C ?
Sure it is. Every C++ program follows roughly the same rules. On the other hand for every C library that I use you have to learn a new "object emulation model" or some more or less crazy API.
|
[
Reply To This | View ]
|
Re: Cool
by koos on Thursday 23/Sep/2004, @17:51
|
> C++ is much more complex than C
Yeah, try reading the boost libraries. Even the STL files, in/usr/include/c++/, can be hard to follow. But don't get me wrong, the result is _very_ powerfull both in features as in speed. But indeed KDE's includes are easy to read.
Actually I was quite happy to only have to recompile libfam and Qt/KDE, when upgrading gcc from 3.3 to 3.4. Not to mention the compile time difference. Long live C, and may every library, that I don't have to use, be implemented in C. And which I do use, well mostly it doesn't really matter.
What's really a swamp is building on top of win32, because you don't know what beneath you (and you get sucked away as soon as it becomes too popular).
|
[
Reply To This | View ]
|
Re: Cool
by stl on Thursday 23/Sep/2004, @18:09
|
I find the stl easier to read than most C libraries(lets say glib). Qt/KDE you can almost read like a book.
|
[
Reply To This | View ]
|
Re: Cool
by koos on Friday 24/Sep/2004, @02:17
|
You probably choose the most expensive super market, because the vinegar is much cheaper there then the bordeaux wines from price fighter mega store next door :-)
|
[
Reply To This | View ]
|
Re: Cool
by stl on Friday 24/Sep/2004, @15:20
|
No, I chose to drive a car(C++) rather than riding on a horse(C) to work.
But seriously, I know it is hard to compare C libs to C++ libs because there is not very often 2 libraries for the same thing. I chose stl vs glib, because they do roughly the same, I/O, containers, string.
|
[
Reply To This | View ]
|
|
Re: Cool
by Aaron J. Seigo on Thursday 23/Sep/2004, @15:31
|
> Oh yeah, being able to interoperate with various GNOME apps is good too.
it's not just GNOME. HAL (hardware abstraction layer) uses DBUS as well to notify from (the Linux) kernel space out about hardware devices (including hotplugging). DBUS is useful to all sorts of apps, not just GUI apps. it is, IMHO, the obvious and logical progression from DCOP, which proved within the confines of the desktop the utility and power of a purpose-built lightweight IPC mechanism, out to the OS in general. people complain about how the desktop is its own little disconnected world on UNIX, and DBUS is one step towards bridging that gap.
so, it's not *just* desktop interop, it's a way to bring a meaningful communication stack across the OS. the ATK DBUS bridge is one such example.
|
[
Reply To This | View ]
|
Re: Cool
by Heiko on Thursday 23/Sep/2004, @17:15
|
>people complain about how the desktop is its own little disconnected world on UNIX, and DBUS is one step towards bridging that gap.
Emmmh.Perhaps this fact that the gui isn't linked to deep with the os saves us from the experience of hardlocked machines like Windows, if gui apps crash.
Maybe DBUS brings us more possibilities for the Unix desktop, but i hope we don't have to accustom with daily reboots or security holes that find their way to the os through the desktop.I would prefer the desktop as a separate thing (like it is) with not to much power over the os.
|
[
Reply To This | View ]
|
Re: Cool
by Eric Laffoon on Friday 24/Sep/2004, @00:46
|
Interacting with a messaging bus and deeply integrating poorly abstracted code into the kernel are about as similar as installing phone lines are to building on top of another house. Getting a message or not getting a message where a client is in trouble is not the same as the client code blocking the kernel when it crashes because they are directly linked.
The key here is that a messaging system can provide the benefits with a huge buffering effect reducing the issues to a fraction of the problems possible with deep integration. This should affect your need to reboot about as much as a web site going down unless it's done very poorly.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
