Thread: Questions about C++ and programming in general from a newbie

My English isn't so great, so I beg your patience if/when I mess up.

I'm going to preamble a bit (which makes this a preamble to a preamble...), but that's just there so you have something to work off of should you want to tailor your answer(s).

So, I'm 17 and haven't been programming for very long. I took up Computer Science as a subject at my school last year (The earliest you can take it in our school system), before which I haven't really had any contact with programming. Last year, our teacher (Who doesn't know a whole lot about programming, he confessed) had us do Java. This year, he switched us over to C++.
I want to create a database program for a family friend, but figure I need to ask these questions (especially number 2) before asking more specific things.

Now, the questions:

1) Important Background: In an interview somewhere, I heard the person make an analogy somewhere along the lines of "if you want to produce musical geniuses, you have to start them off at an early age". I believe it was an interview with the person behind the Raspberry Pi and the analogy was to getting kids programming with it from an early age, just like they used to with the BBC microcomputer, etc. Lots of well-known/public figures in the field of programming have stated that they started at an early age (6-9).
Now, the question - and this is going to be really abstract:

Do you think, in your opinion as an accomplished programmer, that someone that does not have that background (like me) is at a fundamental disadvantage? And I don't mean in terms of just a head-start (Which can be caught up to with hard work). I mean that experience of tinkering at such a crucial period of development having such a profound affect on the way you think and perceive things that to not have it would be a clear disadvantage? Basically, I'm asking whether I will always be a "second class" programmer if I'm only starting this "late".


2) Not so important background: As I mentioned before, my teacher doesn't know all that much about programming. He's learning along with us as we go through a book he has. He's let me have a look at the book, and I've now read most of it.
Last year, when we were still doing Java, I had a question about an error I was getting on a side project I was working on. The teacher couldn't help and I was forced to look on the internet. Google'ing it didn't help and I eventually made up my mind to make a forum post about it. Basically everyone there screamed at me for not using the API - something I didn't even know existed. I mean, the teacher didn't know about it and it wasn't in any of his books. I gave up on that idea and eventually we tracked down a developer from a local company willing to help - but that's besides the point. Some time after that I made it a point to try and find out what an API is and how to use it. I've had success on the first, but practically none on the second.

So, my question is: How exactly do you use APIs? I've Google'd it many times, but never found anything that seems to help. Is there some sort of trick to reading/understanding them, or am I for a lack of a better word just dumb? Do I need to stare at it for long periods of time for it to make sense? If this question is a little too vague, I can probably provide an example of the difficulties I've been having.

3) Something code specific! Do function calls eat a lot of processing power? I'm trying to write the most efficient code I possibly can (I've read/heard most professionals say that in most cases doing that on the job is just unrealistic, because of time/budget constraints). My hope is that if I write it efficiently from the get-go, it won't need so many 'revisions' (don't know if that's the right word) to get it to the best it can be.
For example, in terms of execution speed, which is better:

Code:

int aValue = aFunctionCall();

if (aValue == 1) {
// Something happens
}

// Some other code

if (aValue == 1) {
// Something happens again
}

or

Code:

if (aFunctionCall() == 1) {
// Something happens
}

// Some other code

if (aFunctionCall() == 1) {
// Something happens again
}

Also, does the first one use more memory (Because it stores an extra variable)? I realize in these example the differences would be so miniscule as to be almost irrelevant, but I think you get the idea.

If you read everything; thank you for taking the time. And a preemptive thank you to anyone who replies. I'm sorry if this post is somehow inappropriate (insomuch that it doesn't strictly focus on code).

Fizzgig

Edit: Changed the code snippets to better reflect what I was asking.

