All in all, the progress reports look good: I think that the team approach is working. Tell us what you think.
Getting help as you finish up: There are labs on Wednesday, of course. They're a good place to get hands-on help. When you email us about questions please be sure to send all email to both of us: futrelle@ccs.neu.edu and jiangzh@ccs.neu.edu. That will assure that you'll get more and better help and get it more quickly.
Explanations of what each team member did: Each team member should write their own explanation of what they did and all of you should sign the final joint document (as most of you did for your Progress Reports --thanks). Please submit the individual team member reports as separate documents, one for each team member. The discussion and explanation of the code and other team-wide information can be in single merged documents.
The balance between English and code: In a few of your progress reports, you only included source code, usually with comments. But it is important in such assignments, and especially in your final project material, to explain what you did in English, separate from your source code. There is very little code in the world that doesn't have a manual or help pages or man pages or something written in English that explains what it does. Your code should be no different. In addition, you should briefly review the types of problems you ran into during the work and how you solved them, found workarounds, or didn't ever solve them. Most of you turned in Progress Reports that did explain what you've been doing, and that's good.
Comments and other file-identifying information: Some of the hand-ins we received had source listings of files that had absolutely no identifying information -- at the tops of the files there was no information (metadata!) as to what the file name was or who the author was, or the course or date or anything. Please make sure that each file is a "stand-alone" document that identifies itself. Once you have some header text with such information in it, you can just paste it into each file and modify the information appropriately.
Definitions in .cpp files not .h files: Header files are normally reserved for declarations only. Thus, it's fine to declare a function, a constructor in this case, Node(int k, Info i); in a header file (note that it has no body, not even an empty one), but the definition Node::Node(int k, string nf){<code body here>} should be in a .cpp file in your project. That was the purpose of the defines.cpp file in the code I distributed to you. I think most of your realize this and are doing fine.
Java in your future: Since I do virtually all my research and consulting using Java these days, I find it fascinating to think about the similarities and differences between Java and C++. Luckily, for you, there are a lot of similarities between them, so if you do more Java in the future, the bulk of what you're doing now will help. There are even close similarities in syntax in the two languages (and this was intended by the designers of Java). Even more importantly, the process of design, implementation and testing of software is a process that transcends any particular language, a process that can even be applied to writing English! I'm looking forward to teaching Java-based courses in the near future.