Follow Slashdot stories on Twitter


Forgot your password?

Comment Re:Gnome 3 (Score 1) 402

Gnome 2 disabled the ability that existed in almost all earlier X11 window managers to work with overlapping windows, by forcing you to raise windows on click.

There was an option in gconf to turn off raise-on-click, but for some reason it also disabled the ability of a program to raise its *own* windows. This effectively makes the option useless. The obvious reason is because the designers did not want that, because it might confuse those poor Windows users (Windows also forces clicks to raise windows). The gconf included a long comment about how absolutely logical and necessary this was and how any program relying on the ability to *decide* whether to raise on click was "broken". Surely one of the biggest pieces of bullshit I have seen in a long time. And these people are still working on this, making it worse and worse.

Comment Re:How safe? (Score 1) 109

The text is designed to be copied and pasted into a terminal.

Generally this is a lot easier than "find Registry Editor here on the start menu, now click here, here, here and then scroll down to find this item, now paste in this text which is just as mysterious as any Linux command".

It is true that when it does not work there is not a lot of help.

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.

Slashdot Top Deals

To restore a sense of reality, I think Walt Disney should have a Hardluckland. -- Jack Paar