Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Slashdot Deals: Cyber Monday Sale! Courses ranging from coding to project management - all eLearning deals 25% off with coupon code "CYBERMONDAY25". ×

Comment Re:Climate modeling (Score 1) 330

I'd like to know what "predictions" have such wildly sqiggly graphs.

I suspect this graph is meaninless bunk unless you can come up with a really good explanation for what those "44 lines" mean. Best guess (after the "it's all made up" guess) is that somebody scribbled lines between the maximum error bars of all of them.

Comment Re:Climate modeling (Score 1) 330

There has been at no time proof of deliberate deception. It is all asserted without evidence.

Holy crap are you stupid.

He chose the hottest possible year as the "baseline" to start the predictions from, so they are as high as possible, then chose a totally different "running average" which also causes that hottest year to produce a flat line (notice that his "plot" of temperatures starts flat and increases in slope, completely contrary to normal denialist claim that warming has slowed). What are the odds that out of 30 or so years to choose from, he would choose the one with the greatest height above the average linear line? The odds that this is deliberate deception are about 30:1.

The fact that you see unable to see this is just an indication that you are a close minded idiot.

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 Time (Score 4, Informative) 370

That's the only real solution. All of those people who are hassling you now, will be hassling somebody else in the future. I hope that the "popular forum" you mention isn't something that's vital to your life; if it isn't then abandon it. If it is, it's a more interesting question.

If you need to continue to participate in that forum, I would suggest you just be yourself. Say what you believe, and don't get too fussy about it.

I've heard from a lot of women who participate in public fora that this kind of abuse is not just commonplace, it's ubiquitous. You might also think of the 34,000,000 people doxxed last month. It's just a common thing, it's going to happen to everybody sooner or later.

Comment A different way to use a comet (Score 1) 99

I think that NASA's idea is interesting...very challeging, as other have noted, but worth it if it could be done.

I have been toying with the idea for an SF story using comets. Spaceships would wait for a comet to come by, then embed themselves into the tail of the comet, and use some kind of ramjet propulsion to accelerate out of the inner solar system. Obviously comet tails are not dense at all (a less dense vacuum than what can be made on earth) but the ion tail should be manipulatable.

Anyway, in the story, people in their spaceships end up flying out in more-or-less random directions, and hoping to find something interesting in the process.

You don't have to know how the computer works, just how to work the computer.