You are incorrect here. In C++, if you choose to make virtual calls, you pay the price of indirection via a vtable (this pointer). That's it. You only pay the price in classes which have virtual methods. With GObject, all classes contain a vtable, i.e. all class methods take a pointer to the type instance, which contains within it a pointer to the vtable. Every GObject instance contains this overhead, which makes instantiation of GObject expensive, and additionally increases the memory required for every object. In comparison, you don't pay this overhead for C++ classes unless you actually require it. This isn't including the overhead of additional GObject features such as properties, which are both inefficient to process and are type-unsafe, and the use of "construction properties" in object instantiation. What makes it truly awful is that all this work to implement OO in C is mostly done by hand! You have to manually create your own vtables; you have to manually cast all types to the correct type, and if you get it wrong the compiler won't typically tell you. You have to understand the intricacies of how a C++ compiler works to implement an inferior version in C! Why would anyone willingly inflict this upon themselves?

But this is only the beginning of the GObject problems. When using GObject, the type resolution is done at run-time. Not only does this make programming unsafe--the many typecasts can hide typing issues, leading to failure at run-time rather than at compile-time, it has additional run-time overheads. Here are a few reasons: G_TYPE_CHECK_INSTANCE_CAST, G_TYPE_CHECK_CLASS_CAST, G_TYPE_CHECK_INSTANCE_TYPE, G_TYPE_CHECK_CLASS_TYPE, G_TYPE_INSTANCE_GET_CLASS. And you'll also need to check every function argument taking a GObject to make sure it's of the correct type with G_TYPE_CHECK_INSTANCE_TYPE (or commonly using a wrapper around it). This is not a cheap operation, it has to check the GType type register, which involves a string lookup in a hash table (GQuark, at least last time I looked). So you have several of those for every function call if you actually investigate the use of all the uppercase casting macros, and again inside the function. This is mostly absent for C++ code (the type checks and casts are done at compile-time), and C++ RTTI involves simple pointer comparisons of typeinfo objects; much faster, and again type-safe.

Here's an example of class using GObject: header source

This is the same class using C++ header source

The C++ version is type-safe. Several type bugs were found during the C++ conversion, not picked up by the C compiler using GObject. It's more efficient, easier to maintain, and more secure. The objects take up less space in addition. Overall, the C++ conversion had only positive effects. The current implementation is also available in git.

Back in the mid-to-late 90s, when GTK+ was being created, C++ on Linux was poor, and was not yet standardised. This is now no longer the case, it's very well supported and works very well. IMO it would make a lot of sense to make the excellent GTKmm and related mm bindings the real implementation (i.e. not wrapping the C version), which would really improve the quality of the system. Right now, even the GNOME developers do not encourage development using the C interface due to its many problems. Tools like Vala only paper over the problems--you still need to use the C interface to write a "native" GNOME application with access to all the interfaces, because GNOME is still fundamentally tied to the canonical C implementation, with all the problems that entails.

Regards, Roger

Err, yes, it most certainly does. Take a look at the underlying SSHFXP protocol; it's essentially a serial protocol that provides the UNIX filesystem API, i.e. open/close/read/write/lseek/chown/chmod etc., over the wire. This does allow it to be used directly as a filesystem, and is why we have the sshfs FUSE filesystem which utilises it.

If Steam was available for Linux, and games could run natively or via wine, I'd lose the last major reason I have a copy of Windows. I'm sure I'm not the only one using Windows solely for gaming, and I'd love to be able to ditch it entirely for Linux.

> The No.5 and No.6 reactors represent about 2GW of generation capacity they desperately need.

Totally agree. If they are undamaged and remain safely operable, why would they be left to sit idle once the immediate mess has been cleaned up. The other reactors are obviously write-offs though.

> The power reactor at the Windscale site was operated for 46 years after the graphite fire in the weapons reactor.

Why wouldn't they be though? Sellafield is a big site, around 1000 separate facilities in six square km, and the four Calder Hall Magnox reactors were entirely separate from the Windscale Piles. Calder Hall operated from 1956 to 2003, so it was obviously well under construction, and at least partially, if not fully, complete before the Windscale fire. My understanding is that the affected reactor was sealed and mothballed; no need to abandon the entire site, and that's now part way through being cleaned up and fully dismantled. Unlike Chernobyl, it's not like the immediate area was heavily contaminated and evacuated. Heck, I've been on holiday and been swimming in the sea within spitting distance of the place--it's not like the Windscale incident caused any lasting harm.

