It’s time to clear some of them out. Here are some daytime-themed links. (If I had a Tumblr account, I’d just post there. But I don’t need another website no one reads.)

Parallel Computing
James Reinders of Intel TBB fame estimates that datasets (images, videos, etc.) have grown 10x larger over the last five years. Sequential systems are just too dang slow to process this amount of data. In the near future, “parallel programming” will just become “programming.” (I’m still hoping for better language support so that state synchronization and multicore memory issues are as easy to get right as the sequential aspects of programming are now.)

New memory models would certainly help. A new paper, DMP: Deterministic Shared Memory Multiprocessing by Joseph Devietti, Brandon Lucia, Luis Ceze, and Mark Oskin presents some of the problems with the current memory model and provides one possible solution.

Another post on SoftTalk (sponsored by Intel) describes some of the ways that Intel plans to make parallel programming easier this year: Parallel Studio 2010, a Cilk-based offering for task parallelism, “a data-parallel centric model with safety guarantee,” new SIMD instructions, and new array notations.

You might also want a high-level view of how Intel’s offerings work together.

Herb Sutter, who really knows his stuff, wrote an article for Dr. Dobbs a couple years ago about understanding parallel performance. It’s one of a series of articles about multicore/multithreaded programming, and this helps set expectations about what’s possible and gives pointers on where to start making changes.

Miscellaneous
Visual Studio + Time Machine = IntelliTrace. Don’t just move up and down the call stack; now you can move forward and backward in time, too.

Everything you ever wanted to know about floating-point representation: Floating Point Guide. (Everything, that is, unless you work where I do. Then you just have to go down the hall to get that last 2%. Of course, you’ll be drinking from the fire hose. . . .)

What does Microsoft think are the key trends in software development? Cloud computing, the web as a platform, parallel computing, proliferation of devices (with their own capabilities, IO paradigms, etc.), agile development processes, distributed development. Nothing terribly futuristic here, and comments want to know why “mobility” (i.e., phones) isn’t on the list.

The C++0x “final draft” revision is ready for “final” comments. Here’s your chance to see the significant changes to C++ that will be part of the standard next year (they hope).

The major goals of using object-oriented design are to facilitate the maintenance and extension of software systems by reducing the complexity of software at the class and system level. Successful OO designs are resilient to change, largely because they manage interclass dependencies. In such a system, changes to one part of the system are localized and do not cause a chain of modifications through the system.

The major techniques that OO designers have at their disposal are abstraction, encapsulation, inheritance, polymorphism, and composition. But how does an engineer apply these techniques to create a good design? What are the main ways that sets of classes can be structured and interact to maximize the chance of a successful design? Over the last twenty years, numerous OO practitioners have developed a mature set of rules-of-thumb and best practices to use when constructing and evaluating OO design.

If you celebrate it, enjoy your Thanksgiving tomorrow. Don’t do any homework if you can help it. I won’t!

If you’re familiar with the C++ Standard Library, you can start to use your wrapped mxArray like an STL container. I use the term “like” advisedly, since it’s not actually a container. To reduce memory overhead, I don’t make a copy of the data that gets put into ArrayWrapper. Consequently, it doesn’t model the container concept that element lifetimes are the same as the “container” lifetime. You’re shouldn’t count on being able to use ArrayWrapper with any ole STL function. But then again, you might be able to use it with some; I haven’t tried.

#include "mex.h"
#include <cstddef>

// Treat an mxArray like a container.
// (See Josuttis. "The C++ Standard Library." 1999. p. 219-220)
template<class T>
class ArrayWrapper {
  private:
    T      *v;
    mwSize thesize; 

  public:
    // Type definitions
    typedef T         value_type;
    typedef T*        iterator;
    typedef const T*  const_iterator;
    typedef T&        reference;
    typedef const T&  const_reference;
    typedef mwSize    size_type;
    typedef ptrdiff_t difference_type;

    // Constructor
    ArrayWrapper(const mxArray *theArray)
    {
        v = static_cast<T*>(mxGetData(theArray));
        thesize = mxGetNumberOfElements(theArray);
    }

    // Iterator support
    iterator begin() { return v; }
    const_iterator begin() const { return v; }
    iterator end() { return v + thesize; }
    const_iterator end() const { return v + thesize; }

    // Direct element access
    reference operator[](size_type i) { return v[i]; }
    const_reference operator[](size_type i) const { return v[i]; }

    // Size is constant
    size_type size() const { return thesize; }
    size_type max_size() const { return thesize; }
};

void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
    const mxArray *inputArray = prhs[0];

    ArrayWrapper<uint8_T> inData(inputArray);

    // 1- Count the number of samples in the image.
    mwSize count = 0;
    ArrayWrapper<uint8_T>::const_iterator i = inData.begin();
    while (i++ != inData.end())
    {
        count++;
    }

    mexPrintf("The image has %ld samples.\n", count);

    // 2 - Halve the image values.
    mxArray *outputArray = mxDuplicateArray(prhs[0]);
    ArrayWrapper<uint8_T> outData(outputArray);

    i = inData.begin();
    ArrayWrapper<uint8_T>::iterator j = outData.begin();
    while (i != inData.end())
    {
        *(j++) = *(i++) * 0.5;
    }

    plhs[0] = outputArray;
}

Is there a portable way to refer precisely to datatypes of a particular size? Yes, in C99 #include <stdint.h>.

Use signed integer types larger than char with getc() or getchar() to accomodate EOF (-1).

A good running average is avg += (x - avg) / n; It reduces the chance of overflow, is fast, and doesn’t require you to keep track of all values.

Each comment collapses to a single blank character during parsing.

Many system names start with an underscore ( “_” ). Avoid creating new identifiers that start that way.

All functions have extern storage, just like variables defined outside of a function.

Use volatile when it’s possible that the variable’s value will change from outside the normal flow of control. Technically this prevents compiler and processor instruction reordering optimizations around the use of the variable.

The register storage class is for small, fast-changing variables like loop indices (not for bigger things like arrays). And you can’t do &variable for register-declared storage.

Array names are const pointers, so an array name is not a valid l-value.

It’s not possible to take an address of a literal value, like 3.14 or "I am the very model of a modern major general.". So . . .

Because C-strings are either arrays (char s[]) or pointers to memory areas (char *s), it’s illegal to reassign a value to a string variable directly (e.g., s = "new string"; /* won't compile */).

When passing multidimensional arrays to a function, the function’s argument list must give the size of all but the slowest changing dimension.

Function pointers: int (*f)(int, double) is the same as int f(int, double). The parentheses are necessary to ensure the * binds to f and not int. To use the function pointer f either of these is acceptable: (*f)(37, 3.14) or f(37, 3.14). (This is “declaration follows usage.”)

const int *p is a pointer to a constant int.
int const *p is a constant pointer to an int.

“LP64″ scheme means long ints and pointers are 64-bit values.

Some compilers use precompiled headers to speed up compilation. This can make the inclusion order of header files significant. Also, some compilers (like Xcode) use “prefix headers,” which are always included in a project.

Defining NDEBUG turns the assert() macro into a no-op.