Accelerated C++ book - no solutions for exercises, should I still solve them?

[KCL]

As the title says, there are no answers for the book I'm learning C++ from, should I ignore the exercise section (well except the first exercise which is always compile and execute chapter examples) and move on or give them a try? I can get my hands on many exercises with solutions, but I'd like to know which way is best. Thanks. :)

 

[CompuChip]

I suggest you do the exercises. Theory is not everything in programming: actually writing code will also learn you about common mistakes and learn to avoid them, teach you how to interpret and solve compiler warnings and many other advantages.

If you are not sure about some code, you can post it on the internet (there are many well-known programming forums) and ask the experts, but I suggest not skipping them.

 

[CFDFEAGURU]

You want to learn programming, you better get used to doing it wrong at least twice. Thats how you learn how to program. In real life there are no answers in the back of the book. Give em all a try. Ask me for help if you need it. I program all day long.

 

[mjaw]

You want to learn programming, you better get used to doing it wrong at least twice. Thats how you learn how to program. In real life there are no answers in the back of the book. Give em all a try. Ask me for help if you need it. I program all day long.

@CFDFEAGURU:
Thanks. This is regarding C++ functions with parameters that are References.
Could you please let me know in the following code why I can call the function myFunc(), in the same way, even if I define the parameter differently: (int i2) and (int& i2)

eg:

#include <iostream>

int myFunc(int i2){
std::count << i2;
return 0;
}

int main(){
int i = 1;
myFunc(i); //Valid even if myFunc has (int& i2) above
return 0;
}

 

[CFDFEAGURU]

The myFunc(int i2) is a pass by value method. The myFunc(int &i2) is passing the argument by reference using the address (&) of i2.

Also, in order to not have to use a lot of standard functions, in this manner std:: put this line of code above your main() function.

using namespace std;

That will allow you to simply write

count << " ... " << endl;

You won't have to use the std:: at all.

Thanks
Matt

 

[mjaw]

The myFunc(int i2) is a pass by value method. The myFunc(int &i2) is passing the argument by reference using the address (&) of i2.

Also, in order to not have to use a lot of standard functions, in this manner std:: put this line of code above your main() function.

using namespace std;

That will allow you to simply write

count << " ... " << endl;

You won't have to use the std:: at all.

Thanks
Matt

Thanks for the response. However my question still remains: Why is it that I can call the function myFunc(), in the same way, even if I define the parameter differently?

I am aware of the concepts of pass-by-value and pass-by-reference. In my example I am using reference to an object, but my confusion is about the call.

Different parameter definitions but same call succeeds. Why?

 

[CFDFEAGURU]

The C++ lanquage allows for different options when making calls to functions. Based upon what your function does and how it is incorporated into your program, you may want to pass arguments to it through different methods.

Maybe I don't understand your confusion on this issue but C++ (and other languages)allow for numerous methods to achieve the same goal.

Thanks
Matt

 

[CompuChip]

Apparently you indeed don't understand mjaw's confusion :)
I think that he is asking for how C++ handles pass-by-value and pass-by-reference internally.

For example, when you declare the function to use a pointer, you tell the compiler that the function expects a pointer to an int. Then when you call the function, you have to explicitly obtain your variables address (&variable) and pass that to the function - then in the function you dereference the pointer.

However, when passing by value or by reference, there is no such explicit construction. So what happens in these cases? For example, here is one possible explanation (which is probably nonsense, but hopefully will make you understand the question):

The compiler internally rewrites all functions to take pointers as arguments, so myFunc(int x) and myFunc(int& x) are both rewritten to compiler_myFunc(int* x). When you call a function which passes-by-value, it creates a new variable (using the copy constructor) and passes its address to the function, i.e. it calls compiler_myFunc(new int(x)). When the function terminates, it cleans this temporary variable up again. When passing by reference, the compiler calls the function with the address of the original variable -- compiler_myFunc(&x) -- without making local copies.

Is it more clear now? :)

 

[CFDFEAGURU]

Yes, I understand what was happening, just couldn't get the answer to the person correctly.

Thanks for your help CompuChip.

Matt

 

[D H]

