Yesterday I posted about rvalue references and move semantics. What's really impressive to me is the range of problems solved by the introduction of rvalue references. An interesting example of this is removing sharp edges from my old friend std::auto_ptr, allowing it to be deprecated in favor of the new std::unique_ptr.

std::auto_ptr was introduced to provide a RAII wrapper to pointers. This means you can put the logic of "I want to allocate memory here that I'll clean up at the end of the function" all in one place rather than scattering that logic around a function. It also means a factory can return an auto_ptr and not worry about leaking memory. That is, if create() allocates an object of type T and returns a pointer to it, the caller can't really know (short of documentation) if the object returned needs to be deleted later or if it's just a pointer to an existing object. With auto_ptr, you can do this:
std::auto_ptr<T> create();

create(); // OK, creates a T that 
          // gets deleted because the temporary auto_ptr goes out of scope.
T* it = create().release(); // Safe -- calling code is knowingly taking 
              // responsibility for the memory.
std::auto_ptr<T> it = create(); // Safe

This is all well and good. It gets murky, though. As described, auto_ptr has very odd copy semantics. In particular, copying modifies the source of the copy(!) This means that you can't copy a const auto_ptr<T> (which has its own interesting ramifications—see Herb Sutter link below), but it also means you can't expect auto_ptr to play nice with containers or algorithms that expect assignment to just—I don't know—assign.

That murkyness has a silver lining: It allows for an idiom like the factories-return-by-auto_ptr usage above but for consumers: consumers take auto_ptr by value (not reference). This makes consumers relatively safe:
std::auto_ptr<T> produce();
void consume(std::auto_ptr<T> x);

std::auto_ptr<T> it = produce();
consume(it); // Safe (but quietly leaves it set to NULL).
T* baz = new T();

consume(baz); // Safe -- Won't compile -- you'll be 
              // told it wants an auto_ptr by value.
consume(std::auto_ptr<T>(baz)); // Safeish -- you will 
           // still have baz after this, but you should 
           // know better than to use it.

The danger is that anyone who takes an auto_ptr could slurp it up (even if they don't now, they could change to take it by value some time down the road, and your code wouldn't change!).
void looks_innocent_0(const std::auto_ptr<T>& x);
void looks_innocent_1(const std::auto_ptr<T> x);

std::auto_ptr<T> it = produce();

looks_innocent_0(it); // Looks like it's just looking at it.
looks_innocent_1(it); // Looks the same but actually steals it.
consume(it); // Screwed: it is NULL.

For more on auto_ptr, see Herb Sutter's Using auto_ptr Effectively.

Enter unique_ptr.

unique_ptr is almost exactly like auto_ptr except that it doesn't have the weird move-on-copy semantics. Instead it has no copy operation at all, just std::swap(•,•) and construction and assignment from an rvalue reference; that is, explicit move-assignment otherwise using std::move. The only time the cooky move-assignment happens implicitly is when nobody is looking when the rvalue is the unnamed temporary as it is returned from a function. With that, the above examples Just Work except for where implicit moves were happening, there you have to make the move explicit:
std::unique_ptr<T> create();

create(); // OK, as above.
T* it = create().release(); // Safe, as above.
unique_ptr<T> it = create(); // Safe -- move-copy from rvalue reference.

std::unique_ptr<T> produce();
void consume(std::unique_ptr<T> x);

std::unique_ptr<T> it = produce();
consume(it); // Very safe -- no funny business -- will not compile!
consume(std::move(it)); // Safe -- We say what we mean and won't get a leak.

T* baz = new T();

consume(baz); // Safe -- Won't compile -- you'll be 
              // told it wants a unique_ptr by value.

consume(std::move(std::unique_ptr<T>(baz))); // Safe -- you will 
           // still have baz after this, but you should 
           // know better than to use it.

void looks_innocent_0(const std::unique_ptr<T>& x);
void looks_innocent_1(const std::unique_ptr<T> x);