regarding your code snippets it may well be that the variable aValue is needed to hold lots of different values during its usage period, in which case that snippet is how you would do it, if on the other hand you simply wanted to know if the function call returns true or false then it would not be neccesary to create a variable to hold that return value, so using aValue in that sense is not as 'efficient' for the small differences it may make, declaring an int when not neccesary that is. - yes when you declare an integer or any datatype then it 'costs' a small (or sometimes very large) amount of memory - In the days before masses of RAM memory was available programmers had to very carefully watch their usage of such memory when writing code - it is still good practice to conserve that memory usage in your coding - and also as you use more advanced code you will have to be responsible for tidying up your memory usage as you go along.
Some languages like JAVA have a built in 'garbage collector' to do this for you - whether or not that is effective or proper is another discussion


if the test were just for a true/false return then you can trim it a bit more, note the ' ! ' operator

Code:

//..

if(GoodCall())
{
   //...
}


//or to check for the negative :

if(!GoodCall())
{
  //..
}

//...

Also as far as the age things go yer forget it, your're 17, well over the hill mate, i am surprised you even managed to grasp how to operate a mobile phone given your old brain!

That is to say I do not agree with that at all, the references you may hear to people picking up programming from BBC micros etc were people that were around at the time the whole idea of any kind of computing at all took off - and it was in schools for the first time etc, and those guys some of them work in like GCHQ cyber security centres now tackling IT terrorism and the like, yes, super boffins indeed, but still, then it was more of a niche thing to be interested in and embrace computing and work on it intensively, now there are massive resources freely available to all and the sheer range of media and areaes to get involved in via those channels are just unbeleivable compared to what was around back then.
But to answer in short about actual programming i think you just need to have a creative mind and a good level of intelligence that can solve logic problems and be able to picture things abstractly.
i cant comment if there is any advantage to starting programming very young, other than that would mean you had had x many years more practice than somebody else.

I don't think it is like a pianist that has been able to develop hand flexibility and tendon strength from an early age - though they do say the brain is most receptive when very young, but that is general information-wise - i dont know if that neccesarialy translates to absorbing soemthing specialised like programming more effectively and imbuing some kind of 'talent' for it.

The second snippet will be faster unless the compiler can determine that the two functions' execution paths will be exactly the same, and this is very difficult to analyze.
Nevertheless, I want to give you the advice to stop thinking about trivial optimizations in the beginning. Today's computers are blazing fast, and the bottleneck often is not CPU power. So, unless you can noticeably see (or measure) that your program is slow, then don't both optimizing it.
If you can prove that it is slow (slower than acceptable according to your opinion), then you should use a profiler to determine what parts of the code is slow and then optimize that and only that.

As for age, no, I don't think it's too late. So long as you give it your all, you should have no problems whatsoever, I think.

That's a lot you've written there, so expect many of us to only respond to part of your post. You'll no doubt get the answers you're looking for, just spread out over everyone's replies.

I was close to around 13 or thereabouts when I started, I think. So you're 17 and starting programming. That's still starting earlier than a lot of other competent programmers out there. If you're a smart kid and find it really fun and interesting, then you will go a long way. Continuous improvement is another big plus. Regularly participating in a forum such as this one is one way to boost your skills very significantly. I've seen a lot of people make incredible strides in their knowledge on here.

The problem with your code example is that its damn near impossible to reason about the performance of hypothetical stuff in programming. Everything you can think of, and more, has an impact on the answer, and that's even assuming that the function has no side-effects, otherwise the two code snippets aren't even equivalent.

In general you'll find that you're always told to just write the code in as simple, concise, and clear a manner as possible and the compiler will do its job of sorting out the optimisation side of things. This is good advice with modern compilers.
Early on, you won't know the kinds of things that actually make a big difference in execution time anyway. Let that knowledge come in time. Until then, don't slow yourself down and end up writing awkward code, by being hampered with thoughts on micro-optimistion.

Originally Posted by rags_to_riches

Your English is far better than many native speakers. You have nothing to fear where that is concerned.

But in every other respect I'm screwed, right? Haha, couldn't resist. Thanks SpellCheck helps though.

Originally Posted by iMalc

That's a lot you've written there, so expect many of us to only respond to part of your post. You'll no doubt get the answers you're looking for, just spread out over everyone's replies