Thanks for the response. However my question still remains: Why is it that I can call the function myFunc(), in the same way, even if I define the parameter differently?

C++ does not have a "take the reference of" operator. The same thing arises here:
int & iref = i;

Just one of the many goofy things about the language. When you see myFunc(i) in someone else's code you have to look at the declaration of MyFunc to see whether what this is a call by value or a call by reference. This has led many organizations to make programming rules regarding call by reference. Some (e.g., google) only allow constant references (MyFunc(const int &) is allowed but MyFunc(int &) is illegal). Others disallow call by reference for primitive types. Some just out-and-out disallow call by reference, period.

 

[CFDFEAGURU]

This has led many organizations to make programming rules regarding call by reference. Some (e.g., google) only allow constant references (MyFunc(const int &) is allowed but MyFunc(int &) is illegal). Others disallow call by reference for primitive types. Some just out-and-out disallow call by reference, period.

Yes, const correctness as the Numerical Recipes authors call it. I didn't know that is was an enforced rule at Google.

Thanks
Matt

 

[mjaw]

Apparently you indeed don't understand mjaw's confusion :)
I think that he is asking for how C++ handles pass-by-value and pass-by-reference internally.

The compiler internally rewrites all functions to take pointers as arguments, so myFunc(int x) and myFunc(int& x) are both rewritten to compiler_myFunc(int* x). When you call a function which passes-by-value, it creates a new variable (using the copy constructor) and passes its address to the function, i.e. it calls compiler_myFunc(new int(x)). When the function terminates, it cleans this temporary variable up again. When passing by reference, the compiler calls the function with the address of the original variable -- compiler_myFunc(&x) -- without making local copies.

Is it more clear now? :)

Thank you CompuChip. You make perfect sense.
It is under-the-hood stuff and I will now look it up myself based on what you have written. It is actually a big thing for me, I will use your track to resolve other confusions too.

Aside to CFDFEAGURU: using namespace std is very basic and I know it. But such a global using statement is not recommended. Authors of the book discussed in this thread also recommend against it and with very strong reasons.

Thanks.

 

[CompuChip]

Good luck searching. Please bear in mind that a) it has been a long time since I programmed C++ and b) I know next to nothing about the inner workings of it. So please don't attach too much value to the "explanation" I just cooked up :)

 

[mjaw]

...When you see myFunc in someone else's code you have to look at the declaration of MyFunc to see whether what this is a call by value or a call by reference...

Thank you.
You reveal something completely new to me. I will keep this thing in mind henceforth.

 

[CFDFEAGURU]

Aside to CFDFEAGURU: using namespace std is very basic and I know it. But such a global using statement is not recommended. Authors of the book discussed in this thread also recommend against it and with very strong reasons.

I highly disagree with your books authors. It is also very inefficient to have to specify std:: before each of the standard functions. Hence the entire purpose of statement

using namespace std;

My programs are at minimum a few hundred lines long and usually end up being thousands and if I have to use the std:: operator every time I needed a standard count or cin statement or any of the others that are support by using namespace std, I would be very aggravated.

Who wrote this book?

Thanks
Matt

 

[mjaw]

I highly disagree with your books authors.

I do not want to continue this discusion with you.

 

[CFDFEAGURU]

Sorry, I mean no offense, I just don't agree with the authors. I was taught to use that statement and I use it. It is used routinely in many publications. Such as, Numerical Recipes, one of the most informative books there is on using C++ for numerical computations.

Anyways, have a good day.

Thanks
Matt

 

[D H]

I highly disagree with your books authors. It is also very inefficient to have to specify std:: before each of the standard functions.

Five extra characters is highly inefficient? Come off it.

There are many organizations that make "using" a verboten word in their programming standards, with no waivers allowed. (Why allow a waiver when the desired functionality can be achieved with the addition of five easy characters?)

 

[CFDFEAGURU]

LOL, yeah I get that sometimes. Just following my own approach. Anyways, what do you think D H?

EDIT: Let me clarify my position. I don't work for a software development company, I write custom programs to design heat transfer equipment. I am one of 3 programmers and we all use the namespace std declaration.

