I'm developing for Windows first where the general practice is for applications to ship with whatever DLLs they need rather than install them in shared folders, the windows\system directory or somewhere else on the PATH. Otherwise DLL-hell will surely follow.
Ultimately the application may end up an embedded device, where space is at a premium. In that instance I'll probably have to static link but it depends on licencing issues.
Most desktop OSes would have services that could provide that information and do encodings and transformations between character sets. I don't see that QT needs to ship all of it. Aside from that my app is localizable so I can't do away with the way its implemented either.
It's modular but it's still got bloat. I'm writing an application which has a fairly modest UI that has a main window, some tabs and dialogs. The weight of the runtime I have to ship with it - icu*, Qt5core, Qt5Guid.dll, Qt5Widgets runtimes is nearly 38MB. Most of the modular bits with the exception of webkit - (multimedia, networking, OpenGL, SVG etc.) are comparatively lightweight compared to the slab of unavoidable "core" stuff that you need whether you like it or not.
Bitcoin has repeatedly demonstrated that it's nothing more than a ponzi - stoke up fears in a currency or appeal to their greed, wait for people to buy in and then exit with the different.
No matter how bad the Greek crisis gets, no matter how much of a haircut people get on their savings from any currency swap, it will still be less risk than bitcoin.
I might not be paying them money directly but I'm certainly making them money. Developers and companies pay Oracle for tools, support, certification, training for Java and they do it because there is a demand for the language. If the brand is cheapened then ultimately it will hurt them in the wallet.
Same principle applies to Adobe and Flash. They make nothing from the Flash player but its all those eyeballs are what make professionals want to buy the dev tools that they do make money from. Cheapen the brand and it goes into decline.
The first contact many have with a new product is the installer. So what are companies doing to make a good first impression? Conning them into installing adware / crapware or changing their browser settings. It's insulting, it undermines trust and it cheapens the product by association.
I got so fed up of Adobe loading their updates will crapware like McAfee that I stopped installing it altogether. Likewise I've avoided other products which have started bundling stuff in their installers. I'm sure Oracle are compensated for promoting Yahoo from their installer but the reputational damage will suffer could be immense.
Porting a Java application from Windows to Linux is normally as simple as copying the compiled.jar /.war /.ear over and just running it. The only reason it might not be is it contained JNA or if someone had hardcoded an assumption about the OS into it. Ordinarily neither would be the case and it is not unusual for people to be developing software which ultimately runs on big iron Unix from PCs at their desk.
Porting a C++ application from Windows to Linux means writing it with portability in mind from the very outset, sourcing which libraries you use, rebuilding the code from source and screwing around with the vagaries and differences of different compilers and toolchains. Even in the best of circumstances the code is likely to be plastered with #ifdefs and conditionally compiled code to deal with differences. The best bet would be something like QT which is fairly portable and has a large support library but it's still not as simple as Java.
The Atrix had a dock which turned the Android phone into an Android tablet. Ubuntu hacked it so when you docked the phone it became a proper Linux desktop. How they did it I don't know, but I assume there was some virtualization going on.
PLCs would typically be programmed via IL or STL these days which are designed to be safe (no memory allocation, pointers etc.). Some PLCs even have multi channel execution where the same program is loaded and run on two or more different implementations and if the outputs don't match for the same inputs the PLC goes into error.
I should imagine that programming a car is way too complex for IL or STL and the temptation would be to use C++ but clearly that is a fraught issue, particularly in safety control systems. It probably doesn't matter at all if the media player uses C++ as long as it's running on a separate system entirely.
A segfault in this instance caused by a programming error, not a hacker. And no, they're not good things, particularly if we're comparing two languages, one which will blissfully compile that error straight into your production code and another which tells you about it at compile time.
Ubuntu hacked a Motorola Atrix so it ran Android when you used it like a phone, but plug it into a dock and suddenly it became a full blown Linux desktop. That's a concept ripe with potential. Doesn't have to be Android of course, but just the idea that it's a phone when you carry it around but you can use it as a computer too with a dock with some ports on it.
I'm kind of surprised that Microsoft haven't done something like that yet with an Atom powered phone. As for Ubuntu, I hope for their sake they are because I don't see much reason to use a phone running Ubuntu Linux otherwise.
Your solution to the problem is to try to kill the problem of bad developers by hiding it with the language.
It has nothing to do with "bad programmers". A programmer in one language can be expected to make the same number of errors in their code as a programmer in another. And they can be expected to have a similar spread of competence in their chosen language. It's about how many of those errors make it into the final product, the effort required to test / find / fix them, and the dangers (e.g. to safety, security) if they reach the final product.
C++ suffers from a whole class of problems that are minimal or even non existent in others - memory corruption, heap under/overflows, leaks, bad pointers. That's why languages like C# and Java took off - because companies can deliver a higher quality product in a shorter space of time.
It's also why C++ may find itself being sidelined by the likes of rust, swift etc. These languages offer comparable performance to C++ but will catch errors that C++ wouldn't even notice were errors. In particular rust has been explicitly designed to prevent pretty much every segfault that C++ could suffer from which in a safety system (e.g. running in a car) should be regarded as a good thing.
No no no, you wrote a C++ compiler and you don't even understand why C++ is successful? It's because it still compiles all the old code. You DO NOT deprecate types that are in use in working code. I'm not sure "long double" is in fact used in any working code, but "long long" is THE 64-BIT TYPE so you don't fucking deprecate it.
This is a stupid justification. Gcc already has switches for different standards, -std=c++98, -std=c++11 etc. There is absolutely no reason whatsoever to stop certain functions, and language features from being deprecated or removed in new standards. If people still want to compile old code they can throw the switch in there and they get that functionality. If they don't, the compiler defaults to the latest version of the standard.
The English language isn't defined by a committee which has the opportunity to fix longstanding issues with the language or deprecate redundant, arcane or dangerous functions and code. C++ does have this opportunity but never takes it. Instead it just heaps another layer of features on top of the old, we all sit around for years waiting for the compilers to implement this mess properly and by then another standard has come out.
Personally I wouldn't choose C++ or C unless there was very a strong justification. If your code spends more time waiting for something to happen than actually doing something, then you shouldn't be using a low level language. If reliability is more important than raw performance then you shouldn't be using a low level language. If portability is important then you shouldn't be using a low level language. Conversely if you need to do lots of IO and / or control the file format, or interact with system / kernel services, then perhaps a low level language is suitable.
Boost is a very powerful addition to C++ but that doesn't mean it's as easy to write code as it is in a high level language. e.g. boost's asio is extremely complex and even doing something simple with it like setting a timer is far more pain than other languages. Boost doesn't implement stuff like web sockets or other things either so it's no good on its own without other libraries. If I had to write something in C++ which was performing in a role that would more naturally fall to something like C# or Java, I'd probably use the QT library instead but only after being certain that I needed C++ to begin with.
And that in a nutshell is what's wrong with C++. It has bloated and bloated over the years, never deprecated anything of note and now its this behemoth that few compilers implement in its entirety and few programmers now how to use including all the gotchas, weird semantics and vast complexity.
It's unsurprising that most application development jumped ship to something higher level. It will be interesting to see if languages like rust eat into the systems programming aspect.
They've made it clear in past statements that they want to go to a software as a service model. So I think it is very likely that at least some consumer versions of Windows will do some insidious things - advertising, artificial ringfencing of "premium" features that can be unlocked for a low, low price, cloud services & storage, moving functionality out to the app store (games, backup software etc.).
I don't think professional and enterprise users will be happy about this so they'll have to sell a conventional licenced version too.
Slashdot Mirror
Not from some lame VR game, but because people will become disoriented, trip over something and smash their heads in.
Ultimately the application may end up an embedded device, where space is at a premium. In that instance I'll probably have to static link but it depends on licencing issues.
Is there really a large audience demand to see a dramatisation about a sociopath whose company made computers and gadgets?
It breaks down to about 25MB icu and 13 MB of QT on QT 5.4 on Windows.
Most desktop OSes would have services that could provide that information and do encodings and transformations between character sets. I don't see that QT needs to ship all of it. Aside from that my app is localizable so I can't do away with the way its implemented either.
My, aren't you the patronising one?
It's modular but it's still got bloat. I'm writing an application which has a fairly modest UI that has a main window, some tabs and dialogs. The weight of the runtime I have to ship with it - icu*, Qt5core, Qt5Guid.dll, Qt5Widgets runtimes is nearly 38MB. Most of the modular bits with the exception of webkit - (multimedia, networking, OpenGL, SVG etc.) are comparatively lightweight compared to the slab of unavoidable "core" stuff that you need whether you like it or not.
No matter how bad the Greek crisis gets, no matter how much of a haircut people get on their savings from any currency swap, it will still be less risk than bitcoin.
Canonical were involved. There are vids shot in their offices demoing it.
Same principle applies to Adobe and Flash. They make nothing from the Flash player but its all those eyeballs are what make professionals want to buy the dev tools that they do make money from. Cheapen the brand and it goes into decline.
I got so fed up of Adobe loading their updates will crapware like McAfee that I stopped installing it altogether. Likewise I've avoided other products which have started bundling stuff in their installers. I'm sure Oracle are compensated for promoting Yahoo from their installer but the reputational damage will suffer could be immense.
Porting a C++ application from Windows to Linux means writing it with portability in mind from the very outset, sourcing which libraries you use, rebuilding the code from source and screwing around with the vagaries and differences of different compilers and toolchains. Even in the best of circumstances the code is likely to be plastered with #ifdefs and conditionally compiled code to deal with differences. The best bet would be something like QT which is fairly portable and has a large support library but it's still not as simple as Java.
Yes and Canonical worked on it too.
Bzzzt, wrong. Motorola is the one that implemented the modified Ubuntu desktop when docking the Atrix. It was not Canonical that did that.
Bzzt, wrong. Canonical did although Motorola may have licenced what they produced or cooperated.
The Atrix had a dock which turned the Android phone into an Android tablet. Ubuntu hacked it so when you docked the phone it became a proper Linux desktop. How they did it I don't know, but I assume there was some virtualization going on.
I should imagine that programming a car is way too complex for IL or STL and the temptation would be to use C++ but clearly that is a fraught issue, particularly in safety control systems. It probably doesn't matter at all if the media player uses C++ as long as it's running on a separate system entirely.
A segfault in this instance caused by a programming error, not a hacker. And no, they're not good things, particularly if we're comparing two languages, one which will blissfully compile that error straight into your production code and another which tells you about it at compile time.
I'm kind of surprised that Microsoft haven't done something like that yet with an Atom powered phone. As for Ubuntu, I hope for their sake they are because I don't see much reason to use a phone running Ubuntu Linux otherwise.
Your solution to the problem is to try to kill the problem of bad developers by hiding it with the language.
It has nothing to do with "bad programmers". A programmer in one language can be expected to make the same number of errors in their code as a programmer in another. And they can be expected to have a similar spread of competence in their chosen language. It's about how many of those errors make it into the final product, the effort required to test / find / fix them, and the dangers (e.g. to safety, security) if they reach the final product.
C++ suffers from a whole class of problems that are minimal or even non existent in others - memory corruption, heap under/overflows, leaks, bad pointers. That's why languages like C# and Java took off - because companies can deliver a higher quality product in a shorter space of time.
It's also why C++ may find itself being sidelined by the likes of rust, swift etc. These languages offer comparable performance to C++ but will catch errors that C++ wouldn't even notice were errors. In particular rust has been explicitly designed to prevent pretty much every segfault that C++ could suffer from which in a safety system (e.g. running in a car) should be regarded as a good thing.
So you intend to drive around in a shit heap all your life to avoid the very slight possibility that your car will be hacked?
No no no, you wrote a C++ compiler and you don't even understand why C++ is successful? It's because it still compiles all the old code. You DO NOT deprecate types that are in use in working code. I'm not sure "long double" is in fact used in any working code, but "long long" is THE 64-BIT TYPE so you don't fucking deprecate it.
This is a stupid justification. Gcc already has switches for different standards, -std=c++98, -std=c++11 etc. There is absolutely no reason whatsoever to stop certain functions, and language features from being deprecated or removed in new standards. If people still want to compile old code they can throw the switch in there and they get that functionality. If they don't, the compiler defaults to the latest version of the standard.
The English language isn't defined by a committee which has the opportunity to fix longstanding issues with the language or deprecate redundant, arcane or dangerous functions and code. C++ does have this opportunity but never takes it. Instead it just heaps another layer of features on top of the old, we all sit around for years waiting for the compilers to implement this mess properly and by then another standard has come out.
Boost is a very powerful addition to C++ but that doesn't mean it's as easy to write code as it is in a high level language. e.g. boost's asio is extremely complex and even doing something simple with it like setting a timer is far more pain than other languages. Boost doesn't implement stuff like web sockets or other things either so it's no good on its own without other libraries. If I had to write something in C++ which was performing in a role that would more naturally fall to something like C# or Java, I'd probably use the QT library instead but only after being certain that I needed C++ to begin with.
It's unsurprising that most application development jumped ship to something higher level. It will be interesting to see if languages like rust eat into the systems programming aspect.
I don't think professional and enterprise users will be happy about this so they'll have to sell a conventional licenced version too.