Note that L. Spiro's code is not exception safe, so if you use exceptions in your code, you may not want to copy it directly.

Man, the collective wisdom of a community like this really is a great resource - I'd hate to be trying to learn C++ pre-internet days. I really appreciate the time you have all taken to respond to my questions - especially on nitty-gritty C++ details like this, where I could easily burn myself and only realize it months later. Thank you.

[quote name='Servant of the Lord' timestamp='1351740412' post='4996060']
Why unsigned char* over char*?

When working with strings, I use [color=#0000ff]char. With data, [color=#0000ff]unsigned char. The reason is for safety while using the >> operator.
With [color=#0000ff]char, it will carry the sign bit, which is rarely desirable when working with raw binary data.[/quote]
What effect would that have? Would >> only shift 7 bits and ignore the sign bit?

Nothing in the new array is constructed yet so the next loop constructs the objects and copies from the old list to the new list via the = copy operator. Again one-by-one.[/quote]
Would it be better to use std::move() and the move constructor (since the compiler I use has access to it)?

[quote name='Servant of the Lord' timestamp='1351740412' post='4996060']
How am I supposed to free the raw memory? Just delete[]?

If you allocate with ::operator new(), you have to deallocate with ::operator delete().
[/quote]
How's that work? ::operator new() is saying "use the 'operator new' in global scope". Do classes have implicit operator new()s defined, and the implicit MyClass::operator new() then calls the class constructor? And the implicitly defined MyClass::operator delete() calls the class destructor?

I get that new() constructs the class, but what scope is 'new' in, if ::operator new() does not construct the class?

[hr]
I think it's coming together in my head. When I finish writing the code tomorrow, I'll post it and would like a few eyes to look over it if possible to correct any misunderstandings I might have.

I said that I find myself needing it, "more out of convenience and code cleanliness than necessity", and I was very careful to phrase it that way.

For convenience, because I have multiple classes needing it, I'm making a container that is very much like a vector.
It's a resizable 2D array... that resizes in all four directions (north, east, south, west).

I could just use a 1D vector, and index into it like ((y * width) + x) like I normally do and have done in the past.
Or I could use std::vector< std::vector<Type> > (which I don't particularly like, preferring 1D vectors treated as 2D to ensure the rows all stay the same lengths).

However, using a regular vector requires me to worry about re-arranging the location of the elements anyway.
Example: 3 x 3 grid
0 1 2
3 4 5
6 7 8

Resized to 5 x 5 grid:
0 1 2 3 4
5 6 7 8 +
+ + + + +
+ + + + +
+ + + + +

The elements are no longer in their correct positions, relative to each other.

I'd prefer it to be resized as:
0 1 2 + +
3 4 5 + +
6 7 8 + +
+ + + + +
+ + + + +

Unless I need to extend the grid on the other sides (which I do need in my code):
+ 0 1 2 +
+ 3 4 5 +
+ 6 7 8 +
+ + + + +
+ + + + +

So I created a container class called Grid, which is "a resizable 2D array container, that resizes without harming the relative location of the elements held by the container, and supports negative indices, like a 2D Cartesian grid." (important characteristics underlined - only the first is covered by std::vector)

Yes, I could use std::vector to solve the same thing, but then I'd have to A) have the classes using the vector fumbling around with keeping elements in-sync, B) always be offsetting their indices to correctly support negative indexing. The Grid class handles it all cleanly and intuitively, so I don't bloat the classes using Grid. The Grid class itself is less than 350 lines of code - including excessive whitespacing and comments - so Grid itself isn't bloated or untidy (I'm a real sucker for clean code ).

So yes, "more out of convenience and code cleanliness than necessity".

I'll post it tomorrow, and you can judge it for yourself - I just want to fix one mistake I'm making somewhere in it where resizing is invalidating the data.

Really, the class only took me a few hours to put together - it's just the manual constructing/destructing parts that is new territory for me. And though I could've just made the class wrap std::vector internally (which would still require the class to be made anyway), it's worth taking the extra time to explore the new territory.

There's two kinds of right shift -- arithmetic and logical. The former fills in the gap created at the top by "sign extending" (basically copying the top bit), and the later fills the gap with 0's.
IIRC, in C++ it's implementation-defined as to which kind of shift will be performed -- someone correct me if I'm wrong, or if C++11 has defined this behaviour!

C++ defines shift on a unsigned integer type to be logical shift, however, the standard leaves room for shifting a signed integer to be different from either a logical or arithmetic shift. It would be standard compliant under C++11 for a shift, either left or right, on a signed integer to be a rotation/circular shift rather than either a logical or arithmetic shift. Actually, under C++11 a left shift on a negative signed integer is undefined behavior rather than implementation defined behavior. (Don't ask me to explain this one. To be pedantic a left shift on a signed integer with some non-negative values is also undefined behavior as well, though there's a proposed change to the standard sitting in the committee to fix that oddity.)