When I was in college, I used to be a tutor for the intro to programming course among other courses. The problem you are describing is not uncommon. Depending on what your specific role is, you may have different approaches you want to take.
First, if this is a widespread problem affecting significant portions of the students in the class, if you have access to do so, I would approach the professor teaching the course with specific feedback about what concepts students are failing to grasp, so that he or she may either incorporate additional review of that material as it comes up again in the term, or improve the curriculum for future terms.
If you teach a discussion section for the course in addition to your lab time, that would be a wonderful time to expound on the things that were confusing in lecture and help make them more concrete and make sure fundamentals were all understood.
If the only time you work with these students is during your time in the tutoring lab, you can still use this time to teach the students either one on one, or a few at a time, the conceptual building blocks they need in order to understand and complete their homework.
They may feel so lost in class they don't even know where to stop and ask questions. If that is the case, go back to the basics with them. Where were they in the course when they last understood what was going on? If they are unsure, or "never" understood, you may have to go all the way back to the beginning to explaining hello world, teaching them things like what a variable is, how the computer takes their list of "instructions" and tries to do them in order, but the computer's not as "smart" as us so you have to be very literal and say things exactly right for the computer to understand, etc.
That's actually a point of struggle and frustration I've seen quite frequently in the non-majors programming courses. Students write some code. It seems "about" right, but then they go to compile it and it gives an error, a very cryptic error. And they have no idea what's wrong with it. And stare at their code for hours. Then finally figure out it was something that seems trivial, like a missing semi-colon, or a brace in the wrong place. Then they go compile it again, and there's still an error, it's something else. They spelled a variable name differently the second time they used it. And so on. So they ask a friend or tutor or someone for help, and they can answer off the top of their head "oh just add this there and then it will work." So their experience is that programming is a bit "mysterious" and extremely frustrating and way more trial and error than it should be.
That is an area as a tutor, where you have a lot of room to help. Depending on their frustration level, I might have different approaches to helping them figure out why their code isn't working. If they're sort of getting it, I might give them hints and try to help them figure out on their own. But if they're just at the end of their rope about ready to give up frustrated, I'll often give them a couple freebie answers, and then try to at least ask them questions like "do you understand why this change fixed your program?"
For some students, especially non-majors, they may not have the methodical attention to detail necessary to be a good programmer or enjoy programming. You can hand-hold them through strategies to help them pay attention to the details, and be methodical enough to solve the problems even if it is a challenge for them.
But anal-retentive about the students indenting their code "properly"--so often, beginning programmers create problems with nesting and scope because they have non-matching braces or the like because they don't pay attention to what's nested under what. Give them a checklist of "things to check when your program won't compile", like indent all the code properly and make sure the braces match, make sure all the lines end in semicolons, especially around the line number where the first error shows up, etc.
Teach them to compile early and compile often. Write the minimum skeleton code (say, hello world), compile/test. Add a few lines, compile again. Its much easier to find errors if you're only looking at a small bucket of changes not a big bucket.
Help them learn how to break down a problem into smaller solvable problems. This is the same thing we do as professional programmers solving much harder problems we don't know how to solve. You keep breaking it down into pieces until you get to something that you either know how to solve or can do some research to learn how to solve. "What steps would you need to take to get to a working solution?" Well, first you'd need some skeleton code (hello world). Do you know how to do that? Yes, great, so when we're done talking you can start by doing that! Then it needs to read a file as input. Did you remember reading about that in chapter 4? Not really? Why don't you go have a look at that after you get hello world running, and see how far close you can get to getting that working and then call me back and I'll help you some more when you get stuck on that. The first few times you may just need to make a numbered list for them of the steps necessary to solve the problem, so that they can learn from example how to decompose the problem.
If they are getting some but not all of the material in class, encourage them to ask questions in class, because nine times out of ten, they aren't the only student not understanding, and the professor probably did just gloss over something important.
If they are spending "hours" staring at one bug but not figuring it out, that's a waste of their time, they're not learning much from it. Often bugs are insight problems, and its a matter of coming up with the right insight to solve it, and they may not have a knack for those types of problems. Suggest other general approaches to take when they get stuck: ask another friend in the class for help (get to know some classmates if necessary to do so), start their homework way ahead of time so they have time to stop, and later come into the tutor lab and ask questions during the open hours, or go to the professor's office hours. If they're used to cramming, which works well for memorization subjects, they will hit a wall of frustration when they're faced with programming which is more about problem solving than memorization. Show them how to look up examples of syntax from their textbook, stackoverflow, etc. Encourage them to post a question on a private class question forum if there is one.
Teach them how to narrow down where the code stops working. Comment stuff out till you get back to something that runs, and then slowly add stuff back in until you get that segfault again.
A lot of these ideas could be turned into handouts if they come up a lot. Strategies is usually the part professors gloss over--they're spending their time on the syntax, the semantics of how to write loops, arrays, i/o, etc. But not enough time spent on "what do I do when I try to run my code and it just doesn't compile or crashes on me?"
When it comes to conceptual things, especially fundamentals, like "what is a variable", or "what is a loop?" not understanding that will prevent them from being able to keep up with the rest of the course. In a lecture-based course, the professor may not have time to answer every question or help that lightbulb go off for every single student. And that's part of why tutors are so important for learning programming. They may need individualized instruction with additional analogies to make a particular topic concrete.
Since you are teaching in C++, I would imagine classes come up as an abstract topic that some students struggle to "get". Often the abstraction of classes is taught with examples corresponding to some random real world object, like an "ATM machine", and analogies are made to the real world object. You might have variables to keep track of how much money is inside, you have methods, which are like rules that tell the atm machine how to respond to particular conditions, etc. Sometimes one analogy is the one that "sticks" for a particular person, and other students grasp a different one better.
Whenever possible, draw pictures for them. Like a sequence diagram of what happens over time to help them see the big picture of what the code they are writing does. User clicks this button. Then the program should respond by doing x, y, and z. Draw an array like a bunch of PO Boxes at the post office that can each hold only one number, and pointers like arrows pointing to the "address" on the front of the box. Etc.