std::unique_ptr<T> it = produce();
looks_innocent_0(it); // Safe
looks_innocent_1(it); // Safe -- won't compile
consume(std::move(it)); // Safe!

So far I'm a fan. See also: Who'se the smartest of 'em all? Get to know std::unique_ptr.

Update Comments locked due to spam.


After helping 3M move Lava C.O.S. to a great new team in St. Paul, I've started work with someone new project which involves some C++ programming, this time with Visual Studio 2010, which includes several important C++0x features I had been introduced to in David Musser's Generic Programming course in grad school.

The most interesting (and at first baffling) is rvalue references. They have the dubious syntax of && but are not a reference to a reference (whatever that would mean); it is a special type of reference that at compile time is known to be basically an unnamed temporary. Having this distinction lets you do a number of interesting optimizations related to moving objects around; so-called move semantics.

Collapse )

All You Kneed

I just took the All You Kneed class at The Cambridge School of Culinary Arts. The class was quite good. The biggest thing I learned was that kneeding takes a long time. Here is one exchange on that:

~70-year-old student: How do I know it's done?

Prof: At some point, it'll get stiff, it'll stay stiff and lumpy, then eventually get elastic and smooth. It'll look like a baby's behind.

~70-year-old student: I guess it's not done yet; right now it look's like a senior citizen's behind.

(Also, when you poke it it should spring back.)

I think I need to take a carb-induced nap, now.
  • Current Music
    Wait Wait... Don't Tell Me!
  • Tags

Details make the design

The details are not the details. They make the design.Charles Eames

I posted a while ago about the difference between Helvetica and Areal—that one just looks right and the other doesn't. The differences are subtle, but they make the design.

Here's a similar example: Not all molded-fiberglass chars are the Eames molded fiberglass chair.

If you've ever been to a lecture at RPI, you have probably been to the Darren Communications Center (DCC), at the middle of campus, where all huge courses are taught, including the 500-yellow-seat DCC 308:

Photo: Chris Tengi

I've always thought this sea of yellow fiberglass looked horribly dated and institutional:

Photo: smfny

I just put my finger on it: It wishes it were this:

Photo: Me

As it is, it looks like it's this:

The original has minimal flange around the edge, a curved seat, removing unnecessary corners, a deep seat, that essentially melts side gussets into the seat/back, and an elegant back that flexes gently.

