I have program that uses a Money class which has several constructors for different methods of input and overloaded operators to add, subtract, and compare values.

I am having difficulty defining my int asCents(const Money& amount) const; method so that it can be used in other functions. Used correctly, is it best practice to return the integer it produces as opposed to creating two new ones equivalent to it (amount.getCents() + amount.getDollars() * 100;)? How else can this program be improved?

None of your overloaded operators (except for the stream ones) need to be friends. operator+, etc. can be defined inline and operator==, etc. can be defined non-member. The fact that you use the public interface in operator== is a strong hint that it doesn't need to be a friend.

There's a LOT of code duplication going on. The operators can be overloaded in terms of each other. (You should also make the relational operators const.)

\$\begingroup\$“You should also make the relational operators const” – that is solid advice for most member functions, but then you show a bool operator>(const Money&, const Money&) const that looks suspiciously like a free function rather than a member. Does the const qualifier even work there? What would be made const, considering that both arguments already are const Money&? There is no this pointer. But if it were a member function, how coukd the operator> take two arguments? Sorry, I'm still new to operator overloading in C++.\$\endgroup\$
– amonSep 27 '15 at 11:25

\$\begingroup\$I diasagree with your friend comment. This is the one classic case where they are better as friends as this is one of those times were auto conversion is useful and only happens properly for friends. i want Money + integer to behave in the same way as Integer + Money this is what friend functions will achieve that members will not.\$\endgroup\$
– Martin YorkSep 27 '15 at 15:39

\$\begingroup\$Also you can define friends inline. I do that all the time for simple functions.\$\endgroup\$
– Martin YorkSep 27 '15 at 15:40

\$\begingroup\$You should never track money as a double. Floating point values can not store all values exactly and thus when you do other operations you get rounding errors.\$\endgroup\$
– Martin YorkSep 27 '15 at 15:42

Although it's mostly personal preference, you could still add std:: wherever needed and leave out all the usings. This could reduce a bit of clutter towards the top. Plus, you never included a using for abs, though the compiler may sometimes fail to catch that.

Since you're using just dollars and cents, perhaps this class could be renamed to something more specific like USD. Regardless, your print statements can still include the $ character so that the user will know it's still a monetary value and not just a regular numerical value.

There is a slight indentation inconsistency in the centsPart() statement:

The print statement, especially such an informal one, isn't necessary. Just leave it for client code if desired. The user may also not be expecting the program to exit after a failed construction, and I don't think it's too common. It may be better to instead throw an exception on failure while making the user aware of that.

You already have a try block in main() for two constructors and a member function, but it won't be of any use unless they can throw something. If you do make this change, you can also catch that specific exception instead of just a generic std::exception and its associated error. That could also make it easier to determine which entity has thrown an exception, if made possible for more than one of them (but not likely the default constructor).