Help! C++ Struggles: My First Programming Class

[andryd9]

I am taking C++ this semester, and am not really good at it. It is my first programming class, and I kind of stink, though I am trying. I don't think I'm going to get a great grade, and it will bring down my average. I was thinking of dropping it, but then had a look at the class averages...most are MUCH lower than mine, and I'm a little startled. Is C++ just a hard language to learn, or am I in a class of total slackers? If the former, maybe I should hold on to my not-so-great grade and be happy it's not worse. But if the latter, I might be better off trying again later. Any advice appreciated from those who have experience with C++. TIA.

 

[jtbell]

I don't think it's C++ per se that's difficult, it's computer programming in general. I taught introductory programming courses for many years, first Fortran, then Pascal and finally C++. A few students always "got" programming quickly, but most of the rest struggled to get used to it, at least at first. Some people need more practice than others, regardless of the language.

Also, programming requires two very different skills. First, the ability to take a "real-world" problem statement and convert it into a step-by-step algorithm for solving it. Second, the "nuts and bolts" of coding: getting the syntax right, using your programming tools (IDE or command line), and debugging. These two things are often done by different people in a programming shop, because people are often better at one than the other.

 

[andryd9]

Thanks for your input. I immediately noticed from your description that my issue is with the "nuts and bolts" part...it is amazing to me to be so undermined by minor details. If it is an adjustment for most, I will try to hang in there and do better:)

 

[chiro]

Hey andryd9.

In addition to jtbells advice, I would say that once you know the programming mindset, learning the specifics is not much of a quantum leap.

In programming there are two main things that you need to keep in your mind and those are state and flow-control. State is the state of the machine and flow-control is the flow of execution (i.e. how instructions get executed).

Basically in programming you use time, a lot of fumbling around, and experience to build these up in a gradual fashion. At first you only look at a few variables, then you look at entire classes then modules, then entire libraries and finally entire repositories with many external libraries, and particular parts that make up the whole and inter-connect together.

With flow-control it's the same deal. You start with simple programs then you introduce branching, functions, recursion, and then use language specific features to affect control like constructors and other similar things (which are a part of C++).

You then start to look at multi-threaded and parallel environments and look at the issues regarding this, as well as operating systems and specific platforms, as well as message passing and event systems (or callbacks) and other kinds of flow-control.

These two things are then related to the language, the platform, the data and how its described and the meta-data that helps aid all this functionality with regard to the language, application, run-time environment and so on.

Every single program has its own way of doing things and each one is designed for a particular reason: it doesn't matter if its a C++ program or a PHP script, they all require you to understand the state and flow-control and when you recognize these then the whole thing makes sense and you know what is going on.

 

[scout6686]

Hey andryd9.

In addition to jtbells advice, I would say that once you know the programming mindset, learning the specifics is not much of a quantum leap.

In programming there are two main things that you need to keep in your mind and those are state and flow-control. State is the state of the machine and flow-control is the flow of execution (i.e. how instructions get executed).

Basically in programming you use time, a lot of fumbling around, and experience to build these up in a gradual fashion. At first you only look at a few variables, then you look at entire classes then modules, then entire libraries and finally entire repositories with many external libraries, and particular parts that make up the whole and inter-connect together.

With flow-control it's the same deal. You start with simple programs then you introduce branching, functions, recursion, and then use language specific features to affect control like constructors and other similar things (which are a part of C++).

You then start to look at multi-threaded and parallel environments and look at the issues regarding this, as well as operating systems and specific platforms, as well as message passing and event systems (or callbacks) and other kinds of flow-control.

These two things are then related to the language, the platform, the data and how its described and the meta-data that helps aid all this functionality with regard to the language, application, run-time environment and so on.

Every single program has its own way of doing things and each one is designed for a particular reason: it doesn't matter if its a C++ program or a PHP script, they all require you to understand the state and flow-control and when you recognize these then the whole thing makes sense and you know what is going on.

Thanks for that advice I'm in similar situation and I REALLY appreciate your wisdom! Figured I'd speak-up instead of lurking lol...

 

[Rooted]

I'm in a similar situation too, and trying to get my head around the language. A book I have found useful is 'Thinking in C++' by Bruce Eckel. There is a free electronic version of this online.

Good luck, and persevere!

 

[chiro]

I'm in a similar situation too, and trying to get my head around the language. A book I have found useful is 'Thinking in C++' by Bruce Eckel. There is a free electronic version of this online.

Good luck, and persevere!

That is a good book and I recommend it (I read that many years ago) but a lot of the learning in C++ will come through the pain known as debugging (fixing bugs) and this will educate you about the state and flow control.

But after a while you will see the code in your head and you will see things that you didn't see before just like with anything and when you get to that stage, you will (if you choose to) start to master it by dealing with things with greater complexity and scope.

 

[Borek]

my issue is with the "nuts and bolts" part...

C++ is - at least IMHO - not the best language to start with, just because of the syntax. Still, if that's what you are struggling with, and not the algorithmic part, you are in a better situation than the others.

 

[andryd9]

