need help debugging

[falsepride]

#include <iostream.h>
#include <stdio.h>
#include <cmath>

typedef unsigned long ULONG;
typedef unsigned short int USHORT;

void user_wait();
void user_wait()
{
     int c;
     cout << "Press enter to continue . . . ";
     do
     {
          c = getchar();
          if(c == EOF) break;
     } while(c != '\n');
}

int main()
{
    ULONG levelExp(99);
    ULONG exp, a;
    USHORT desiredLevel;
    a = 0;
    for (int i = 1; i < 100; i++)
    {
        a += i+(300*pow(2,(i/7)));
        //levelExp[i-1] = a/4;
        cout << a/4 << "\n";
    }
    
    cout << "Enter your mage exp:";
//cin >> exp;
    cout << "\n";
    cout << "Enter your desired level:";
//cin >> desiredLevel;
    cout << "\n";
    user_wait();
    return 0;
}

i just started learning c++, actually my friend lent me his book 1 week ago exactly. so i asked another who plays a rpg called runescape if there was any calculators he wanted so i could make a program for practice. thats what thats a start off. but when i go to compile i get a error pointing to "a += i+(300*pow(2,(i/7)));" and something about going from DOUBLE TO ULONG

[ShadyCraig]

It would seem that the result of that expression would be too big to fit in the ULONG variable 'a'.

Try redeclaring 'a' as a double:
ULONG exp;
double a;

[falsepride]

13,034,431 is how much exp it takes for level 99. at max a will be 4 times that so it'll only reach 52 million. unsigned long integers can handle that much.

[ShadyCraig]

according to this source pow() returns a double:
C Guide--2.7 math.h

if you really don't want to use a double then maybe you could cast the returned variable to a ULONG?
a += i+(300*(ULONG)pow(2,(i/7)));

[teknomage1]

if you cast it afterwords you've still lost accuracy (since your double overflowed). The main reason the library pow function is quick though is because it knows how to take advantage of the fpu. Since your data type needs are well defined, the easiest method might be to just define your own unsigned long integer pow.

[falsepride]

when using shadys answer the numbers didn't come out to what they should be, so tekno how would i do that. the book i reading seems to be more heavy on theory, or teaching how to think in programming. it tells how to polymorph, and opp, pointers, some detail on how computer memory/processing works, how the free store works. but almost halfway through the book and the only library functions it went through are cin and cout. so i don't really know how to do what you said,

[teknomage1]

Well the reason the numbers didn't come out was because the built in pow works with floats or doubles, which are too small to hold your number, so you can define a new version of pow that works with unsigned longs which can hold your large numbers.

unsigned long ulpow( unsigned long base, unsigned int exponent )
{
  unsigned long result = 1;
  while( exponent > 0 ){
    result *= base;
    exponent--;
  }

  return result;
}

That's just a simple translation of the definition of the power function, but it uses the unsigned long so we know it won't overflow with the size of the numbers you need. It's going to be marginally slower than the standard pow, and it doesn't handle as many cases (like fractional exponents or negative exponents). Since your exponent is (i/7), we can't guarantee that's going to be integral so we should modify it a to be a bit more accurate.

unsigned long ulpow( unsigned long base, unsigned long double exponent )
{
  unsigned long result = 1;
  unsigned int integralExp = exponent;
  long double fractionalExp = exponent - (long double)integralExp;
  if( fractionalExp ){
    /* This is still bad since the inexactness here will add up to a lot later*/
    result = powl((long double)base,fractionalExp);
  }
  while( exponent > 0 ){
    result *= base;
    exponent--;
  }

  return result;
}

It's still going to be wrong because it drops significant figures, for example:
pow(2.0,2.5) = 5.565
ulpow(2,2.5) = 4
But for integral values of (i/7) it will be correct, and it should be more correct on large values than the overflowed version. Perhaps smarter rounding might help. I guess it depends on how accurate you need to be.