did you know, that checking for equality with myList -> engine lets you verify the start of the list? Don't waste a call on getpos() and compare against 0. That shows me you're still overthinking in brute-force and micro-management mode. We won't always have getpos()/setpos(), so don't use them as a crutch!

This is also a general plea to understand what you are doing. I see far too much “overhelping” going on, where the solutions are near identical, save for some pointless change (like declaring a useless variable to try and make it seem different). I KNOW who is collaborating, I KNOW who knows what is going on and who doesn't. Your work needs to be your own, you NEED to understand what it is you are doing. Comments are one way of demonstrating to me that you do. Leaving them out is a cop-out and an intentional attempt at misleading me.

avoid using -> to -> to in your logic… you are limiting your code's flexibility. You should not need to delve any deeper than a single “to” pointer, and your conditions should generally try to avoid excessive comparisons of the “to” pointer to NULL (not that there aren't valid cases, but generally I see a lot more less optimal approaches, hence why I am pointing it out).

9/21 (~42%) had C/C++ with Hans

8/21 (~38%) had C/C++ with me

4/21 (~19%) had C/C++ with Joe

14 were in C (compilable with gcc), that's 93% of submissions

1 was in C++ (needed to be compiled using g++)

the reason I point this out? I've been saying the bulk of your C++ experience has really just been as a “lazy C”. As 93% of submissions goes (with 42% of the class having had Hans and “ONLY” C++), it seems there was relatively little trouble adjusting. Are there differences? Sure. But not “entirely different language” differences.

16% had Hans

33% had me

lack of programming experience (ie not touching programming since your last programming project was due, which meant not touching programming at all over the summer)

lack of playing and experimenting. Programming is about expressing your ideas, but the less you work on means of expression, the less fluent you are, meaning the more rigid and limited you are in creating solutions (especially ones that are not largely prescribed that you are doing little more than memorizing and regurgitating). You MUST (and regularly) play and experiment. Write small programs that test something so you are more familiar with how the language will react. Not as familiar with do-while loops? Take an existing program and convert it to using them, etc.

lack of proper time management discipline. I suspect some waited until the last minute to really start (thinking “why not? This is how I completed ALL my other projects in the previous class”), and have realized that we're no longer doing the basics, we're now adding content on a layer above (requiring a solid foundation in) the basics. Some took advantage of the time they had, and prospered (and will reap the benefits). Others, I hope it serves as an opportunity to start on improvements to your approach to class work.

again, this was a review of old/intro to new type of project, and far too many were experiencing far more significant issues in its implementation. Makes me worry a little bit about what's to come.

for those who were demonstrating on-going and acute unfamiliarity/clumsiness with various programming tasks, were lagging, were into the late window for ael0 and then somehow, magically, submit a fully-working project. That's not viable. Not impossible, but just remember the part about doing your own work, and not relying on others who may just think they're helping (because they're not, your challenges remain, only the wall is taller now with the next project). Struggling and submitting an imperfect/incomplete project late? That makes a lot more sense. It is reasonable, and it demonstrates honesty (both personally and academically). This obsession with exactness is a habit many simply have to break. Getting 100% at all costs (including not truly by your own brain and hands) will not yield success in the long term. I'm not saying I'm going to drop the hammer on anyone this time around… let's just say it'll establish some data points allowing me to watch certain individuals even closer (and if one is struggling, who wants to be scrutinized even more closely to ensure they are doing their own work?). See how a perceived “good” short term decision can actually be far less good in the long term?

for those who weren't asking me questions, perhaps trying to escape my discovery of any confusion you were experiencing… that also shows in results. Late, quiet, but perfect? Again… data points and longer-term trends. Not saying a capable person couldn't have just suffered from a bout of undisciplined procrastination… but again, give me time and data points, and I'll be able to ascertain that and distinguish those people as well.

why? MEMORY ADDRESSING

on other systems, notably 16-bit and 32-bit systems (especially late-era hardware that might have incorporated tweaks to support more memory than is typically accessible by the default machine word size), memory address sizes can vary.

takeaway: for code portability, do not assume 8 byte memory addresses. ALWAYS use sizeof() to maximize portability.