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
SUMMARY

The forum discussion centers around a C++ divide function that fails to compile due to improper function definition and scope issues. The user initially attempts to define the divide function inside the main function, which is not allowed in C++. After receiving feedback, the user successfully refactors the code to declare the divide function outside of main, allowing it to compile correctly. The discussion also highlights the importance of returning values from functions and managing variable scope effectively, particularly in the context of error handling with division by zero.

PREREQUISITES
  • Understanding of C++ function syntax and scope
  • Familiarity with error handling in C++
  • Knowledge of variable types and scope management
  • Basic understanding of C++ standard library functions
NEXT STEPS
  • Study C++ function declarations and definitions in detail
  • Learn about error handling techniques in C++, including exceptions
  • Explore variable scope and lifetime in C++ programming
  • Review C++ standard library features, such as std::numeric_limits
USEFUL FOR

C++ learners, software developers, and educators looking to improve their understanding of function implementation, error handling, and variable scope in C++ programming.

  • #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