I expected as much. I just tried to preempt questions as best I can, but I know I come off long-winded most of the time.

Originally Posted by iMalc

The problem with your code example is that its damn near impossible to reason about the performance of hypothetical stuff in programming.
...
Early on, you won't know the kinds of things that actually make a big difference in execution time anyway.

This makes sense.

Originally Posted by iMalc

...and the compiler will do its job of sorting out the optimisation side of things.

I... didn't know they do that. But surely they have some sort of limit as to how much they can do, right? (Flows into next reply)

Originally Posted by Elysia

I want to give you the advice to stop thinking about trivial optimizations in the beginning. Today's computers are blazing fast, and the bottleneck often is not CPU power.

I understand what you are saying, but am I wrong in thinking that cannot be such a blanket statement? What if I'm writing code for circuitry (Embedded systems I think is the right name for it? Not sure). There the processing power is severely limited.
I just thought learning to program the "right" way from the start would make me a better programmer later on. But I understand now that it's more of a case by case thing and that it involves learning how the underlying systems work - something I should leave for later.
But if what you and iMalc say is correct and software takes care of the optimizations, why do we have things like Big-O notation? Is that just for the people that write the optimization software?

Speaking of Big-O notation, may I just ask someone to help me understand this one thing:
with Sum = Sum + 1; as the basic operation and n being unknown, I can agree that in

Code:

int Sum = 0;
for (int i = 1; i <= n; i++)
  for (int j = 1; j <= n; j++)
   for (int k = 1; k <= n; k++)
    Sum = Sum + 1;

the growth-rate function is O(N^3).
What I can't agree with is that in the following

Code:

int Sum = 0;
for (int i = 1; i <= n; i++)
  for (int j = 1; j <= i; j++)
   for (int k = 1; k <= j; k++)
    Sum = Sum + 1;

the growth-rate is also O(N^3).
I've tested this every which way. On paper, with outputs to the console at every step and it never agrees with this. Most of the time it's pretty close, but never spot on. Is that it? Is it just an approximation in the same sense that you discard constants in Big-O notation? That at higher numbers, the deviations are inconsequential? If so, this book should have really stated so (It did in the other cases). For those wondering what book, the same one we're taught out of at school. Big-O notation is the very first chapter and thus the very first thing I learned in C++ (Even though it's not language specific).

Originally Posted by Elkvis

which API? there are as many ways to use an API as there are APIs to use. without knowing which API they were telling you to use, it will be hard to give you advice.

