Comment Re:Sheesh (Score 1) 1352
Do you also think it's a problem that some programs on the Cable News Network are not news?
Yes.
Do you also think it's a problem that some programs on the Cable News Network are not news?
Yes.
Bill O'Reilly admitted as much on Real Time with Bill Maher on HBO. The problem is that The O'Reilly Factor airs on a channel called Fox News.
Cunning indeed!
The batteries do not have a constant cost. They have a decreasing cost as even damn blurb said so "price of consumer lithium-ion cells has fallen 6 to 8 percent annually since their 1989 launch price of consumer lithium-ion cells has fallen 6 to 8 percent annually since their 1989 launch" Seriously wtf did you put any effort in your ideas at all?
The cost decrease is over time and not necessarily based on volume. The cost decrease over time is probably due in part to volume but there's a part of the decrease that's due to research and development in producing these batteries.
One morning Julian Assange will awaken to see an unmanned drone hovering outside his bedroom window. It will fire a small but deadly missile through his window, ending his miserable little life. And I will smile...
Is that you Prince Andrew?
It's probably Tom Flanagan.
I have to agree that, in this particular release, it doesn't seem like the information that has been published has provided any benefit to the public. Killing the messenger won't make things better or stop future leaks. I do believe that the person that provided the information to Assange should remain in jail for a long time.
The US government sent thousands of young men to die based on lies.
You lefties keep saying that like if you repeat it often enough it will become true... or least Truthy. But it just ain't so.
People keep saying that because it's true. The Iraq war was based on a lie. There were no WMDs. There was no known threat from Iraq. Osama Bin Laden is still out there. Denying it will not bring back the people that died. I'm sure that there were many righties and lefties.
I don't understand your frustration with WikiLeaks.
The thing I understand even less however, is that your sig seems to argue that freedom of speech is good yet you are unwilling to accept that this freedom be given to others. Where do you draw the line? Why is it OK to ridicule the prophet of millions while it's wrong to provide government information? The US government sent thousands of young men to die based on lies. Don't you want the truth to be told?
Infinity isn't a number.
Right
If anything, the concept represents a "really really big positive number" in this context, in which case, yes, if you add something greater than 0 to that really really big number, then you will have an even bigger number.
If I remember, and understood, my college math properly:
In mathematics, k+inf. is inf. but you wouldn't represent it that way. It would probably be a limit. So the limit of a+k as a approaches infinity is infinity. Are they the same?
You could consider the limit of (a+k)/a as a approaches infinity, this limit is 1 so it would appear to be the same.
If you consider the limit of (a+k)-a as a approaches infinity then the limit is k so it would appear that they are different.
So I don't think you can say whether they are the same or not but, within some contexts, you could consider them to be the same or different based on that context.
IANAM
If you're not rational enough to be an atheist, you should not be allowed into medical school.
Here's a conundrum for you ass-wipe. I'm an atheist, my degree is biology and I oppose embryonic stem cell research. It's not needed.
Let S1 = "If you're not rational enough to be an atheist, you should not be allowed into medical school."
Let S2 = "I am an atheist."
Let S3 = "I am smart enough to be in medical school."
Prove that S1 and S2 doesn't imply S3.
I don't know if GC uses refcounting at all, though I suppose it's possible.
However, the point is that the reference counting itself isn't just the extra bytes of RAM, it's the extra bytes of CPU cache. It's the difference between a chunk of your program fitting in cache and running insanely fast, then being paged out for GC to run (and GC sits in cache during its run), and that same program needing the refcounting, malloc/free, and a bunch of other housekeeping stuff always hot in cache, meaning it's likely your program will have to have chunks of it paged in and out of cache much more often.
Actually, ref-counting is mostly just the extra few bytes. An auto_ptr (or a unique_ptr or a boost::scoped_ptr) doesn't even use the extra bytes because it has single ownership. When they go out of scope, the object is destroyed. No extra byte; no complicated memory management. The C++ compiler knows when the object goes out of scope and will call the destructor at that time.
For boost::shared_ptr, there's extra memory for reference counting because there can be multiple owners. But, again, I'd be surprised if a GC-based language wouldn't use reference counting. Perl, for example, uses reference counting exclusively *because* it's much faster than other schemes. It has the same drawback that C++ has which is that circular references may leak.
Paradoxical, and I'm not convinced, so I'd want to benchmark it. It does seem plausible, and I did read it in a respectable-looking paper.
If you have a link to that paper I'd like to see it. As I said, there's not much more to reference counting other than incrementing a value when the object is assigned a new owner and decrementing that same value when it's being released. The allocation is done once and there is a single delete.
So no, I wasn't talking about the GC keeping anything "in memory" (as opposed to what?) -- yes, once the object isn't referenced, its data is meaningless.
And yes, I'm pretty sure malloc/new implementations have, at least at one point, been direct system calls. I imagine they still are, on some embedded platforms.
I've programmed in C and other procedural languages, Pascal for example, for a long time. I've never seen a single implementation that would make a system call for each malloc/free call. If you know of one, again, I'd be interested to have a link.
When you're starved for memory, it makes sense -- you want everything free'd for other processes to use as soon as you possibly can.
When delete is called (or free in C), the memory used by the object is made available immediately. This requires a call to the C or C++ library, if that's what you mean, but this is not a system call. It doesn't require an intervention from the OS except, maybe, in a multi-threaded application. If this library call is what you mean by "system call" then yes it has some overhead. I have heard of implementations of new/delete that accumulate the delete in order to gain a few extra cycles. But when you need these extra cycles you probably should be programming in C++.
Good to know about boost -- though now I'm curious what the difference is.
For most purposes, smart pointers will do the job real fine. There's none to little overhead and you get the advantage that you know when your objects get destroyed.
Well, again, what do you mean? If we're talking about std::auto_ptr -- that is, a refcounting pointer -- then while I haven't done the benchmarks to back it up, I'd guess refcounting can actually be worse than GC in terms of performance. In particular, with a garbage-collected language, the garbage collector presumably runs at intervals, and is highly optimized -- the whole thing probably fits in cache. This means when the GC isn't running, there's no memory-management-related code running. By contrast, with refcounting, you're at least dealing with the reference count all the time, and you're making calls to delete or free more often...
On the other hand,
First off, I'm not an expert in memory management. I graduated in the 90s and I'm sure things have changed quite a bit since then. That is, I may be wrong and you can prefix everyone of the next sentences with "As far as I know."
Reference counting has very little overhead. Memory wise it adds a few bytes and time wise, it adds almost nothing as well. A GC will probably use reference counting to speed up detection of unused memory and only perform mark-and-sweep or whatever is needed to resolve circular references after that. I'm pretty sure that there's just as much, if not more, memory-management related code in a GC based program even when the GC is not running. I haven't done any benchmarks either.
auto_ptr is probably not the smart pointer you want to use. You're better off using boost's smart pointers. The problem with auto_ptr is that they don't play along nicely with containers.
As far as keeping unused objects in memory for cache, I don't think that GCs can do that. Once the object is no longer referenced, its data is meaningless. Also, I'm pretty sure that malloc/new implementations have never resulted in systematic calls to the OS.
It's not that complicated.
In theory, it's simple. In practice, not so much -- the bugs which can happen here are numerous and subtle.
That's true. It's also true of other languages but there are probably more issues with C and C++ than there are with many other languages.
There are also plenty of GC libraries for C++
And my point here was that by the time you use a GC library, why not get the full benefit of a safer, saner language? You've already got most of the overhead of something like Java, why not also get the runtime optimizations and the protection from buffer overflows and segfaults, too?
For most purposes, smart pointers will do the job real fine. There's none to little overhead and you get the advantage that you know when your objects get destroyed.
it's possible to select which objects are GC candidates and which are not
And what'd be the criteria for which objects should be GC'd and which you want to handle yourself?
I'd guess the objects which you want to manage yourself are either places where you're interacting with code, or particularly performance-critical parts of your application. But if you're doing it that way, it seems to me that I get most of the same benefit by coding in Ruby, and dropping down to C for those two cases.
It seems you could get similar benefits in Java if JNI wasn't such a bitch -- and even as it is, it isn't that bad compared to pretty much anything else in C.
I've never had to use a GC in C++ so I'm mostly guessing here. One situation where I'd want to use GC is if I had several containers sharing the same objects and none could be considered the owner. If there's an owner, then using a weak pointers for other containers does the trick.
As far as performance is concerned, going from managed to unmanaged code was relatively expensive in Java with JNI when I used it. Hopefully Ruby is better at it. I don't think you're wrong in that the vast majority of cases don't need the performance provided by C++.
There's another thing you might want to look at when talking about performance. C and C++ will usually have much lower memory requirement and there's no interpreter to load. If performance is an issue, it might be simpler to stick to C++
I just don't think the memory leak issues in C++ are as bad as many people try to make them to be.
I don't think they're particularly bad either, but I don't see any reason I, as a programmer, should have to deal with them. I certainly don't think C++ has any real place in web development -- except, as I mentioned, in particularly performance-critical bits, especially when they can be abstracted into libraries. I trust the HTTP parser in nginx or Apache a lot more than any code I wrote myself, but anything I write, I trust a lot more in Ruby or JavaScript than in C or C++.
If performance is not an issue, I wouldn't use C++ either unless there's some reason to. I've implemented some proof-of-concept in C++ but I did so because I had to interface with our code base. At other times I've used Perl, Java and C# when I could choose.
By contrast, it's trivially easy to leak memory in a non-garbage-collected language, and again, "smart pointers" (just refcounting, right?) are still more likely to leak memory, and potentially add even more overhead than real GC.
There are ref counting smart pointers but there's also weak pointers and unique pointers. For the majority of stuff you just want to ensure that the resource is released when the resource's owner goes out of scope. It's not that complicated.
There are also plenty of GC libraries for C++ so it's possible to select which objects are GC candidates and which are not - best of both worlds.
So, may as well just use GC, and if you're doing that, may as well just use something like Java. (Though not, I'd hope, Java itself.)
GCs have other issues aside from efficiency. They make it much harder to have real-time guarantees. They make it harder to free up resources in a deterministic manner although C#'s using statement makes this much easier. Also a good number of Java and C# programmers probably don't even know about weak pointers so I'm pretty sure memory leaks exists in most non-trivial programs in GC languages too.
Sometimes I prefer Java or C#. Sometimes I prefer C++. I just don't think the memory leak issues in C++ are as bad as many people try to make them to be.
If all else fails, lower your standards.
