| INeedAHero (29) | ||||||
|
Ok, I read your comments and after closely cross-checking between my .h and .cpp I saw what was wrong and corrected the errors. Yet, when I try to compile, the same error messages keep coming up! These are the error messages I am seeing: HugeInteger.cpp: In function âHugeInteger& operator+(const HugeInteger&)â: HugeInteger.cpp:81:6: error: âarrâ was not declared in this scope HugeInteger.h:48:14: error: âint HugeInteger::arr [40]â is private HugeInteger.cpp:81:17: error: within this context HugeInteger.cpp:81:20: error: âaddâ was not declared in this scope HugeInteger.cpp:83:11: error: invalid use of âthisâ in non-member function This is strange to me because I never had a problem with directly accessing arr in the operator+ funciton, but now I'm being warned that it's private. I don't understand that. You said
I don't understand how I could have add(...) only take one parameter when its purpose is to add two different arrays, and it isn't supposed to use any objects. I figure I should post my new .h and .cpp, so you can see the corrections I made: .h
And .cpp
| ||||||
|
|
||||||
| AbstractionAnon (516) | ||||
|
Consider the following two lines: From header: const HugeInteger & operator + (const HugeInteger&);From the .cpp file: HugeInteger & operator + (const HugeInteger& right)Two problems with the implementation: 1) Return type doesn't match (not const). 2) operator is not qualified by the class. Therefore not a member of the class. Should be:
Because the compiler interpreted operator + as a global function (not a member of your class), the errors are telling you that the function could not access private members (add, arr) of your class.
add is a member of the class so it implictly has access to arr. Passing two arrays to add is okay, I was just pointing out that if the first argument was always arr, it wasn't really necessary to pass it. | ||||
|
|
||||
| INeedAHero (29) | |||||
|
Ah, I needed to take a break - spending too many hours in a row programming was causing me to overlook the obvious. I fixed the errors you pointed out, along with a few other ones that popped up, and I got the program running and adding properly. But, when I tried multiplying, I was getting a segment fault. I noticed two errors - one, in my declaration of the array "mult_array[MAX]", I should have mult_array[resultmult.MAX] (line 54 below) - two, in line 87 (below) I didn't have resultmult.MAX, but rather just MAX. Yet, even after fixing both those errors (in a way that I believe was correct), I am still getting a segment fault. I have scoured my code for any other problems, but I've come up empty. Anyone know what can be causing this? It's worth noting that my multiplication algorithm was at one point working without any errors. I have changed none of the logic - I have only converted it into object-based code. The only potential for a logic error would be in line 90 (in the code below), since I altered that so heavily. Though I doubt the logic itself has been skewed. Anyone see what's wrong here? Here's the entire program: .cpp
And here's .h
| |||||
|
|
|||||
| INeedAHero (29) | |
|
Anyone see what's going on here? I'm sorry I can't be more specific with where the problem lies, because I honestly have no idea. I can only say that it almost certainly has to do with incorrectly using an object. That's the kind of error I would not be able to spot, but one of you who have more experience would be able to see. | |
|
|
|
| AbstractionAnon (516) | |
|
I do see a few things: Line 24. result is no longer used. Line 68. You use firstDigit, but it's uninitialized. Line 76. You're testing addzero_ctr, but addzero_ctr is uninitialized. Line 80: addzero_ctr is used as a subscript. Since it's uninitialized you're pretty must guaranteed to get a segmentation fault. Lines 93-97: I'm not seeing the point of these lines. You're setting mult_array, but mult_array immediately goes out of scope. .h line 21: Now that you've overloaded <<, you can probably get rid of Display. | |
|
|
|
| INeedAHero (29) | |||||
|
Thank you so much! I initialized everything like you recommended and the program compiles. Yet I still get a segmentation fault when I run it! I suspect it may have something to do with lines 93 - 97, the ones you commented on. The purpose of those lines is to keep memory of the integer formed during multiplication. Because when you multiply longhand, you need to sum two numbers together: 54 X27 ---- 378 +1080 -------- In that example, I need to remember the 378, so I have mult_array be equal to it, so it can later be added to 1080. And here's my initialized operator*:
And I figure I may as well show the main.cpp
| |||||
|
|
|||||
| INeedAHero (29) | |
|
Segment faults are so tough to deal with! I can't see the error.... Anyone see anything? | |
|
|
|
| AbstractionAnon (516) | |
|
Segmentation faults are almost always the result of bad pointers or bad indexes. Since you're not using pointers, that leaves a bad index. Regarding my comment about lines 93-97. Please disregard. I failed to notice those lines were within the outermost for loop. I'll try and look at your code more throughly tonight. | |
|
|
|
| ne555 (4381) | |||||||||
c = a+b; // ¡¿modifies `a'?! The prototypes should be
Maybe you were confused with compound assignment
| |||||||||
|
Last edited on
|
|||||||||
| L B (3805) | |
| @ne555: why should the return values of operator+ and operator* be const if they are returned by value? | |
|
|
|
| ne555 (4381) | |||
| |||
|
|
|||
| AbstractionAnon (516) | |
|
@ne555 - Why return HugeInteger by value rather than reference? Returning by value is inefficient. A good anology is string. string::assign and string::append both return the modified string instance by reference. | |
|
|
|
| L B (3805) | |
|
@ne555 is that so wrong? Does it corrupt memory or something? @AbstractionAnon The problem with returning by reference is that the object you are returning is not kept alive by the reference. Returning by value is generally very efficient in C++11 because of move semantics. | |
|
|
|
| ne555 (4381) | |||
|
http://www.youtube.com/watch?v=0iWb_qi2-uI form minute 37 to 44 However, I don't think that you could use `move' in this case, as you don't have dynamic allocated arrays. > both return the modified string instance by reference. `operator+' should not modify its operands. Take by instance `std::string' `std::valarray' `int', their operators do not modify their operands. As an alternative, ban `operator+' and use `operator+=' So in order to say c=a+b you'll use
Edit: @LB: I think it is a logic error, better to not compile then. | |||
|
Last edited on
|
|||
| L B (3805) | |
| @ne555 yeah I don't know what I was thinking. Somehow I had it in my head that there were cases where you would want the return value to not be const, but I can't think of any. | |
|
|
|
| INeedAHero (29) | |
|
I would like to say that I corrected the segmentation fault (I forgot return(*this), haha), and I met with my professor today who told me about some changes I have to make, which I think (hope!) I can do on my own. I'd also like to thank all the people who came here and helped me with this assignment. You were all a tremendous help and I really appreciate that you took the time to help me. Thank you! | |
|
|
|