Why Does My C++ Divide Function Not Compile?

In summary, the conversation discusses an error message that occurred when trying to run a program that involved a function called divide(). The speaker initially had trouble understanding how to set up the parameters for the function, but eventually realized that it was a common function and could be set up like any other function. They also mention that they need more practice with C++ and occasionally forget syntax. The conversation ends with a discussion about how to handle the error path in the function.
  • #36
Jarvis323 said:
To be honest, the rules about C-strings aren't really that straightforward. I wasn't sure because I don't use C-strings whenever I don't have to. The article was the first entry in a google search for "return C-string". I was surprised a little that char * c = "x" (or const char *c = "x") is different than char c[] = "x". I guess the first one is a pointer to a string literal (which has static global storage for the lifetime of the program), and the second one is an array on the stack with automatic storage (gets deleted when out of scope).
In both cases the string literal "x" is in static storage. The pointer variable c holds the address of the string literal. The array variable c of the second example may or may not be on the stack, depending on whether the array is declared inside of or outside a function. I believe that the contents of the string literal get copied to the space allocated for the array. Also, the contents of the array don't get "deleted" when the array goes out of scope; the array contents merely get overwritten.
Jarvis323 said:
You can return a string literal, with the return type const char *, in the sense you are returning a pointer to a const global static string literal that exists for the lifetime of the program. But you can't change a string literal.
Right, you aren't really "returning" a string literal -- just returning a pointer to where the literal is stored in memory.
 
Technology news on Phys.org
  • #37
Mark44 said:
In both cases the string literal "x" is in static storage. The pointer variable c holds the address of the string literal. The array variable c of the second example may or may not be on the stack, depending on whether the array is declared inside of or outside a function. I believe that the contents of the string literal get copied to the space allocated for the array. Also, the contents of the array don't get "deleted" when the array goes out of scope; the array contents merely get overwritten.
Right, you aren't really "returning" a string literal -- just returning a pointer to where the literal is stored in memory.
Right the string literal "x" is in static storage, but (inside a function) c is either a pointer to that static storage or a pointer to stack allocated memory that the literal was copied to, depending on if it's declared *c or c[]. It doesn't get deleted I guess, but the memory is invalidated. I guess "destroyed" is the proper term?
 
  • #38
Mark44 said:
No such thing as "passing by argument."
A function argument is an expression inside the parentheses when a function is called.
In C, a function argument be passed by value, or can be passed by reference (i.e., as a pointer).
In C++, a function argument can also be passed by value, but C++ muddies the water a bit, because an argument can be a pointer or it can be a reference variable.

Some examples.
C++:
int funValue(int a) {return 42;}
void funPtr(int* adr) { *adr = 42;}
void funRef(int& ref){ ref = 42;}

Calls and results.
Code:
int a = 15;
int result = funValue(a);                 // result is set to 42 - no change to a, which is passed by value
funPtr(&a);                               // a is reset to 42
int b = 20;
funRef(b);                                // b is reset to 42
Don't forget R-value references (&&).
 
  • #39
Jarvis323 said:
As long as we don't confuse Japan with Gapan, and Jeff with Geff.
Now you've hurt Geoffrey's feelings. He's probably living in Gapan now too. Not around here anymore at least.
gif.jpg
 
  • Haha
Likes Jarvis323 and sysprog
  • #40
Jee, talk about thread drift... o0)
 
  • Like
Likes jbunniii and Vanadium 50

Similar threads

  • Programming and Computer Science
Replies
6
Views
8K
  • Programming and Computer Science
2
Replies
35
Views
2K
  • Programming and Computer Science
Replies
12
Views
1K
  • Programming and Computer Science
Replies
12
Views
1K
  • Programming and Computer Science
Replies
22
Views
2K
  • Programming and Computer Science
Replies
4
Views
782
  • Programming and Computer Science
Replies
20
Views
1K
  • Programming and Computer Science
Replies
5
Views
2K
  • Programming and Computer Science
Replies
17
Views
1K
  • Programming and Computer Science
Replies
30
Views
2K
Back
Top