Before I returned to Pennsylvania for the holidays, I rather quietly made the initial commit to the SlimBuffer Subversion repository.

SlimBuffer is a very straightforward API for creating and manipulating native-memory buffers from managed code. While there exist ways to do this directly — via unsafe blocks (in some languages) or various methods of the System.Marshal class — those methods are usually inelegant, inefficient, or both. SlimBuffer is written in C++/CLI for maximum efficiency and does what it does in a very clean, expressive manner.

If you’ve used SlimDX‘s DataStream class, you already have a basic idea of what SlimBuffer’s MemoryBuffer class is like. Indeed, DataStream is the conceptual basis for much of MemoryBuffer, and the _problems_ with DataStream provided the impetus to spin off the SlimBuffer project.

The big difference is that MemoryBuffer is not a subclass of System.IO.Stream. Our original decision to make DataStream a stream was a poor one. It forced certain conventions on us that, as development and usage of our API progressed, became restrictive. For example, the lack of distinct read and write positions causes users to have to remember to “rewind” many streams before handing them back to SlimDX. MemoryBuffer is beholden to no such interface restrictions — save for those of IDisposable, but that’s a given since unmanaged resources are involved.

MemoryBuffer also allows for allocator customization, similar to that offered by the standard C++ containers. As of now, there is a default allocator that uses new and delete, as well as a simple delegating allocator.

SlimDX 2.0 will be replacing DataStream with MemoryBuffer, but the class (and some of the interesting tidbits I have planned for it) can be extremely useful on its own, so we’ve created a dedicated project for it. This way users who aren’t using other aspects of SlimDX can still take advantage of what SlimBuffer provides.