Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Re:Time to let it die (Score 3, Informative) 242

I was amused when I bought a blender online. I was deluged with ads for blenders! Hint: since I now have a brand-new blender, I am actually the least-likely person to want to buy a blender!

I think I made it worse because I also searched for Blender the software.

Comment Re:What instead of an exception? (Score 1) 262

C++98 did have the "throw" function specification, and in general it was found to be more trouble than it was worth, with the possible exception of "throw()", which should be replaced by "noexcept" in modern C++.

Apparently it was Visual C++ that made "throw()" do what "noexcept" now does: it means you can be certain that this code will not throw an exception. This caused it to be used a lot, but the actual C++ definition of what "throw()" did was not that at all and was quite useless.

"finally" does not exist in C++, fortunately, since RAII is much better. There's no reason you can't allocate on the heap and have destructors clean everything up. That's what auto_ptr was for in C++98 and what shared_ptr and unique_ptr are for in C++11. If you need to worry about what the destructors are doing and what order they're called in, you're almost always doing it wrong. (There may be applications I am currently unfamiliar with where that matters, but that would be unfortunate.) A "finally" block has low cohesion and high coupling, whereas destructors have high cohesion and low coupling.

You are correct that RAII can do everything "finally" does, but it does sometimes require the writing of very strange classes when some kind of finally statement would work better. But to actually work well the statement can't be at the end, it should be next to the definition. Something like this would work just like a local unique_ptr (not suggesting this but imagine a more one-off instance of something that needs destruction):

          char* ptr = new char[BUFSIZE];
          finally { delete[] ptr; }

Comment Re:As always with C++, the truth is more nuanced (Score 2) 262

We're still going to need two objects, one a base object and one a pointer object. If we use raw pointers, the reference count will not be incremented and decremented properly, and we need the reference count to reliably be equal to the number of pointers extant. Therefore, the pointer needs to have its own copy constructor, copy assignment operator, and destructor, which will call the appropriate increment and decrement methods (the decrement method to include the deletion as a special case). If we keep the reference count with the object instead of with the pointer, we can keep the pointer size down without indirection.

This is no more complicated than what has to be done with shared_ptr. And you are confused, you can use raw pointers all you want, as long as you know there is a shared_ptr pointing at the object. This happens in many cases.

We need to document heavily that IRefCount (or something more according to C++ naming) is to be inherited virtually, as otherwise we could have more than one reference count if we add it to multiple levels of a class hierarchy. (C++ multiple inheritance can be tricky to get right.)

So, we've got the pointer object, which will contain the pointer and have some attached functionality, and the reference count mixin. This works as long as we can easily modify the class structure, but it does require a fairly sophistication serialization/deserialization system to keep the modified and unmodified objects in sync. In addition, since it changes the memory layout of a class, it can lead to slow compiles.

It's not a "mixin". It is a base class. This avoids your supposed problems.

With this, we also don't get weak_ptr functionality. A shared_ptr object has a shared pointer count and a weak pointer count. This makes it possible, for example, to have a circular list that can be destructed: have one link be a weak_ptr and everything else a shared_ptr. The object itself is destructed when the shared pointer count goes to zero, and the shared_ptr object when both go to zero. (A weak_ptr does nothing on its own, but can be converted to a shared_ptr if the target object is still there.)

You can implement weak_ptr in EXACTLY the same way make_shared does it. The object is destroyed but the memory is not freed until the weak_ptr count goes to zero. In fact it is fairly easy to have "an object that supports weak_ptr" be a different base class than the plain refcounted object, thus you don't pay for the weak_ptr overhead on every pointer (though you can't make a weak_ptr unless the object is derived from the correct base class).

I don't see this as being easier than shared_ptr, although it is superior for some purposes.

It is enormously easier when you have to do the equivalent of make_shared_from_this (or whatever they called it), and to avoid constructor shenanigans so that the user has to call make_shared and not construct raw objects. The implementation is about the same as shared_ptr.

Boost called this an "intrusive pointer" but they did not support weak pointers. That could be done with a few extra calls. It was a bit ugly as they tried to not define the base class (instead it called functions that the class defined to inc/dec the ref count), I think insisting that everything be based on a refcounted base class would work just fine.

Comment Re: Newtonian physics (Score 1) 369

Did you flunk basic physics?

It is not quarting the momentum. It is increasing the mass, while keeping the momentum the same. This reduces the velocity, but (I suspect more importantly) the momentum is delivered to a larger area of the target, which is what really reduces the lethality.

Comment Re:Dangerous, stupid lies. (Score 1) 622

Huh? Here is the 2nd paragraph of the linked site. It certainly does refute the post above. I think your reading comprehension needs some work:

"Radiocarbon analysis has dated the parchment on which the text is written to the period between AD 568 and 645 with 95.4% accuracy. The test was carried out in a laboratory at the University of Oxford. The result places the leaves close to the time of the Prophet Muhammad, who is generally thought to have lived between AD 570 and 632."

Note that "AD 568 to 645" is different than the Slashdot article lead which says "545 AD and 568".

Comment Re:Study is right, but needs more.. (Score 1) 166

A nuclear accident could easily release a lot more radiation than a coal plant. You are confused by the often-quoted fact that when operating normally, a coal plant can release more radiation. An accident though means the plant is not operating normally.

This may mean that the risk from the radiation from either type of plant when operating normally is pretty low. It's fun to point out that more radiation comes from a coal plant, but I'm pretty certain the danger from breathing the other crap that comes out of the coal plant way outweighs the radiation danger.

Comment Re:What a bunch of stupid Republicans (Score 1) 588

I believe the "stupid Republicans" posts are a troll, possibly from somebody who is actually right-wing. They are designed to look like they are posted by as stupid a person as possible. Have seen a couple equally ludicrous ones for the opposite direction, though they tend to use "Liberals" rather than "Democrats". Sometimes they use the exact same wording as the republican attack. Not as common, however, for whatever that means.

Comment Re:Why would you want this? (Score 1) 66

The intention is to have the database update when the close() is done, not on every write().

It is pretty obvious that the desired functionality could be done by fuse, where a get() is done on open and a put() is done on close if write was ever called.

I think the modern day applications that only write a part of a file are nearly non-existent (and in fact partial update where another program can see your unfinished writing, is usually a bug, not a feature). So there is no need for any api other than put().

There is a nice subset that only reads part of a file (and that part almost always includes the start of the file) however. So I can see this as being an argument for being able to access blocks of data from the remote.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (9) Dammit, little-endian systems *are* more consistent!