Well, at that time it was the Java API if I remember correctly. I had a run in with one recently when working with QtCreator, as I wanted to fiddle with C++ GUIs (I understand that C++ doesn't have anything 'built in', in order to be cross-platform as I understand it) So I have a specific example from that, but if almost every API is used differently, I'm wondering whether I should just wait to ask at a later date (I don't know if I'm going to stick to Qt). Actually, you know what, there's no such thing as useless knowledge, but I'm going to tack on another question before I get to the example: At what point is a programmer expected to be able to use an/any API?

Example: I was trying to get QInputDialog::getInt() to work inside my main function (You are supposed to call it via a class dedicated to GUI or something as far as I understand). It just wasn't working and I couldn't understand why, I mean I looked for examples on the Net, copy-pasted them (after modifying to fit of course) and they just wouldn't work and gave me a very nondescript error message.
This is what I had at first:

Code:

int number;

number = QInputDialog::getInt(0, "Calculate Primes", "Enter a number between 1 and 500:",1, 1, 500,1, 0, 0);

And this is what fixed it:

Code:

int number;

number = QInputDialog::getInt(0, ("Calculate Primes"), "Enter a number between 1 and 500:",1, 1, 500,1, 0, 0);

Can you perhaps show me what in this API (Qt 4.7: QInputDialog Class Reference) explains to me to use those parentheses? In fact, why did I have to use them?

Originally Posted by rogster001

...though they do say the brain is most receptive when very young...

That's what I was talking about.

Originally Posted by rogster001

but that is general information-wise - i dont know if that neccesarialy translates to absorbing soemthing specialised like programming more effectively and imbuing some kind of 'talent' for it.

Originally Posted by Elkvis

programming is really just a form of engineering and problem solving. if you've been developing your engineering and problem solving skills all your life, the people who have been programming for their whole lives aren't really that far ahead of you.

Originally Posted by Elysia

So long as you give it your all, you should have no problems whatsoever, I think.

It's good to hear your opinions on this, thanks.

Originally Posted by iMalc

Regularly participating in a forum such as this one is one way to boost your skills very significantly.

Wouldn't folks get very irate if I posted a question every other day, though? (After of course researching the problem to the best of my abilities beforehand and trying to figure it out myself)

Edit: Bah! I only now notice the Multi-Quote button on the bottom.... I hand-typed all those quotes =/ Oh well, another reminder to be observant.
Also fixed double negative.

The compiler is very good at its job, but nothing can cure idiocy, so to speak. The compilerndoes not know what younare intending to do - it cannot see te bigger picture. It only sees instructions and tries to optimize those. But there are always dumb ways you can do things, and the compiler cannot fix all those things because it would have to be infinitely smart and infinitely complex (imagine a compiler identifying every known algorithm and good solutions for them).
That is why we have Big Oh. To optimize what the compiler cannot. To fix dumb solutions.
The Big Oh notation is always an approximation. It used as a guideline for knowing how fast or slow an algorithm or a piece of code is. Nothing more.

Do not worry about asking lots of questions. If anything, it gives a lot of people something to do everyday, and to some, there is nothing better than answering easy questions. Ask, read, solve and reply. That is part of the way to knowledge. You will learn immensely.

I don't want to say too much but I must disagree with Elysia on Big Oh being an optimizing tool. I like to profile when my program has huge hang time. That is discounting the times when I debug and find some ultimate cause, which happens frequently anyway. Design flaws are just that. And making decisions is half the battle. I've got loop unrolling and table driven development in my "optimize this" toolbox because I've used those techniques before. And optimization is something that you learn and if I'm honest about it, I can say I'm something of an optimization moron. I don't know a lot about how long it takes to perform certain CPU instructions down to specific architectures. I don't like to do optimization because of this stuff and yet I can't always fix things with yet another algorithm. If you want to be good at it, be smarter than me and Elysia, too.

Originally Posted by Fizzgig

I... didn't know they do that. But surely they have some sort of limit as to how much they can do, right? (Flows into next reply)

I understand what you are saying, but am I wrong in thinking that cannot be such a blanket statement? What if I'm writing code for circuitry (Embedded systems I think is the right name for it? Not sure). There the processing power is severely limited.
I just thought learning to program the "right" way from the start would make me a better programmer later on. But I understand now that it's more of a case by case thing and that it involves learning how the underlying systems work - something I should leave for later.
But if what you and iMalc say is correct and software takes care of the optimizations, why do we have things like Big-O notation? Is that just for the people that write the optimization software?

You're a clever and inqusitive person. This is a good thing, and it is a good sign that you will make an excellent programmer. Yes compiler optimisation very much has its limits. It has come a long way over the years, yet at the same time has plenty of room for further improvement.
Big-Oh notation stuff is important because it is basically somewhat where one draws the line between what a compiler can optimise and what it cant. I.e. it is almost certain to turn a multiplication by 8 into a shift by 3, but it wont turn a bubblesort into a quicksort. Changes in big-Oh notation are where optimisation is quite firmly in the realms of the programmer's responsibility.

Wouldn't folks get very irate if I posted a question every other day, though? (After of course researching the problem to the best of my abilities beforehand and trying to figure it out myself)

Edit: Bah! I only now notice the Multi-Quote button on the bottom.... I hand-typed all those quotes =/ Oh well, another reminder to be observant.
Also fixed double negative.

We don't mind lots of questions from someone who asks intelligent questions. In fact by all means, keep them coming. It's a break from those who just dump their easy assignments after having made no effort and ask others to do it for them, etc.

Yeah I need to use that multi-quote button more often too.

To come back to the original questions asked ....

Originally Posted by Fizzgig

Do you think, in your opinion as an accomplished programmer, that someone that does not have that background (like me) is at a fundamental disadvantage? And I don't mean in terms of just a head-start (Which can be caught up to with hard work). I mean that experience of tinkering at such a crucial period of development having such a profound affect on the way you think and perceive things that to not have it would be a clear disadvantage? Basically, I'm asking whether I will always be a "second class" programmer if I'm only starting this "late".

No.

Someone who is inclined to be a good programmer will become a good programmer, whether s/he starts at age 5 or at 105. Learning and tinkering does not somehow get harder as one gets older. Other life distractions may crop up, but that can happen at any age.

Originally Posted by Fizzgig

So, my question is: How exactly do you use APIs? I've Google'd it many times, but never found anything that seems to help. Is there some sort of trick to reading/understanding them, or am I for a lack of a better word just dumb? Do I need to stare at it for long periods of time for it to make sense? If this question is a little too vague, I can probably provide an example of the difficulties I've been having.

To use an API, you need to find documentation for that API. Reading such documentation can be easier or harder though, depending on mindset. An API is just a specification of how the users of a library invoke functionality from that library. If you wish to use a particular API, or a function in an API, it does help to have a reference handy while designing your code. Rather than trying to do it from memory.

Originally Posted by Fizzgig

3) Something code specific! Do function calls eat a lot of processing power? I'm trying to write the most efficient code I possibly can (I've read/heard most professionals say that in most cases doing that on the job is just unrealistic, because of time/budget constraints). My hope is that if I write it efficiently from the get-go, it won't need so many 'revisions' (don't know if that's the right word) to get it to the best it can be.

