"not really" by itself is a subjective answer.Originally Posted by brewbuck
Not really.
the functions purpose is to check if a number is even or not, the parameter x has postcondition that it will be even.
"not really" by itself is a subjective answer.Not really.
the functions purpose is to check if a number is even or not, the parameter x has postcondition that it will be even.
Then the function's purpose is clearly not to "check if a number is even or not." Its purpose is to ENSURE the number is even.
Remind me not to have you write any code for me...
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
dont worry i wont
again, the functions purpose is obvious. a required side effect or postcondition is that the parameter x is even after the function has returned.
anyways, we arent being constructive and this is doing no good to this thread or forum.
I think the advice to name functions appropriate to their purpose does a great deal of good in general.dont worry i wont
again, the functions purpose is obvious. a required side effect or postcondition is that the parameter x is even after the function has returned.
anyways, we arent being constructive and this is doing no good to this thread or forum.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
i agree (though ive never heard of that design paradigm before!).
from the start, i said it was a silly example, but i just thought of something quick and on the spot to give the thread starter an example. if this were a real-world application, of course the function and postcondition would be documented in detail, so the design team doesnt assume anything incorrectly. it is possible the thread starter isnt even reading this thread anymore, however you or anyone of course can always give them different or better examples to help their understanding.
lots of reasons. consider if you had an object whose data is used and represented in many different places. using a pointer to that object's data prevents you from having to update the values at each of the other locations.
also, if you have a large object, assigning or passing it by value requires you to make a copy of that object which can be quite resource-intensive. a pointer is the same size as an int.
judicious use of pointers can make your code more efficient, reliable, and reduce the total amount of work you have to do.
yes, they will change.
There would be a third, though it is related to the first: for the implementation of data structures that involve "links" of some sort, e.g., linked lists and trees. Also, the second is not as important in C++ due to the existence of reference types, even though C++ references are themselves typically implemented as const pointers.
Actually, only arrays are "passed by reference" due to them decaying to a pointer to their first element, since the pointers themselves are passed by value.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
I am so happy to report that you are wrong!
Since we are discussing C++, they are passed by pointer or by address, not reference.
4 good reasons (most already stated) for using pointers (and/or references):
- Dynamic memory (not so common in C++; usually std::vector is used).
- Allow other functions to modify local variables (if they are not passed by pointer/reference, copies are made and thus the original values are not changed).
- Avoid overhead of copying data (only the pointer would be duplicated).
- Allow several places in the program to see the same data and be able to update it and make the changes reflect everywhere this data is used.
Look carefully at the quotes. We are talking about the computer science term, not the C++ term.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Well, this is C++, so pass-by-reference means using references. There I object to the term. I always have and this is even a better reason to object it. Avoids confusion.
We will not have this discussion again.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
We will not.
This thread is full of hate.
Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
