I entirely agree, installers should only be allowed access to specific files and directories, but that's relatively hard to do. Especially in Windows, where those files and directories may be scattered across the system rather than being in well-known places.
No it's not. All the folders an application should need access to, such as their application data folder, temp directory, etc, are all easily accessibly by environment variables and thus no matter if you are using XP or Win7 your files will get laid done in the correct directories. Your complaint is with application developers being historically lazy in doing things the right way.
But those are all static pages. Of course if you are doing nothing but displaying static content it makes sense to not use JS. Slashdot used to be perfectly fine long before they made it so JS heavy as well. Apparently, though, it was way more fun to create a laggy AJAXy experience over fixing the bugs in the older discussion system.
It doesn't matter if they have a trademark on the specific word. If someone uses a mark that is similar to something you use and they are within the same industry you risk diluting your mark and losing it. Which is why Microsoft was basically required by law if they wanted to not lose their Microsoft trademark to sue the guy who started "Mike Rowe Soft".
If C++ supported closures you could replace the ~10 lines of C++ code in the example you linked to with 3- and you wouldn't need to create the clutter of a new class to just to create a closure.
Who says you have to create a class to create a closure? Where did you get that nonsense from? I think you misunderstood his example. From the article:
a closure (also lexical closure, function closure or function value) is a function together with a referencing environment for the nonlocal names (free variables) of that function.
C++0x has exactly that with lambda functions. No one is redefining anything. For example:
[](int x, int y) { return x + y; }
This is a perfectly valid example of a closure that fits the accepted definition of what a closure is.
Which is why many of them still write code that leaks memory even with a garbage collector. One of the worst offenders are the.NET programmers who write software that leaks GDI handles like crazy and cause all sorts of crashes and bizarre behavior because they didn't bother to learn anything about managing memory and realizing that *gasp* even in a GC language you still need to make sure to be careful that all your resources are being properly released. This is further compounded because there have been a number of bugs in.NET that have caused even well-written code to leak GDI handles.
Well, that's typical sectarian. "If it doesn't work for you, it is you who did something wrong".
In many cases it is you who is probably doing something wrong.
C++ imposes a massive burden on the programmer. You have to be a lot smarter than with other, better programming languages just to get something done reasonably well.
Oh noes! You actually have to be smart to be a C++ programmer. Oh the horror!!! THE HORROR!!!!!!!! Wait, why is that a bad thing? We have enough incompetents writing software as it is. We don't possibly need to lower the bar any further, do we?
They are both compiled locally to native code on the local machine, which can potentially lead to better optimizations than the else-where compiled C++ binaries. In practice, the C++ will still be faster, but lets not get ahead of ourselves.
And if you want the benefit of optimization based on runtime data such as in.NET or Java, just use Profile-guided optimization which has been available in MSVC++, Intel's C++ compiler and GCC for years now. You get all the benefits of a runtime optimization of a JIT-compiled language without the overhead combined with much more extensive compile-time optimization that you don't usually get with say Java or a.NET language.
That was meant to be vector<int>::iterator. And obviously in my example this isn't as bad, but say you are dealing with a more complex container declaration and the type of the iterator can expand out like crazy.
Because surely, the hard work of writing code is in all that typing.
No, but when you use a lot of for loops with iterators being able to type, for example, auto i = ivec.begin(); instead of vector::iterator i = ivec.begin(); makes things a lot less tedious and, for me, makes things more readable with less noise obscuring the intent of the code.
It's own guidelines?
No charity or cause funding.
Really? Did you happen to miss:
No charity or cause funding.
Seriously, it's not even that far down in their list of guidelines.
I entirely agree, installers should only be allowed access to specific files and directories, but that's relatively hard to do. Especially in Windows, where those files and directories may be scattered across the system rather than being in well-known places.
No it's not. All the folders an application should need access to, such as their application data folder, temp directory, etc, are all easily accessibly by environment variables and thus no matter if you are using XP or Win7 your files will get laid done in the correct directories. Your complaint is with application developers being historically lazy in doing things the right way.
You do realize that those package managers ask for root access themselves when installing those programs, right?
You might have a point if not for the fact that a lot of warez releases have trojans in them.
(Not that gnome shell is essential, but it proves the point by example, I should think.)
It doesn't.
Except that's what it did mean. Keep digging that hole though.
But those are all static pages. Of course if you are doing nothing but displaying static content it makes sense to not use JS. Slashdot used to be perfectly fine long before they made it so JS heavy as well. Apparently, though, it was way more fun to create a laggy AJAXy experience over fixing the bugs in the older discussion system.
If managed code halves your development time
Then you are dealing with incompetent programmers.
while increasing the CPU load from 5% to 10% when it's running
You are in some cases many orders of magnitude off. 5% to 10% is ridiculously underestimating the overhead.
And, in general, C++ development is most definitely slower than Java if only due to the verbosity and compile times.
This is a joke right? Complaining about C++ being verbose and then trying to hold up Java as a counterexample? Really?
It doesn't matter if they have a trademark on the specific word. If someone uses a mark that is similar to something you use and they are within the same industry you risk diluting your mark and losing it. Which is why Microsoft was basically required by law if they wanted to not lose their Microsoft trademark to sue the guy who started "Mike Rowe Soft".
Perhaps we should ask the Mythbusters?
Yeah, that's extremely funny. What business willfully helps their competitors poach their users or customers? Oh right, none of them.
There are no companies (users in Facebook speak) actively mining your content on Google+.
So Google is not a company?
Even still it's very rare to see such resources run out from a .NET application, especially these days.
Actually it's not. There are still some very popular GUI toolkits built on .NET that will leak GDI handles.
If C++ supported closures you could replace the ~10 lines of C++ code in the example you linked to with 3- and you wouldn't need to create the clutter of a new class to just to create a closure.
Who says you have to create a class to create a closure? Where did you get that nonsense from? I think you misunderstood his example. From the article:
[&](const employee& emp) (emp.salary() >= minimum_salary && emp.salary()
This is a lambda expression which by their very nature are closures since it creates a lexical scope that results in a closed expression.
Because most jabbermouths just keep on blabbing anyway?
There are also various dynamic programming algorithms which simply have runtime memory behavior which is too complex for manual memory management.
Then use the built-in dynamic memory management support of the language.
a closure (also lexical closure, function closure or function value) is a function together with a referencing environment for the nonlocal names (free variables) of that function.
C++0x has exactly that with lambda functions. No one is redefining anything. For example:
[](int x, int y) { return x + y; }
This is a perfectly valid example of a closure that fits the accepted definition of what a closure is.
How is it not very accurate when both lists say basically the exact same thing?
Which is why many of them still write code that leaks memory even with a garbage collector. One of the worst offenders are the .NET programmers who write software that leaks GDI handles like crazy and cause all sorts of crashes and bizarre behavior because they didn't bother to learn anything about managing memory and realizing that *gasp* even in a GC language you still need to make sure to be careful that all your resources are being properly released. This is further compounded because there have been a number of bugs in .NET that have caused even well-written code to leak GDI handles.
Well, that's typical sectarian. "If it doesn't work for you, it is you who did something wrong".
In many cases it is you who is probably doing something wrong.
C++ imposes a massive burden on the programmer. You have to be a lot smarter than with other, better programming languages just to get something done reasonably well.
Oh noes! You actually have to be smart to be a C++ programmer. Oh the horror!!! THE HORROR!!!!!!!! Wait, why is that a bad thing? We have enough incompetents writing software as it is. We don't possibly need to lower the bar any further, do we?
They are both compiled locally to native code on the local machine, which can potentially lead to better optimizations than the else-where compiled C++ binaries. In practice, the C++ will still be faster, but lets not get ahead of ourselves.
And if you want the benefit of optimization based on runtime data such as in .NET or Java, just use Profile-guided optimization which has been available in MSVC++, Intel's C++ compiler and GCC for years now. You get all the benefits of a runtime optimization of a JIT-compiled language without the overhead combined with much more extensive compile-time optimization that you don't usually get with say Java or a .NET language.
*facepalm* C++0x has closures. For example, here is an article talking about them in C++0x. Hell the article is 3 years old at this point.
That was meant to be vector<int>::iterator. And obviously in my example this isn't as bad, but say you are dealing with a more complex container declaration and the type of the iterator can expand out like crazy.
Because surely, the hard work of writing code is in all that typing.
No, but when you use a lot of for loops with iterators being able to type, for example, auto i = ivec.begin(); instead of vector::iterator i = ivec.begin(); makes things a lot less tedious and, for me, makes things more readable with less noise obscuring the intent of the code.