The impostor basically has a rectangular seat and rectangular back with the back held up by a thick flange that makes the chair relatively rigid, but also prone to cracking (as anyone who's seen them knows).

Eames wasn't kidding. The details make the design. Here's what his wife and his design looks like in an auditorium setting:

Renderings: Herman Miller

It will always be Modern, but by getting the details just right, it is still contemporary (if not clichéd).


It has been nearly 11 months since Boston's best rock station, WBCN, went off the (analog) air. Since then, Free Form BCN has gone from robotic to occasional tests to now a regular program from 11 am to 2 pm weekdays. It's an entertaining relaxed DJing style with an eclectic mix of rock music.

Give it a listen: Go to and click on the Free Form BCN logo at lunch at work.

You can also listen on your iPhone with the CBS Radio app.

Either way, show your support: Listen and friend them on Facebook.
flaming unicycle

Understanding image sensor characteristics

Dear Lazyweb,

Can you explain image sensor specs to me? I am trying to understand where the brightness limit is at which shot noise dominates, and understand how to compare sensor specs.

Forgetting for a moment about dark current and photo-response non-uniformity (PRNU), I see a pixel on a sensor as taking in a certain number of photons and turning them into a certain DN number, (zero to 255 for 8-bit images). Now, ideally you might have a 32- or 64-bit sensor so you could actually count the number of electrons that built up, but for whatever reason, that's not how these things work. Instead, you build up electrons and then use an A-to-D converter (with its own gain and offset) to get the DN. This gain is the ISO setting on a camera.

Why, then, do sensor specs talk of "sensitivity"? I'm fine with the notion that the A-to-D converter will have some noise, either in how many electrons it can count as one or in its output; that makes sense. But what does it mean to have a sensitivity of 8.40 V/(lx·s)? I read that as the conversion from lx·s to volts... but isn't that captured by the quantum efficiency times the fill factor? That is, before we digitize the counts, doesn't QE·FF completely define how much signal there is to digitize?

Along the same lines, why all this talk of volts at all? If each photon that excites an electron is bumping it over a potential, then won't each electron be charged to the same voltage, rather than building up voltage? Wouldn't they be building up coulombs not volts?

In one spec, I see "conversion gain" in microvolts per electron (17.6 μV/e); is that the number of volts of charge a photosite gets for each electron?

I see saturation charge of 62,500 e&minus;. I assume that's the well depth. Is that to say that the maximum charge on a photosite is 17.6×10−6 V · 62,500 = 1.1 V? Does that correspond to "Output signal amplitude" of 1 V?

Sensitivity is given either in Vm2/(W·s) or V/(lx·s). If I understand the conversion gain above, then I can use it to convert these to electrons per lux-second. Is that right?

I feel like I would really just like to know the PDF of the random variable that is the output DN as a function of exposure time, light flux, and amplifier gain, so I can approximate an image I would get from a given sensor, but these specs don't seem to make that easy.
flaming unicycle

LCD Issue

What causes this in a monitor?:

This happened to my old monitor; I replaced it, but just don't have the heart to throw out the old one. While it is a bit smaller than my new one, the image quality (when it worked properly) was just a bit better in a hard-to-define way. (I'm sure I could define it if I knew LCD technologies...)

These are vertical stripes that shimmer and seem to have something to do with the signal on the screen. They aren't stuck pixels or even stuck bits (best I can tell). It started out as one and got progressively worse. It is particularly bad on text.

The input source doesn't matter (here it's showing the unplugged-monitor screen saver).

Can I fix this, or do I use this as an opportunity to dissect an LCD down to its light-control film, light guide, and backlight?

Projector cooldown

Dear Lazyweb,

Why when I turn my projector off, does the fan spin up for a few minutes? My first thought was that it doesn't make sense, because it's not getting any hotter what with the power being off. Furthermore, cooling it off fast will only heat-cycle it harder. On the other hand, maybe the filliment is soft; maybe this is protecting it from the once in a blue moon that I'll move the thing right after watching? My only other thought is that there is some component that would get hotter before it got cooler if the fan didn't stay on, but that (a) sounds bogus and (b) seems like a design way too close to the edge and (c) doesn't explain why the fan would have to spin faster for cool-down thanfor steady-state projecting.

Stopping Deepwater Horizon

The Deepwater Horizon oil spill has been going on for over a month. Would it work for them to freeze it stopped? I realise the oil flow rate is high, but ice has a way of clogging flow. I'm picturing attaching a freezer element to the riser pipe and freezing the pipe, the water around it, and, hopefully the oil from the inside of the pipe.

(No, I haven't cracked open Heat and Mass Transfer to do a back-of-the-napkin calculation.)

Clay bar

I finally tried a clay bar for cleaning my car. I was a bit dubious. You basically just spray a lube on the car and slide clay over it. It doesn't feel like it's doing anything; no elbow grease needed. Amazingly it works. Nothing else has cleaned off the grime that builds up on the pannels behind the wheel wells, but this did it easily without scratching.

Basically, the clay hydroplanes on a very thin skim of liquid. When it encounters grime, it grabs it and conforms to it, quickly absorbing the grime so it too quickly hydroplanes and so doesn't scratch like when you try to clean that stuff up with a cloth or something else (visco)elastic. It's the viscoplasticity of the clay that works the magic.

Disclosure: My employer, 3M, relatively recently acquired Meguiar's.

Posted via