C++: Pshaw...

[lsibn]

Yeah, whatever. Here's the short version of the story:

I recently discovered somebody took out a $1000 bond in my name, and I was curious as to how long it would take to mature (really only curiosity- have to save it anyway). I looked at freshmeat.net for a compound interest calculator, and found one, but when I tried to download it (it was a C++ file) was told that it was being linked from another server which was not allowed. So I figured "It's simple math, it shouldn't be THAT hard to do..."

So I did. I wrote a version in C that did the trick, with 44 Lines of Code. Then I figured I could make it in C++, just for fun. So I did. I scrapped it, and re-wrote it in C++, and ran it through wc -l. What!? Now it's 97 LoC. I deleted the C version (didn't think to preserve it for posterity's sake...), but posted the C++ version somewhere ( http://utspl.cjb.net/cci.C should do the trick), and you can take a look at it. Is there anything I'm doing wrong there? I thought I had everything right...

But I'm perfectly willing to admit that I've screwed up a few things. Compiling is easy:
g++ cci.C -Wall -o cci

If you use -O0 on my box, the binary is 7084 bytes. If you use -O2, it's 8261.

In case the help message (when you run it) isn't obvious, it takes 3 arguments (no more, no less):
<The amount of money to start earning interest with.> <The rate of interest to compound> <The number of times interest will be compounded.>

So considering that it's so simple, and picky about when it works and doesn't, why is it so difficult to understand the code? I've GOTTA be doing something wrong...

Edit: BTW, there are a couple of unused variables because I wasn't sure how I was going to implement it. But they don't make the listing THAT much longer... I'd strip the variables, but I figured that (at this time) it's about as simple as it'll get, and it works.

[ 18 June 2001: Message edited by: lsibn ]

[Stuka]

C++ will, IMO, have more lines of code than a comparable C program. The power of C++ is not in its brevity, but in its ability to create abstracts that permit more reusable code. That said, a simple (1 or 2 line) constructor that takes the initial values for your object could shorten your code in main(). Declaring all your float variables could reduce the line count by quite a few also. But seriously, line counts are not the best measure of software quality anyway!

[Energon]

it seems to me that the only place LoC count (at least in the 'l33t' circles) is w/ Perl, and that's only through obscurity...

[lsibn]

Well, the reason I ask is not because I'm concerned with the Line Count. I just thought it was odd that one of the advantages of C++ and OOP was that it was supposedly simpler to read and write. IMO, having a longer main() function with all the variables there makes it easier to use
value = value + value / 100 * apr;
than it is to read
item.set (VALUE, (item.get (VALUE) / 100 * item.get (APR) + item.get (VALUE)));

So I'm curious if I'm doing something wrong. All looks good?

[sans-hubris]

I think to think that OOP is the best way to solve all problems is a fallacy. OOP makes certain large tasks easier to handle and understand (e.g. games and GUIs often come to mind.) It'd be like saying Linux can do everything (the day Blizzard starts porting their games to Linux, then I will say it can do everything.)

This is one of those problems where OOP makes the solution harder.

OTOH, you could say that for this problem, all the classes are already provided (floats and ints) for you and so you really don't have to create a new class. Remember, even primitives are classes in C++.

BTW, if you really wanted to make the program more complete OOP, don't use macros (your #defines), use global consts, they allow for better type checking.

[ 19 June 2001: Message edited by: ndogg.cpp ]

[ 19 June 2001: Message edited by: ndogg.cpp ]

[lsibn]

Due note has been taken.

I considered using consts, but decided against it for one simple reason:

Because #define works nicely for the task at hand. :p :D

So I did this the right way, besides that? Any other ways anybody see I could have done much better?

[kmj]

If you can write a program in C in 44 lines of code, then changing it to C++ isn't going to help much, more likely it will make it more complex than necessary. Now, if it were a 20,000 line program, that might be a different story. 'Course, you could probably to the same thing in perl in 25 loc, most likely without making it very obscure to anyone who knows perl. :D

[lsibn]

Originally posted by kmj:
<STRONG>If you can write a program in C in 44 lines of code, then changing it to C++ isn't going to help much, more likely it will make it more complex than necessary. Now, if it were a 20,000 line program, that might be a different story. 'Course, you could probably to the same thing in perl in 25 loc, most likely without making it very obscure to anyone who knows perl. :D</STRONG>
I see... I was under the impression that this would be an easy kill to do, and thought it'd be a great chance to flex some atrophying grey matter. I was confused by the output though... Anyways, thanks. :D

Nice to know that (more or less) I "did the right thing(tm)." :)