I wouldn't worry about such things. Efficiency of any given code construct varies between compilers, with compiler settings, between computers. And there are many other factors.

It is better to get the code working correctly (i.e. producing the results needed) without worrying about performance or memory usage (or other such things) too much. Then, if you have particular identified performance requirements, do measurements to see if they are met. If they are not, use tools like profilers and debuggers to find the "hot spots" - the sections of code that contribute to not meeting the performance requirements. Then focus attention on those areas of code with an eye to optimising.

Generally speaking, worrying about performance up-front is called premature optimisation. Optimising without a particular idea of what you are trying to achieve is an effective way to waste time. A program that works and is delivered to a customer on time is vastly superior to a program that works 5% faster but is delivered late because the programmer has wasted time lovingly tuning the performance without any particular need.

As to your two code examples, assuming that aFunctionCall() does something quite quickly and returns the same result on consecutive calls, there is probably not much advantage in either of the approaches you suggest. If aFunctionCall() does some time-consuming actions (eg a long running calculation) then the first approach is often better.

The first approach is arguably easier to read, which is good for the programmer (and often good in other ways, since the cost of the programming exceeds most other costs in most software projects). So, assuming that aFunctionCall() returns the same result on consecutive calls, I would call it once and save the result away, more often than not. But memory usage or program efficiency is low on my list of priorities, more often than not.

It is a rare function that does not introduce more overhead than a single integer so the memory usage difference will often be irrelevant. There is a cross-over point if the function returns a large amount of data (say, a large data structure) but, if you are running in a setting where such things matter, you will know exactly what you are doing. Again, there is no general answer except "it depends" so - except in specialised circumstances - it is rarely worth worrying about.

Originally Posted by Fizzgig

Are header files necessary? As someone from a Java 'background' (The whole one year of it =P), header files feel unnatural to me. The book I'm working from states I don't need them. I've looked online and on basically every forum where this comes up it ends up into some kind of fight/argument. Someone, I can't remember who and on what forum, stated that it's still useful in the sense that it helps with program maintainability. What are your thoughts on the usefulness/viability of headers?

