I've recommended Python to new programmers because in my experience one of the biggest barriers to new programmers is getting something interesting working quickly and minimising the amount of technical minutiae they need to understand (at first).
For reasons others have explained, I think Python is great at this.
For this site in particular, being able to recommend a simple but popular library like Pygame is a huge benefit too.
If someone sticks with programming, they will almost certainly learn additional languages later. So one's first language isn't actually important in the long run. I started with BASIC!
But getting them to stick with it is the hard part, and for my Python helps: getting them up and running quickly, writing an interesting program and with lots of help and support available online.
Your class should have a destructor, a copy constructor and assignment operator.
I'd recommend not having both a head and tail pointer to start, it should be simpler to implement a queue as a singly linked list (in reverse, push creates a new "head"). It complicates things to maintain both correctly.
Consider using new/delete for the nodes, at least to start. Complex classes like std::string will break unless you account for how malloc() separates allocation from C++ object life cycle management.
Normally you try to write a regular expression that fully captures the kind of strings you want to allow. Your approach of having a pattern you want to disallow and search for instances of it can also work, but would be a less common approach.
To simplify, I'm going to imagine a case you only want lowercase letters (e.g. [a-z]). You can say that you expect zero or more, or one or more, by using the metacharacters * or +. You can use the metacharacters ^ and $ to say that your requirement is to match against the entire input, not just a partial match in the middle.
So that might yield ^[a-z]*$, which means a string starting with zero or more lowercase characters and then ending.
What you might be asking about is how "b" and "cb" are working in the lambda. This is called "capturing", the city button and "b" variables are captured when the lambda is created, and are available when the lambda is executed later.
That is a particularly complex method, in that there appear to be many non-local variables modified that may be used by other methods. I suspect some of those variables are not used elsewhere, and could be converted into locals, but even then I'm not sure that extracting a method will actually simplify anything here.
Possibly restructuring some of the higher level code, particularly with an eye to reducing the need for so much mutable state here, would enable this approach.
You have to be careful with functions like SDL_GetModState(), this gets the state at the time you call it, which can be different than when the event is consumed. Do you do any other non-event related input handling, e.g. calling SDL_GetKeyboardState()?
A simple solution would be to extract the inner loop, along with the variable resets, into a helper method which has an early return statement. If possible move the declarations of these variables into this method.
However I suspect there might be other ways to solve this issue, but I'd need to see the full code to be sure.
Many of the comments are unnecessary, in that they just restate what the code does. Maybe the book does that to help guide you through the program, and it is fine if you want to keep doing so in the short term to remind you what different parts mean, but remember that this is not how comments are usually used. Comments are best used to give context to the program, maybe an example in your program is why the "hire date" is important but not the "start date".
... I'm glad my gut instinct did not want to do this, but when reading code that consistently used it, I thought I was in the wrong.
Remember this is code style we're talking about, it is not objectively right or wrong.
... but I think books that assist with the object oriented part would be even more ideal before diving into windows programming?
I can't say I've read those exact books but strengthening the fundamentals first sounds like a good idea.
(I can't accept sentences that say: This code does this, don't ask how, but it works).
A good attitude for the most part, but don't let it turn into a "not invented here" syndrome!
enum variables in the book are all upper case, I did not realize that it was standard. I'll adjust that. As for the objects John, Joe and Jill starting with an uppercase is probably bad mannerisms from the actual English language.
Yes. Indeed most of the time you want your program to be agnostic to such details. Giving human friendly names to the data structures in your program is mostly accomplished using some kind of lookup system like a dictionary data structure (e.g. std::map<>) or a database of some kind. Don't worry about this too much for now, but I'd say that if you can, try make names data (even if only a string literal) and not code.
I hope I posted in the right forum, if not you can move this to wherever it belongs.
Please not that the following is based on the most common styles I've seen, it is not universal.
The following is discouraged:
Having multiple statements on one line
Having multiple variable declarations on one line
Abbreviated variable names (use the full name for a variable "year" instead of "y")
Most of your variables start with a lowercase letter (which is standard), but "John", "Joe" and "Jill" appear to be exceptions? Consistency is the most important part of having a code style, the actual details aren't too important (though it is good to stick with common ones unless you have a reason not to). Typically, constants are uppercase, e.g. enum entries would be "DRIVER". Types usually use "CamelCase", e.g. Employee, Date, EmployeeType.
Separate class or function declarations with a blank line. Separate function parameters with a space.
Personally, I prefer if a comment is before the statement it related to, and starts at the same indentation level.
Most people use "get" as a member function prefix to mean that the member function will only fetch data from the object and not modify it.
You repeated code in your main function, can you extract the logic for "John", "Joe" and "Jill" to be less specific, without affecting the program's functionality?
Consider renaming "eDate" to something meaningful, like "dateHired" or "hiredOn".