I just bought a Nokia 1800. Not a smartphone, but I don't need one; I have a computer for all that stuff. Battery life: currently around 2.5 weeks with moderate text/call usage. Very simple, does all the basic stuff excellently though. Cost me £16 with £10 credit, so basically £6 for the phone.

This has a very similar interface to older Nokia phones I've used. I'm basically a happy Nokia customer. Am I at all interested in Windows Phone 7? No, and never will be. I was interested in the potential of the N900, but was far too expensive to justify actually buying. Shame we probably won't see what it's successors could offer.

I'm kind of sad the 1800 is likely the last Nokia product I'll buy, since prior to Elop it looked like they had a superb long-term strategy--they just needed a little longer to get it all together in the short-medium term, and they would have continued to be the best.

(Sheesh, Slashdot can't even handle a simple UTF-8 £ sign without mangling it.)

This is one probable reason. If there's a security problem, then the distributor has the following options:

- wait until Mozilla releases a new version containing the security fix [but this may contain other, unwanted, changes]
- backport the security fix, but then get explicit approval from Mozilla before being allowed to make the release [may take too long]
- backport the security fix immediately, but don't wait for approval from Mozilla [but requires renaming to something other than "Firefox" to be compliant with the trademarks].

Additionally, Firefox and its related components are so complex and intertwined than it's often simply not possible to backport a security fix. In this situation the only choice is to upgrade everything to the latest version.

From Debian's point of view, you don't really want to push major new versions into a stable release, and especially for a security update. You want a minimal, targeted, testable fix which fixes a single issue only. That's one of the reasons why Debian chose to rename "Firefox" to "Iceweasel", because otherwise it is simply not permitted to release a security update.

It's also worth pointing out that distributors such as Debian also make changes to software to better integrate it into their system. "Firefox" would prohibit that as well, which is one reason why it's very much a standalone application that doesn't integrate properly into any desktop environment, and reimplements a whole bunch of the common functionality they provide.

Regards,
Roger

You should be aware that Debian is not allowed to use the trademark "Firefox" and also have the ability to apply patches such as security fixes(1). It's not called "Iceweasel" out of anything but necessity. You think this is a Debian-specific issue? Well, no, it's actually a major problem for all other distributors as well(2).

1
2

So the links are 5 years old, but the issues surrounding the trademarks haven't changed or gone away. Distributions shipping "Firefox" have abrogated their ability (and responsibility) to be able to apply changes and security updates to the software without the explicit concent of Mozilla Corporation.

Not exactly free software when it comes on those terms, is it?

Regarding the kernel, I assume you're referring to the non-free firmware removal. Maybe you haven't been fully informed that the non-free firmware was actually removed from the upstream kernel sources as well. As a result, the Debian kernels are far from "non-standard", they are standard!

Regards,
Roger

[FFS Slashdot, it's 2011 and you still can't handle UTF-8!]

One thing many people aren't aware of is that for several years now (since GCC3), GCC and G++ accept UTF-8 as their default input encoding, and internally store narrow and wide strings as UTF-8 and UTF-32, respectively. It's recoded to the output stream locale when you do any output. This means you can write your source code in Unicode (in strings and comments at least) and it all works perfectly. It has full support in the C and C++ standard libraries. I've been using it for years; it works perfectly. It would be nice to get support for UTF-8 symbols in the linker, so we can have UTF-8 variable names as well. The same applies to Perl, though perl6 even gives you the ability to have Unicode operators, and possibly variable names.

I do routinely use UTF-8 symbols in R (example: "deltaCt" can be replace with the actual Delta symbol [Slashdot ate the Unicode--seriously poor!]). It makes the code more readable, and entry isn't the massive issue people make it out to be. AltGr/compose keys handle the common symbols, and you can look up the few odd ones that aren't in the compose tables.

Having the ability to use Unicode does not in any way detract from the ability to use ASCII. Since ASCII is a strict Unicode subset, the ability to use Unicode imposes zero overhead on those who wish to stick with ASCII, so the extent of the hate seen for wanting a bit of progress is a bit shocking. People pointed out how unreadable code could be made, but the reality is that when used sensibly and judiciously, it can make code more concise and readable.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522776 for information about some of the issues.
Having native Unicode support end-to-end by default is still a goal we want to achieve; the ASCII C locale is the last holdout. Getting a UTF-8 C locale is the last remaining step, though it'll take a few years to get there.

Regarding editing Unicode sources, both Emacs and vim have pretty decent Unicode support, and Linux distributions have had unicode support for a decade now, and really good support for at least six years. Broken tools are no longer an excuse for not using Unicode.

Regards,
Roger