Header files are unnecessary in the sense that no matter how large and complex your C++ program, you can always write it such that no headers are included, and yet have it compile perfectly fine. But as you have apparently heard, they are indeed useful, because there are bound to be function declarations, class definitions, etc, that need to be available in different source files, and it would be so much easier to just include the appropriate header instead of repeating the code.

Originally Posted by Fizzgig

Another question I keep forgetting to ask: Are header files necessary? As someone from a Java 'background' (The whole one year of it =P), header files feel unnatural to me. The book I'm working from states I don't need them. I've looked online and on basically every forum where this comes up it ends up into some kind of fight/argument. Someone, I can't remember who and on what forum, stated that it's still useful in the sense that it helps with program maintainability. What are your thoughts on the usefulness/viability of headers?

Are they required to use the language correctly and compile some code? No.

So are they a requirement, then? I would say, it depends.
If you just have one small file with code, then it probably isn't worth it.
If you have several files, then I would yes, absolutely, they should be a requirement. But they are only a user-imposed requirement. The compiler does not care.
But asking this question implies that you do not fully understand what purpose they fill and why they are useful. So, as an advice, you should learn about declarations and why they are necessary. Then, all you need to know is that, duplicating declarations is bad and a waste of time™. Thus, headers begin to shine.

Also, is there a way to do something similar to other forums' "Spoiler" functionality on this forum? I think it would probably help immensely with someone like me that just talks without end. =P

None that I know of.

Regularly participating in a forum such as this one is one way to boost your skills very significantly. I've seen a lot of people make incredible strides in their knowledge on here.

Is very true, as a self taught programmer i have gained a lot from being a member of this board, I am no way an super advanced programmer, but the help and knowledge to be gained from regular visits and participation here has been invaluable - And certainly things like indentation - getting berated for not doing that right, and other best practice stuff, quality of work stuff is really ingrained in me thanks to the members here. i now work for a software house producing financial applications - i am not a key programmer there at all, but i have to say i was really amazed at the sheer 'sloppiness' of the practice i have seen employed by really high paid coders - I expected everything to be like cBoard perfection - but seems the real world is not like that! It has to be said that deadlines etc contribute to rushed stuff, tho the business does very well - 'money for old rope' mate.

I'm guessing being intimidated with walls of technical text isn't quite the mindset you have in mind. I firmly believe this will change with familiarity though.

Yes - in the same way as your fluency with english has - And also as someone that has learnt foreign languages too, then you find that you have an 'angle' on leaning new ones - by the experience of learning the previous ones - the paradigms and 'syntax', it is no different in programming - when you learn a new language you want to know stuff like : how do i declare and define a datatype? how do i declare and call functions? how do i pass values to functions? how how do i store multiple values in container dataypes? what is the scope of the data that i use? how do i create looping constructs? And the experience you will have gained will let you employ those things in the new language much faster, beacuse you can anticipate what the outcome is when using these things. - they are common goals in programming the same as needing to know how to use verbs and tenses in foreign languages.

And extending this to the idea of using an API - then you will just have the documentation handy and be able to read it fluently (if its written well !!) - you will link up your libraries for the compiler
and away you go. So it won't appear 'technical' as such, its just your working reference, so if it is a graphics API, you might want to look up line drawing, and find out how to call the function, what arguments it requires, what are its return values for error checking? etc etc.

I would have liked to keep putting my questions here (as in this thread), as that would keep me from basically spamming the forums. Also, by keeping everything in one place, people would know what they were letting themselves in for when entering this thread; battle with gigantic walls of text =P

I think it is better to post your program specific questions in a new thread, that way others may benefit from the answers by way of search topics etc.

P.S. The fact that there are no headers in java is a source of much rage for me!!!!! I have to say i dont like the big jv much mate. Its just a shame C++ cant match it in some areas - natively i mean - but then depending on a big lump of runtime being available on the target platform is not exactly cool either.