Slashdot Mirror
Coding The Future Linux Desktop [updated]
the.jedi writes "With the release of GTK+ 2.4, and Gnome 2.6 due out some time next week, it seems of some the Gnome developers are looking at how they'll be coding Gnome and the rest of the Linux desktop. Havoc Pennington of Planet Gnome has written a short blog pondering and analyzing the available options as coders move towards high-level languages like java and C#. He gives a good overview and assessment of technologies like mono, OO.org's UNO framework, as well as other ways of tying new languages to the existing code base. An extremely interesting read for desktop linux hackers everywhere."
Update: 03/17 14:44 GMT by T : Speaking of the future of Gnome, aeneas writes with a list of Gnome 2.6 release parties around the world (linked from gnome.org/start/2.5).
We'd actually get a performance gain without a 4 way Xeon and gigs of memory, and apps would even downscale acceptably to mobile devices?
Gnome/gtk kind of sucks for X performance, even compared to the Motif libraries, which are no speed demons. It makes WAN/dialup/dsl use of X even more painful than it need be.
Deleted
Having development environments like KDevelop and Glade are very important to the linux desktop. If these programs had more point-and-click UI design features, it would allow anyone with basic programming experience to put together a program. It's both good and bad to have this in linux though; it allows almost anyone to point and click an application together, and this will help corporations utilize a linux desktop. It also allows for the same problems that windows development has: lack of granularity in visual basic and really bad, unoriginal programs.
I think improving the visual part of KDevelop and Glade is very important. I also think leaving C/C++ and possibly Java as the languages in which the applications are written is preferable. C# is simply Java by Microsoft.
It would also be nice to have a development environment that allowed any language to drive the UI.
http://github.com/gbook/nidb
...as coders move towards high-level languages like java and C#... ... and soon Linux will not run anymore on low end systems, either requiring a super machine (like Windows) or running painfully slow.
I mean, we all like java, but have you ever seen a normal user application (with a GUI) written in java that is even a bit fast?
The battle for the Linux desktop has really been heating up lately, and with the planned release of several big commercial apps (Macromedia), it's getting even hotter.
.NET; what makes HP think that GTKmm or QT isn't good enough? Don't believe the hype dude; the MS marketing machine has been blowing a lot of smoke up a lot of asses.
As a bit of a GNOME fanboy, I hope GTK+ and friends can lure ISVs to use G-technologies when porting their programs. GNOME currently seems to have a large base of commercial support, although I've heard QT is being used in commercial development more. The integration of commercial apps with a desktop platform could be a make-or-break for said platform, especially as Linux market share grows and more Aunt Tillies and suits move off of Windows.
I've got a bone to pick with the FA though; it states that FOSS needs a new high level language and toolkit pronto if it's going to lure new developers. I haven't heard of the Adobes, Macromedias, or Intuits of the world scrambling to rewrite their apps in
Is this rock and roll, or a form of state control?
If you are locking up your hardware in XP, especially that regularly, I suggest you look at your hardware... namely whether that $20 power supply is sufficient.
-- ac at work
I was a gnome diehard for a long time. But now they are opening it up to legal issues with this .net copying.
Further, WTF is with object oriented nautilus in 2.6? Can someone explain how having hundreds of windows exploding onto my desktop as I browse is beneficial? And if it's for "ease of use" then can someone tell me how abandoning what the other 2 Major OSs are doing is "easy of use"?
Methinks there is some UseInterface Jihad warriors who could be kept under control. This is ONE thing where you do need an easy to use control panel to change between options.
Gnome is going in the wrong direction IMO.
I opened up KDE 3.2 to find konqueror quite nice actually, their tabbing is comparable to moz/fox now and the interface is cleaner. Sure KDE had "lots of options behind the scenes" but they are still behind the scenes, only one or two more "on the surface" extras to gnome.
There might well be a migration to KDE from Gnome to avoid legal issues if too many apps get developed in mono.
I've been professionally developing using C/C++ since 1985 on everything from device drivers to GUIs on every platform imaginable and I love C++.
BUT I've also been doing Java and C# the last three years, and they are a *huge* win in developer efficiency. Watching people working on my projects, I can see marginal developers immediately become much more productive (2x in some cases) - and I've been measuring this using several objective metrics (modules/week, LOC, PR #, time/PR).
I would rather see Java "win", but unless Sun blinks on the free/open issue _very_ quickly, I think C# will win by default.
Something I posted to osnews:
Nice article Havoc!
One very key thing is that many many developers who aren't open-source fanatics still use OSS when it suites them - development tools mostly, especially mingw etc.
Now from my empirical sampling of programming buddies, I'd say these developers outnumber the OSS crowd 10 to 1. There just are so many of them, and they're going to be writing software primarily for Windows for years to come.
The key thing is supporting windows in order that we can get those developers to start writing portable code accidently rather than by design. I've already managed to get many of them to use wxwidgets but obviously C++, as Havoc pointed out, isn't best for every project.
Any OS framework has to be aimed primarily at infecting the windows world and building accidental dependance there these portable tools, so that windows apps can magically run on our alternative OSS desktop.
An OSS desktop gains momentum through supported apps making it easy for normal (windows) users to use, not through advocacy.
I find all this talk about GNOME possibly becoming based on Mono extremely unsettling. GNOME is part of the GNU project. The Mono project is not only not part of GNU, they're even openly hostile to the GNU efforts that they're competing with.
That's quite an facile editorial but you can't expect better from normal users. My screenshot looks better than yours. Evolution is better than KMail, GNOME looks more polished than KDE and so on. I do use XChat, Abiword, Rhythmbox.... ...usually you get stuff like these from normal users. And this is ok since you can't blame them for stuff they simply don't know about or don't have a slighest knowledge about.
Such editorials are hard to take serious since they are build up on basicly NO deeper knowledge of the matter. Most people I met so far are full of prejudices and seek for excuses or explaination why they prefer the one over the other while in reality they have no slightest clue on what parameters they compare the things.
If people do like the gance ICONS over the functionality then it's quite ok but that's absolutely NO framework to do such comparisons.
I do come from the GNOME architecture and spent the last 5 years on it. I also spent a lot of time (nearly 1 year now if I sum everything up) on KDE 3.x architecture including the latest KDE 3.2 (please note I still do use GNOME and I am up to CVS 2.6 release myself).
Although calling myself a GNOME vetaran I am also not shy to criticise GNOME and I do this in the public as well. Ok I got told from a couple of people if I don't like GNOME that I simply should switch and so on. But these are usually people who have a tunnelview and do not want to see or understand the problems around GNOME.
Speaking as a developer with nearly 23years of programming skills on my back I can tell you that GNOME may look polished on the first view but on the second view it isn't.
Technically GNOME is quite a messy architecture with a lot of unfinished, half polished and half working stuff inside. Given here are examples like broken gnome-vfs, half implementations of things (GStreamer still half implemented into GNOME (if you can call it an implementation at all)) rapid changes of things that make it hard for developers to catch up and a never ending bughunting. While it is questionable if some stuff can simply be fixed with patches while it's more required to publicly talk about the Framework itself.
Sure GNOME will become better but the time developers spent fixing all the stuff is the time that speaks for KDE to really improve it with needed features. We here on GNOME are only walking in the circle but don't have a real progress in true usability (not that farce people talk to one person and then to the next). Real usability here is using the features provided by the architecture that is when I as scientists want to do UML stuff that I seriously find an application written for that framework that can do it. When I eye over to the KDE architecture then as strange it sounds I do find more of these needed tools than I can find on GNOME. This can be continued in many areas where I find more scientific Software to do my work and Software that works reliable and not crash or misbehave or behave unexpected.
Comparing Nautilus with Konqueror is pure nonsense, comparing GNOME with KDE is even bigger nonsense. If we get a team of developers on a Table and discuss all the crap we find between KDE and GNOME then I can tell from own experience that the answer is clearly that GNOME will fail horrible here.
We still have many issues on GNOME which are Framework related. We now got the new Fileselector but yet they still act differently in each app. Some still have the old Fileselector, some the new Fileselector, some appearance of new Fileselectors are differently than in other apps that use the new Fileselector code and so on. When people talk about polish and consistency, then I like to ask what kind of consistency and polish is this ? We still have a couple of different ways to open Window in GNOME.
- GTK-Application-Window,
- BonoboUI Window,
- GnomeUI Window,
Then a lot of stuff inside GNOME are hardcoded UI's, some are using *.glade files (not to mention that GLADE the interface buil
If they worked on KDE we by now would have a far better Desktop..
Would we? It seems to me that a lot of effort on KDE is wasted by continually reinventing the wheel, or just wasted with downright complete rubbish which shouldn't be there in the first place.
Exhibit A: KPaint. What the hell were the KDE release team even thinking? It doesn't work. What is doing in KDE?
Exhibit B: Kview & Kuickshow. KDE2 had KView, which worked, had a nice interface and was very useful. Now we have Kuickshow which is klunky, over engineered and less useful than KView. It takes a lot longer to load, too. Why?
Exhibit C: KBiff. KBiff was damn useful when I was running KDE1 all those years ago. Where is it now? Oh, it died a long time ago with the change to Qt 2.x Droping features like that is just bad.
Maybe if the KDE guys would spend some more time and actually invest themselves in less duplication and wasted effort instead of worrying about whatever GNOME are doing, wKDE would be a far better Desktop?
I guess I better strip Perl out of my Debian machine, then. Er...that'd kill it.
Seriously, code inside VMs has advantages, such as security and portability.
tasks(723) drafts(105) languages(484) examples(29106)
Letting Havoc Pennington decide what the Linux desktop should look like is like hiring Stevie Wonder for an interior decorator--He may be talented, but there are areas he should just simply stay away from. Far away from. Deciding standards for others, being among them.
Long story short, Pennington simply doesn't get the big picture of what the Linux desktop needs to be. For example he thinks having multiple, competing standards for GUI layout is a good idea. Ding ding ding ding! Hey Havoc, here comes the Oxymoron Train! "multiple standards"?!
Here's a real revolutionary idea...Instead of spending years trying to mimic every aspect of the Windows desktop, we build one of our own, with our own ideas! (*gasp*) !
Maybe because people don't want to keep constant track of memory allocation semantics. Maybe because developers don't want to have to learn a new platform library (e.g. Boost) every time they look at a new project. Maybe because the legions of programmers we expect to build tomorrow's applications will justifiable not give a damn about solving the same old problems we have been solving for decades, and instead want a consistent platform and set of APIs to get their work done safely and with minimal hassle.
"Our guys" are gonna have to fight their guys. And if "their guys" are armed with cheap CLR/VB.net/C# runtimes (meaning there will by about 10x more), we are going to freaking lose even though we have big and complicated C/C++ howitzers.
It's 10 PM. Do you know if you're un-American?
Just for fun i once ran the windows version of our C++ product using wine on linux. The window menus were more snappy than the one from the native X11 version. Why is that? Probably because wine uses DGA by default, bypassing X11 altogether.
Sorry, i just stopped believing in the "X11 isn't slow" slogans some years ago. Of course you can say "the toolkits use X11 ineffectively". Might be true. But that's like saying "Windows is secure, only the applications suck".
I don't think you could say that C++ is a high level language compared to C# or Java. Look at it this way - C++ usage on Windows is far, far higher than it's ever been in free software land yet pretty much all Windows developers I know who have tried .NET consider it a massive leap over what they were using before.
Now something will reach for the reply button to make a smart comment about MFC. Of course, MFC is not the only C++ API available - the ATL is even not that bad as they go. Even then, C++ is not as convenient as people would like.
For instance you still have manual memory management, and lack of thread support built into the language. You might not consider that a problem, but for instance the following code isn't guaranteed to be thread safe (and on some versions of MSVC++ isn't):
void foo() { static bar = new blah blah blah }
Using languages and runtimes like Java or C# helps with these issues as they were designed in from the start.
"I doubt they are using Java and Mono because they are "trendy". If anyone strays more from "trendy" things, it'll be developers. We use what is best for the job, be it C or C#."
If that were true, programmers would be using languages like Smalltalk, and not shying away from Frameworks. A lot of reason developers use not what's best for the job, but inertia of what they know. Just look at the difficulty Apple had when it released Mac OS X, getting "classic" programmers to use Objective-C, and Cocoa.
Quoting from Havoc's blog:
Unfortunately, Havoc says nothing about why he thinks the Parrot will not be the right thing: he merely asserts his opinion. My impression is that Parrot and Perl 6 development are both moving forward satisfactorily and offer the underpinnings needed for major projects. And of course are right in the center of open source development.
So what am I missing? Are there inherent structural flaws in these languages or the Parrot? Or do others share my personal opinion that Perl, Python, and Ruby are mostly out of favor because they aren't 133t enough to separate programmers from lusers?
(I thought this thread was sort of cold but perhaps throwing this gasoline on it will create some heat and maybe even some light.)
> Coding efficiency. High-level languages are
> simply technically superior to C/C++ for most > uses, desktop applications in particular.
Those who claim that do not know enough C++.
Using Boost or Loki smartpointers, C# or Java lose all the advantages they have over C++ in terms of productivity.
And properly usage of STL (including algorithms)
and templatization make C++ the most productive
language over there for non trivial projects.
One must not look at the effort needed to write
a program that do some trivial work multiply with 1000 and decide how much it take for a big project.
Take your time and learn more C++ before decide to use C# or Java.
Rant:
Reading The Fine Article(R), I found it unsettling that people are seeing XAML as a potential substitute for both HTML and programming, and haven't yet articulated an answer, even if a derisive one.
If it was the first time I took a real look about XAML, from the first few paragraphs of MS' introduction to it, it is clear it amounts to storing UI and other application data (not organisational data used by the application, but data used to build the application itself) in XML, that is to say, hierarchically.
Just as every time one talks about XML and data in the same breath, or OO and data, this would be a throwback to 35 years ago before Codd had defined and published the Relational Model for database management.
This is specially worrying because we see many free software advocates, and most of new hackers, married to OO instead of fundamentally saner functional programming, even if it is a marriage of convenience just to get things like garbage collection that are included in current popular OO platforms; and it is specially disappointing given that Gnome now is giving thought to a saner if partial answer, namely Gnome Storage.
Marrying Gnome Storage with some functional programming over .Net or Java perhaps could by us some sanity back, but I feel it like a kludge unlikely to produce significantly better.
Going Java or .Net may be an intelligent way of trailing MS. But to really leapfrog it where now they have a huge advantage -- and that's not now the desktop as in an user environment or office automation apps or games, but custom software development for businesses with Oracle Developer, PowerBuilder, VB, Delphi and the like --, we have to present something fundamentally and conceptually better.
Something like a functional flavor of Alphora Dataphor integrated at the systems level since the installer could be the answer perhaps; while this would be a tall order for the near future, having it in sight for, say, twenty years in the future while implementing it step by step -- for example, first the D-compliant RDBMS interfaces, then an upwards- and downwards-scalable RDBMS engine with a quasi-SQL interface for backwards compatibility, then integration in the OS, then POSIX interoperability --, would give us the initiative and reduce MS to yet another platform direction change in the future, while we'd be able to keep our perfect POSIX backwards compatibility.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
The trend in GNOME/KDE has long been towards integrating SW rather than making independent apllications. To me this is a distinct weakness, and one that makes me consider abandoning those desktops altogether.
To me useability means flexibility, which implies configurability and openness. And openness in particular means proper, exhaustive documentation - low level as well as intermediate and high level documentation. Which is more or less non-existent in current versions of Linux desktops and applications.
Another prerequisite for flexibility is modularity - not Windows style modularity, but a style of coding where modules are predominantly simple and have simple interfaces. Compare the mish-mash that is Windows, with all it's knitted spaghetti of interconnectedness, to UNIX in the old days (and, thank God, still today). The elegant simplicity of filter programs or the way inetd works illustrate what I'm talking about. This is what we need - somthing that 'as simple as possible, but no simpler', to misappropriate a well known quote.
Why not keep the window manager simple - and continue with C, and embed a scripting layer (like python) that allows you to extend it to create your applications? Python has an XML parser, and other things besides that you wouldn't need to implement inside of the window management engine.
:(
This doesn't seem like brain surgery to me...but then again, I am perfectly happy running Zope and kicking out web apps - or throwing together a python/Tk app if I need a gui for something on my desktop. I know...I am in the minority.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Instead, you go check and find out that the Mercury and Haskell projects are sponsored by Microsoft.
.NET to universities. Some gullible professors will no doubt swallow the bait.
These ports are just attempts by Microsoft to sell
You seriously thought MSFT cares about languages other than C# and VB.NET?
Save your wrists today - switch to Dvorak
I think before the OSS community can make a decision about -how- to code a competitive Linux desktop, it needs to decide -why- to code a competitive Linux desktop. The virtues of the system clearly come from their various kinds of openness and freedom, and we need to decide which are priorities. For example, do we want to produce:
-(free-ness)A free-as-in-beer system of comparable usability and functionality to commercial systems, that levels the playing field for developing countries, small businesses, or other entities without loads of cash to spend on commercial software;
-(Freedom)A free-as-in-speech system that empowers its users with useful technology, all of which they may apply to any non-exploitative purpose they like, without subjecting them to the whims and legal departments of the corporations who own it, and which therefore poses a significant threat to any single party which might try to restrict the way people can use their own computers and the software on it;
-(Openness)A system with an open architecture, where the kernel, file system, device drivers, window manager, desktop system, file browser, print manager, etc. are all decoupled and may be substituted or can even co-exist with any number of alternatives which might suit the user's needs more precisely;
-(Technical merit) A system that is guided by technical merit above any other purpose, that in its design and implementation represents the best effort of an entire meritocratic community beholden more to engineering principles than business strategies.
These are distinct but non-exclusive goals, each of which I see supported in the OSS community. I'm not convinced that we can effectively pursue all of these at once and hope to make significant achievements toward any of them on a competitive timeframe. Because of the forking problem, an uncoordinated step forward is also a step back. Perhaps one distribution will be a landmark of usability, but to achieve that goal its designers may have compromised on extensibility and designed it very specifically for particular implementations of assorted features, or may have used non-Free software. The accomplishments of this distro would liekly be useless to an ideal system which would meet all of the above goals- at the least, applying its improvements would require duplicated effort or extra work (opening up the architecture, developing and swapping in a Free alternative to the non-Free software).
Forking is always going to be an issue where there is complete freedom, and that's fine, but then the disparate goals of the system need to be prioritized, or else a significant strategy should be developed for how they'll be pursued concurrently.
I think Havoc's post states that C/C++ is proving an inadequate solution for pursuing (Technical merit) in a way that satisfies requirements for simultaneous (Openness) and high enough usability to make (free-ness) a significant advantage over commercial alternatives. The issue, though, is that the best alternatives compromise the goal of (Freedom).
C++ doesnt even have the abstraction of properties or attributes, go figure.
Its Cludge++ of macros and other hard to debug "features".
As for multilanguage features, rofl, more Cludges in the form of _T macros etc, what else hmm, no language independant way of packaging objects, except we have to bolt on COM. What else, all that code duplication between definitions and imeplementations. Im sure I can think of more cludges in C++.
At the end of the way, we hold the money, we are the ones putting food on your plate so you use what toosl we the designers choose and right now we are using C# and C++ managed extensions but this is only on a as few places as possible due to the inherant problems of C++.
Yeah and the compiler, well theyre not smart at all, i mean I have to code someconstantvalhere == variablevalue becuase the compiler cant check the == properely. More C++ issues.
Or do others share my personal opinion that Perl, Python, and Ruby are mostly out of favor because they aren't 133t enough to separate programmers from lusers?
It appears that Java programmers are considered the VB monkeys of today, so I don't think that's it.
Quite a few only use the languages they are taught at school, and with which they think they can get a job (those that don't have one or are afraid of losing their current job, that is). Therefore they avoid anything "exotic".
OTOH, avoiding Perl makes perfect sense.
Save your wrists today - switch to Dvorak
.../NextStep/Cocoa? it works from Apple. Objective-C already compiles in GCC, and it's less than trivial to use preexisting C/C++ code in Obj-C, making it an easy migration path.
Just raise the taxes on crack.
Those technologies offer a standards based means of doing UI's. The web isn't going away, and gradually browsers are getting closer to what we can do on the desktop. There are folks having some luck extending Javascript with Smalltalk features.
There already exist well supported compilers for Javascript-and those could be highly optimized with the right effort.
Javscript is _already_ well supported by Microsoft(they are supporting it as one of the major languages for the Windows Scripting Host). IMHO VBScript is just plain too buggy and ugly.
IMHO languages like Python/Perl/Ruby the best mainstream tools for Server Side Development(though Mozart-Oz has some interesting features). Client side? The browser appears to be the client of the future--and folks doing desktop stuff had best figure out how to deal with that.
Each time somone talk about moving from C to some others languages, we heard about C++, C# or Java. All are kind of OOL, but whatabout typed functionnal programming languages ?
I'm using OCaml every day, for many things (in the CDuce interpreter, see www.CDuce.org, but also in other coding projects.) And it is fast (nearly as C, just take a look at this language benchmark), it is in some way safe (the famous : "Well typed programs cannot go wrong"), it has a good interaction mechanism with C librairies, programs can be compiled in native or in bytecode, OCaml native code compiler is giving very good result on many arch/OS ...
And, speaking about gnome, there's also a "wrapper" for GTK and GTK2 (called lablgtk and lablgtk2.)
Marwan Burelle co-Head of EPITA's System Laboratory
- A modern GUI toolkit
- File and network I/O
- Decent string handling
- Common data structures and algorithms, so we don't have to write 1,000 hash tables and 1,000 quicksorts
- An interface to existing C libraries
The language also needs to be able to attract a large number of developers (which rules out Lisp, Scheme, OCaml etc) and needs to be suitable for large collaborative projects (which arguably rules out Perl, Python and Ruby).Java/GTK/gcj seems to be the only thing that meets the requirements and works now.
...in the open source community, we'd see more effort going into GNUstep.
Works with everything we have today? Check, there's compatibility with KDE and GNOME applications as well as Motif, with window style hints too.
High level language support? Check, Objective-C provides Smalltalk-like object orientation, and automatic memory management is available. There are also bindings to Ruby and Java. You can even build Java applications with native quality look and feel.
Compatible with what programmers know today? Yup, Objective-C is a slight superset of C, so almost any programmer can get to grips with it in a weekend. (Speaking as someone who did.)
Good class libraries? Yes, modeled on NeXT's excellent work, the same foundation used to build OS X. I've written Cocoa code, it's the most painless class library I've encountered. (Yes, I write Java too and have written C++.)
Cross platform? Yes again, programs are portable between GNUstep and Cocoa without too much work--see GNUmail for an example. Non-GUI programs even port to Windows without major effort, allegedly.
Good developer tools? Again, yes. Excellent developer tools on OS X. Doubtless the free tools on Linux could use some work, but that shouldn't be too hard. We can even build them using the OS X tools if necessary.
Pretty UI? Well, I think it looks OK. Not as nice as Aqua, but it's functional.
Mature? Well, the Objective-C compiler is GCC, Apple use it for their developer tools and push back improvements, the class library design has been refined over the course of 10+ years.
Think about it, people. We could unify the Linux and Apple developer communities. All work towards one common goal. Get 10%+ desktop market share for OpenStep/OS X/GNUstep in no time.
Hell, get GNUstep up to scratch and you'd probably see developers porting their commercial applications from OS X to Linux. Wouldn't you like to see products from Adobe, Macromedia, maybe even Apple available to run on your Linux desktop?
Think about all the problems that have been solved by NeXT and Apple. Application packaging? Solved, applications are bundles of files that you can just drag-drop wherever you want to keep them, and they work.
But no, the GNOME crowd will shun a tried and tested, open source, native code solution that works today and is backed by the single biggest vendor of UNIX desktops, in favor of cloning an untested patented bytecode-based Microsoft solution. Gates and co must be laughing.
But hey, go GNOME. Let's reinvent those wheels. Maybe your next set won't be square.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
You can actually write C++ code without pointers, new and delete (provided the libraries you use don't require it somehow). You achieve this via STL. For example, to read the contents of a text file you can use sth similar (may contain bugs, did not try to compile) :
you can even create trees without pointers - to achieve this simply use a map - every node has an int id (like a primary key) - this id is a key in the map - the value is the node. The node looks like this:and you store the nodes in a map like this:
By using a set you can ensure, that you won't reference several times from one parent to the same child. Such trees are very easy to store in a database, as you can imagine.
One of the problems with not using pointers is achieving polymorphism, since you cannot store derived types in a container, but it turns out that virtual functions are not that often necessary (at least that's my case).
Another issue are iterators - because of speed(?) they are not boundary checked, so if you
over a vector of 50 elements and then doyou have an ooops !!! you can hovewer reference elements in sequence container like this:which would throw an exception in case of a 50 element vector v.I wonder why nobody seems to
- Use C++ w/STL and avoid pointers - they are seldom needed
- Solve the problem with iterators (implement boundary checking - that can't be that difficult!).
I have been writing C++ / Java programs for several years and from my own experience, if you really use many of C++ features and avoid certain pitfalls, there is little more Java can offer - it doesn't even have the approx. 50 algorithms that STL has!I have also done some benchmarks for myself - if you replace STL containers with plain arrays, you get a 6x speed gain. I don't believe Java with all its objects is similar in speed to a properly coded C app - maybe both are so fast it doesn't matter, but a C app should be about 10 times faster than a similar Java app with all objects in their places!!! ;)
It seems like the root problem for almost all of these issues is that the JVM is not integrated into the OS. A separate JVM is launched for every application. If Java was the standard desktop toolkit then wouldn't it be possible to integrate a JVM into the OS runtime? This would greatly reduce the startup overhead, the memory usage per app, and also allow a faster GUI toolkit implementation.
When it comes to memory usage welcome to the real world of tradeoffs. I would rather pay more cash for extra memory than waste time while my apps crash because they use languages that don't protect developers from their own mistakes.