Thanks, Chiro and Borek, for the input. And I think the reason that I am struggling with the syntax and not the algorithmic part as such is because of the class format...at home on my own I can perfect the syntax, but often encounter problems that I struggle to frame correctly so that the language can help to solve them. In class, however, our tests consist of written programs. The algorithms are very simple, and I can almost hear the instructor thinking "There, this is so easy any fool could figure it out!" in his head. But they are all long and often require many detailed steps, increasing the possibility of a small error. If your program does not compile or you don't submit by the time deadline, you are sunk. Really sunk- it doesn't matter how much you've done well, you get nothing.(I have been working on debugging, as it seems to me that doing this quickly is vital.)

 

[Astronuc]

Learning C++ is a necessary evil.

I learned Fortran (the older F77 version). To learn C++ now is somewhat like learning Roman after having grown in speaking Greek. The languages accomplish the same, but they are different in many ways, although there is similarity in structure and function.

I'd simply reiterate what jtbell, borek and others have mentioned.

Part of scientific programming/computation (numerical analysis) is being able to translate the mathematics into an algorithm that works in numerical analysis. This is not trivial.

The other part is learning the computer language with one uses to write the algorithm(s) and solve the problem. Along with that is the input and output of data, which itself is critical. If one puts garbage in, the one's program is simply a fancy (and potentially expensive) garbage processor.

Much of scientific programming comes with a legacy of FORTRAN. C++ is more recent, and there is a tendency to write new scientific programming in C++, particularly for systems employing object oriented programming (OOP).

I'm in a situation where I have to use both FORTRAN and C++.

 

[AlephZero]

If your program does not compile or you don't submit by the time deadline, you are sunk. Really sunk- it doesn't matter how much you've done well, you get nothing.

That seems a bit harsh if you literally mean you get zero marks. Everybody makes the occasional typo or spelling mistkae. But some "fails to compile" errors are really "fails to understand the semantics of the programming language" errors, and those can be a good indicator of how proficient you are.

But as Borek said, in C++ some of those issues are made worse by the cryptic syntax - for example "a function that returns a pointer to something" and "a pointer to a function that returns something" are very different concepts, but the only difference in the C++ code is a pair of ()'s.

(I have been working on debugging, as it seems to me that doing this quickly is vital.)

Actually, the quickest way to debug programs is to write them without bugs in the first place - in other words make sure the algorithm works, BEFORE you start writing the code. For example if you find you need lots of logic to handle "special cases", that is often a sign that the basic structure of your program is wrong, and you should be testing for things in a different order. But once you have the program "90% working", it's very tempting to keep adding more bits of code to "make it work", rather than throwing it away and starting again.

 

[Astronuc]

Some text editors actually use colour to help with syntax, e.g., matching (,) or {,} in C/C++.

I think TextPad is one such editor. It's very helpful.

 

[Dembadon]

That seems a bit harsh if you literally mean you get zero marks. Everybody makes the occasional typo or spelling mistkae. But some "fails to compile" errors are really "fails to understand the semantics of the programming language" errors, and those can be a good indicator of how proficient you are.

...

In my programming course, zero points are given for programs that don't compile. This is common in the engineering department, since commenting out the lines of code that don't work only takes a few seconds. Then the grader doesn't have to waste their time figuring out what they need to do to be able to run what does work in your program.

OP: The sooner you start to code, the longer the project will take. I usually spend a lot of time with pencil and paper writing out memory management issues, logical structures of my algorithms, etc. Don't rely on the compiler as a crutch to find the errors in your program. Do your best to anticipate problem areas and address them before you start actually writing the code.

 

[D H]

To learn C++ now is somewhat like learning Roman after having grown in speaking Greek.

Better: To learn C++ now is somewhat like learning Castilian Spanish, French, and Basque after having grown in speaking Latin American Spanish. Some parts of the language look very similar to C. However, even in this seemingly familiar part, the idioms oftentimes differ a bit between C and C++, sometimes differ by quite a bit. If you just stick to this part of C++ you aren't really programming in C++. That language is more or less C, or C±.

To take better advantage of C++ you need to move to object oriented programming. This is the French part of C++. Because the C++ flavor of object oriented programming is still written in terms of a procedural point of view, that object oriented stuff still looks a bit familiar. It is a different language, though, requiring a very different mindset compared to programming in C.

To take full advantage of C++ you need to use the template programming capabilities that are part of the language. This is the Basque part of the language. Even though the Basque region is sandwiched between France and Spain, the Basque language has nothing in common with either French or Spanish. That's C++ templates to a T.

 

[uperkurk]

Im in my secon year of my computer science degree and I hadn't done programming before but I read up on the concept of it before going to uni. I started with Python and basically all programming languages are the same.

The hardest part is learning the syntax, you want to make a program that counts to 10 then stops at 10. Sure it's very simply just use a loop, but almost every language uses different syntax so at times I know EXACTLY what it is I want to do but it takes me a google search to find out the correct syntax.

Unfortunately compilers are not smart enough to take a guess as to what it is you're trying to accomplish.

 

[D H]

basically all programming languages are the same.

You won't say that after you have learned Haskell, Lisp, or Prolog.