My goodness, there is no reason to argue with this. LOL Use whatever you like, I was only stating the fact that I don't agree.

End EDIT:

Thanks
Matt

 

[D H]

Sorry, I mean no offense, I just don't agree with the authors. I was taught to use that statement and I use it. It is used routinely in many publications. Such as, Numerical Recipes, one of the most informative books there is on using C++ for numerical computations.

You are overly enamored with Numerical Recipes. It is at best a good starting point. The algorithms are rudimentary, old, and all too often, buggy. The code is, simply put, atrocious.

http://www.ibiblio.org/pub/languages/fortran/ch3-3.html

Numerical Recipes are harshly criticized by numerical analysts for the
quality of the code, algorithms and numerics, and for using algorithms
long ago superseded by better ones. A common opinion is that the routines
shouldn't be used for serious work, as they can give inaccurate or even
plain wrong results without any warning.

Numerical Analysis being a difficult subject to master, NR established
a wide clientele by offering a relatively cheap and very easy to use
alternative. Many users of mathematical software knows very little on
Numerical Analysis and can't judge its quality, or what lack of it means.

http://www.astro.indiana.edu/~jthorn/numerical.html

I have mixed feelings about Numerical Recipes. On one hand, the books cover a wide range of areas in numerical methods for scientific computing, in an easy-to-read and down-to-earth manner, and they come with a substantial library of subroutines. And you can view the books online (either postscript or pdf format) at the Numerical Recipes web site, too. On the other hand, the Numerical Recipes authors aren't really experts in numerical analysis, and alas it shows in the uneven quality of the books' explanations, advice, and the accompanying codes. Here are some (mostly critical) http://www.lysator.liu.se/c/num-recipes-in-c.html" and the accompanying software, by people who genuinely are numerical analysis experts. Overall, I'd say Numerical Recipes is a useful starting point for learning about numerical methods, but it shouldn't be your last book on the subject or on any given topic.

http://amath.colorado.edu/computing/Fortran/numrec.html

Numerical Recipes -- not so good

A collection of comments about Numerical Recipes, a commercial product for which ITS does NOT have a site license, and therefore you will not find on ITS computers. Instead we have the superior Fortran libraries NAG and IMSL on various computers on campus. Also, you can find lots of high-quality public-domain numerical software (Fortran and C) from NetLib.

 

[CFDFEAGURU]

Thanks for the links. I have read some of that before. Personally, I don't have any trouble with the results or the routines.

I think this post has gone awry. You seem hard pressed to put me in my place over a silly disagreement. This thread has become a waste of space.

Thanks
Matt

 

[D H]

Anyways, what do you think D H?

Personally? I never use "using". The programming standards for the group in which I work marks it as a verboten word, along with asm, goto, mutable, register, struct, union, and volatile. That looks pretty draconian. It's not. A waiver for using asm, register, and volatile because doing so would enable a clever programmer to commandeer a computer's graphics cards to perform some very expensive mathematical computations - easily granted. A waiver for using unions in some ported code - fairly easily granted. A waiver for using goto where goto-less code would require significant code replication and quadruple the cyclomatic complexity - also fairly easily granted. A waiver for using 'using' because doing so will save the programmer from repeatedly typing five characters? Not a chance.

 

[CFDFEAGURU]

Thanks. Like I said in post #21, I do not work for a software development company. I don't need to get waivers. I have the ability to write my code as I and the other two programmers that work with me see fit.

From reading your post above, I gather that we work on opposite ends of the programming spectrum. My longest programs which involve 3000 - 5000 lines of code are probably tiny when it comes to yours.

As for the NR critic, I have read most of that before and like I said, I don't have any problems. Also, I never said that the book was the end all for numerical programming, I said it was one of the most informative, in that the routines (even if atrociously written in C++) are explained in (what I think) is a nice readable manner.

However, I am only on this forum to help people when I can and be helped (hopefully) when I need it. If you have a better way to answer a post than I do then good for you. I will read it and hopefully learn something myself. Bickering over some silly statement that I made, I don't believe is called for. So let's get back on track with this thread.

OK?

Thanks
Matt