Why Strings as Classes?

Benji Smith dlanguage at benjismith.net
Mon Aug 25 18:56:18 PDT 2008


superdan wrote:
> relax. believe me i'm tryin', maybe you could put it a better way and meet me in the middle.

Okay. I'll try :)

Think about a collection API.

The container classes are all written to satisfy a few basic primitive 
operations: you can get an item at a particular index, you can iterate 
in sequence (either forward or in reverse). You can insert items into a 
hashtable or retrieve them by key. And so on.

Someone else comes along and writes a library of algorithms. The 
algorithms can operate on any container that implements the necessary 
operations.

When someone clever comes along and writes a new sorting algorithm, I 
can plug my new container class right into it, and get the algorithm for 
free. Likewise for the guy with the clever new collection class.

We don't bat an eye at the idea of containers & algorithms connecting to 
one another using a reciprocal set of interfaces. In most cases, you get 
a performance **benefit** because you can mix and match the container 
and algorithm implementations that most suit your needs. You can design 
your own performance solution, rather than being stuck a single "low 
level" implementation that might be good for the general case but isn't 
ideal for your problem.

Over in another message BCS said he wants an array index to compile to 3 
ASM ops. Cool I'm all for it.

I don't know a whole lot about the STL, but my understanding is that 
most C++ compilers are smart enough that they can produce the same ASM 
from an iterator moving over a vector as incrementing a pointer over an 
array.

So the default implementation is damn fast.

But if someone else, with special design constraints, needs to implement 
a custom container template, it's no problem. As long as the container 
provides a function for getting iterators to the container elements, it 
can consume any of the STL algorithms too, even if the performance isn't 
as good as the performance for a vector.

There's no good reason the same technique couldn't provide both speed 
and API flexibility for text processing.

--benji



More information about the Digitalmars-d mailing list