Why Does My C++ Divide Function Not Compile?

  • Context: C/C++ 
  • Thread starter Thread starter yungman
  • Start date Start date
  • Tags Tags
    C++ Function
Click For Summary

Discussion Overview

The discussion revolves around a C++ divide function that does not compile correctly, as presented in a programming textbook. Participants explore issues related to function definitions, variable scope, and error handling in the context of C++ programming, particularly focusing on the correct implementation of a divide function that handles division by zero.

Discussion Character

  • Technical explanation
  • Conceptual clarification
  • Debate/contested
  • Homework-related

Main Points Raised

  • One participant shares a code snippet that fails to compile due to the incorrect placement of the function definition within the main function.
  • Another participant suggests that the divide function should be defined outside of main and provides a corrected version of the code that works as intended.
  • Concerns are raised about using a global variable to store the result, with suggestions that the function should return a value instead.
  • Some participants emphasize the importance of handling division by zero properly, proposing the use of NaN (Not a Number) to indicate an error instead of returning zero.
  • There is a discussion about the syntax of functions in C++ and the need for practice in using return values effectively.
  • Participants reflect on their learning experiences and the challenges they face in understanding function syntax and scope in C++.

Areas of Agreement / Disagreement

Participants express a mix of agreement and disagreement regarding the implementation details of the divide function. While some agree on the need to avoid global variables and handle errors appropriately, others highlight different approaches to function design and error handling, indicating that no consensus has been reached on the best implementation.

Contextual Notes

There are unresolved issues regarding the handling of division by zero and the implications of using global variables versus returning values from functions. The discussion also touches on the participants' varying levels of familiarity with C++ function syntax and error handling practices.

Who May Find This Useful

This discussion may be useful for individuals learning C++ programming, particularly those interested in understanding function definitions, variable scope, and error handling in mathematical operations.

  • #31
sysprog said:
Yes, I glance-read the article ##-## my main quibble with it is that that the writer spells 'gibberish' with a 'j' ##\dots##
I don't mind. J makes more sense. This is why I'm not Garvis323 ;)
 
Technology news on Phys.org
  • #32
Jarvis323 said:
I don't mind. J makes more sense. This is why I'm not Garvis323 ;)
Are you trying to rule out the soft 'g'? Should we have to write 'jermane' instead of 'germane'? Can we please still write 'Germany', and not 'Jermany', even though there's such a name as 'Jeremy'?
 
  • #33
sysprog said:
Are you trying to rule out the soft 'g'? Should we have to write 'jermane' instead of 'germane'? Can we please still write 'Germany', and not 'Jermany', even though there's such a name as 'Jeremy'?
As long as we don't confuse Japan with Gapan, and Jeff with Geff.
 
  • Haha
Likes   Reactions: sysprog
  • #34
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). 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, and the usefulness of having functions which return C-strings is limited.

I also maybe shouldn't say that C is a subset of C++. Some things are legal in C but not in C++. For example, apparently char * c = "x" is (supposedly) depreciated in C++ (should be const * char c = "x"), but not in C.
 
  • #35
yungman said:
Is passing by argument the only way, to pass by reference or pointer?
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
 
  • #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.
 
  • #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   Reactions: Jarvis323 and sysprog
  • #40
Jee, talk about thread drift... o0)
 
  • Like
Likes   Reactions: jbunniii and Vanadium 50

Similar threads

  • · Replies 6 ·
Replies
6
Views
12K
  • · Replies 35 ·
2
Replies
35
Views
4K
  • · Replies 17 ·
Replies
17
Views
2K
Replies
12
Views
2K
  • · Replies 22 ·
Replies
22
Views
4K
Replies
20
Views
2K
  • · Replies 8 ·
Replies
8
Views
4K
  • · Replies 17 ·
Replies
17
Views
3K
  • · Replies 36 ·
2
Replies
36
Views
6K
  • · Replies 118 ·
4
Replies
118
Views
10K