I think the problem is the apparent lack of familiarity with STL containers, and the ubiquitous prevalence of .begin(). end() and knowing that ++ against an ite

I think the problem is the apparent lack of familiarity with STL containers, and the ubiquitous prevalence of .begin(). end() and knowing that ++ against an iterator will advance it. I looked at the for loop and it was obvious that it was a container of some sort that offered a ForwardIterator. The replacement code is a struct that uses a pointer to a char array with no constructor or destructor. That is far more dangerous. What the heck is "char * *" meant to be? Who owns the data inside it? How does it get cleaned up? What is its initial value? (clue: absolute garbage). eg. Results x; then read x.entries - KABOOM. This is horrible C-style code. The problem is nothing to do with auto. The problem is no obviously-defined lifetimes of data and throwing pointers around as a solution. EDIT: I heartily recommend the first couple of chapters of Stroustrup's C++ Programming Language Fourth Edition, where suddenly everything makes sense and you never want to see naked new, delete or double pointers ever again. Use references everywhere, and ensure you have sensible constructors and destructors. I have to deal with crappy code like this all day in a brand-new C++ project where my superior pulls confused faces when expressions like RAII, copy-constructor, iterator, const-correctness, references etc. are used. I am pretty cheesed off with it and hate seeing code like this any more, particularly in brand new code (littered with uninitialised variables, double-lists with new items pushed onto them so nobody has a clue who owns items, C-style casts etc. etc. I weep). Life in C++ land is now simple: Use the STL. Don't cast unless you have to. Use references. Use const correctness. Let the compiler do the work for you. Let it check for you. Don't make life hard for yourself.