All of the topics in the poll should eventually be covered, but one thing at a time. I've had C++ training, so maybe I can offer a more educated response than most.

Start with dumb user input filtering and data integrity. I've noticed that this is a weakness for just about any programmer. ALWAYS BET ON STUPIDITY when it comes to users. You may want to quote that in the ep.

I don't program full time, but for the programs I do write I ALWAYS get feedback about how stable they are. Part of that is good design steps before codeing, and the other part is that I never trust the data. I also have a mild distrust of data that has been previously scrubbed coming back from a database.

Computers are fast enough and have enough RAM that a few extra lines of code here and there for integrity checking won't really be noticed by anyone.

CGI type programming is a worst case scenerio that quickly comes to mind. These are some of the weakest and most hacked programs out there. Data input should always have a fixed input limit inside the program (preventing buffer overflow attacks and general user copying and pasting-in stupidities). If a number is expected and not received, dump it (obviously). If a string is received, remove spaces and other trash off the end and forcibly tack it with a '\0'. In some rare cased I've forcibly used a '\0' at the defined end of a string (myStr[strMAX]='\0';) before doing any scrubbing operations on it just because many of the str() functions look for the NULL and will overrun the end if it isn't found...usually leading to bad behaviour or getting access to other data that shouldn't be given. For string testing, I've also used a lot of the (myStr[i]>='a' && myStr[i]<='z') loop tests. I used the same for capital letters and numbers. For special allowable characters (spaces, periods, commas, semicolons, colons, question, bang, etc...) I think I used a case statement since those usually aren't sequential in the ASCII table. In the past I usually just created a stringTest() function for easy reusability (plug that for a future episode). If I ran into a bad character, I would either clobber it with a generic character (usually an underscore) or do a memmove() statement and essentially erase it.

With CGI programming that made calls to the operating system, I'd pass the command string through another scrub statement to remove the commonly used hack-me codes (like semicolons).

For loop testing, I like to use something like ( while (i>=0) ) statements just out of paranoia in case the 'i' variable got accessed and changed elsewhere to something beyond the testing range (negative for this example; this can happen in sloppy code and buffer overflows). This prevents a loop from running forever. If the loop count is dictated by user input (or even database input), I'll typically scrub it first for both minimum and maximum allowable values. This leads to...

enums, static variables, and #define fixed variables. These are great for setting minimum and maximum limits and giving simple names to numbered indexes. These make programs much more human readable and probably should be mentioned.

In summary, when it comes to data integrity and security, don't be afraid to essentially recode the obvious out of paranoia. There's always going to be a moron 2.01 out there that will try and break the program.

For the rest of the episodes:

* Arrays and sorting. Maybe even linked lists and balanced trees...but maybe those should be after the objects episode. This will also be an introduction to pointers. Mention that pointers can be seriously useful but also quite dangerous if not paying attention. Always set unused and free'd pointers to NULL. Always test pointers for NULL before operating on. Dynamically sizing an array with dynamically sized elements could also be mentioned here. This can save a huge amount of RAM if operating on huge databases and such.

* Functions. Calling and return values. void functions. Using pointers to pass by reference and by value. Passing arrays by reference. Using functions in general to simplify and consolidate code (easier debugging). C++ supports function overloading...but that may be a bit too advanced for a segment.

* Objects and classes. I'm not sure structs are worth the time. Thanks to GNU compilers, everyone has access to C++ now. Classes are superior, generally easier, and less restrictive. A great thing about classes is that when an object gets loaded, it can be done through an abstract set() function that can scrub the data before it gets accepted. get() abstractions are equally important. Make sure the variables getting operated on are marked private and such. Multiple types of get() and set() functions can be used on the same data to present different interfaces to the same things. A report() function could also be created for easy viewing and debugging of the data. From my real world experience, I can't over emphasize data abstraction enough.

* By this time, it would probably be a good idea to tie all these previous segment ideas together and talk about good program design and implementation. Emphasize modular programming and future expandibility. Mention writing commonly used functions generic enough that they can be easily copy+pasted or imported in. A well designed program will essentially write itself when it comes time to code it. A well designed program will be trivial to upgrade and expand when the time comes...and it always does. Probably also mention that even a well designed program may need to be rewritten from the ground up (or at least parts of it) if the program's reqirements change significantly from the original's (don't pull a micro$oft and patch overworked designs forever). A well designed program probably and should be upgraded in modular segments so "too much doesn't change at one time leading to bug tracing problems".

I'm sure there's more, but my brain ran dry. Good luck.