> We'll make the assumption that there exists a system than can transform any simple program But then > Before you answer, note that including a class from th

> We'll make the assumption that there exists a system than can transform any simple program But then > Before you answer, note that including a class from the STL means that behind the scenes your program actually includes a huge bunch of code. Either your sample hardware translation can handle STL natively or you do not have a simple program. > a dynamic memory allocator, a virtual memory system (or dozens of gigabytes of RAM, just in case), and a very complex Finite State Machine to implement the behavior of all the methods that are called directly and indirectly (so this includes methods from "list", "reverse_iterator", "allocator", etc.) Assuming you are allowing the full powered standard STL library. You could provide a simplified one that avoided a lot of those problems (for instance having a maximum size of 256 and having some different underlying guarentees about time). It seems the only point made is that no program could possibly take an arbitrary program and create an efficient hardware implementation of it. And I don't think anyone thinks that is possible.