# Thread: [Jumping into C++] My code for Chapter 7, exercise 3 wont print

1. ## [Jumping into C++] My code for Chapter 7, exercise 3 wont print

Alright, so the problem is this:
Design a program that finds all numbers from 1 to 1000 whose prime factors, when added together, sum up to a prime number (for example, 12 has prime factors of 2, 2, and 3, which sum to 7, which is prime). Implement the code for that algorithm.
I was debugging my work, and it seems I fixed most everything there was to fix. I went through the numbers from 1 to 20, and everything seemed to parse okay. So, I decided to run the program normally, to see if the console prints any wrong results (like it did the other day).

However, this time, the console wouldnt print anything. I have no idea why; I made sure the main outer loop wasn't infinite.

Here is that loop:
Code:
```for (int i = lowest; i <= highest; ++i)
{
/*
if (i == 2)
{
sumHavers.push_back(2);
primeSums.push_back(2);
continue;
}
//^makes the algorithms work better
*/

//ignore the even numbers that arent two
if (isEven(i) && i != 2)
{
continue;
}
else
{
vector<int> primeFactors = getPrimeFactors(i);

//if the current num has prime factors, then we include it
// in our vectors
bool hasPrimeFactors = (primeFactors.empty() == false);
if (hasPrimeFactors)
{
sumOfNums = sumInVec(primeFactors);

if (isPrime(sumOfNums))
{
primeSums.push_back(sumOfNums);
sumHavers.push_back(i);
}
}
}
}

(after this are the cout calls)```
If you need to see the whole (ugly) program, look here: show at bpaste

I'll see what I can do about this in the meantime, but I'd like to know why the cout statements don't get run. 2. Debugging.
Code:
```\$ gdb -q ./a.out
(gdb) run
Starting program: /home/sc/Documents/a.out
^C
0x00000000004016df in __gnu_cxx::operator!=<int const*, std::vector<int, std::allocator<int> > > (__lhs=..., __rhs=...) at /usr/include/c++/4.6/bits/stl_iterator.h:817
817         operator!=(const __normal_iterator<_Iterator, _Container>& __lhs,
(gdb) bt
#0  0x00000000004016df in __gnu_cxx::operator!=<int const*, std::vector<int, std::allocator<int> > > (__lhs=..., __rhs=...) at /usr/include/c++/4.6/bits/stl_iterator.h:817
#1  0x000000000040125c in prodInVec (vec=...) at bar.cpp:232
#2  0x0000000000401038 in getPrimeFactors (num=75) at bar.cpp:178
#3  0x0000000000400ceb in main () at bar.cpp:68
(gdb) c
Continuing.
^C
prodInVec (vec=...) at bar.cpp:234
234           int currentNum = *(iter);
(gdb) bt
#0  prodInVec (vec=...) at bar.cpp:234
#1  0x0000000000401038 in getPrimeFactors (num=75) at bar.cpp:178
#2  0x0000000000400ceb in main () at bar.cpp:68
(gdb) c
Continuing.
^C
0x0000000000401239 in prodInVec (vec=...) at bar.cpp:235
235           product *= currentNum;
(gdb) bt
#0  0x0000000000401239 in prodInVec (vec=...) at bar.cpp:235
#1  0x0000000000401038 in getPrimeFactors (num=75) at bar.cpp:178
#2  0x0000000000400ceb in main () at bar.cpp:68
(gdb) c
Continuing.
^C
0x0000000000401257 in prodInVec (vec=...) at bar.cpp:232
232         for (iter = vec.begin(); iter != last; ++iter)
(gdb) bt
#0  0x0000000000401257 in prodInVec (vec=...) at bar.cpp:232
#1  0x0000000000401038 in getPrimeFactors (num=75) at bar.cpp:178
#2  0x0000000000400ceb in main () at bar.cpp:68```
It's stuck inside getPrimeFactors (num=75)
Now this contains a while(true) loop!
You need to examine all your 'break' conditions, because none of them are being hit.

Stepping a bit deeper....
Code:
```(gdb) b 187
Breakpoint 3 at 0x40106c: file bar.cpp, line 187.
(gdb) c
Continuing.

Breakpoint 3, getPrimeFactors (num=75) at bar.cpp:187
187           currentProd = prodInVec(result);
(gdb) n
188           if (currentProd == num)
(gdb) print currentProd
\$1 = 1211914337
(gdb) print result.size()
\$2 = 9876```
Not only is your loop infinite, but your result vector is growing to enormous sizes for the given inputs. 3. I don't really get all that gdb stuff, but all right. I'll go change my algorithm to avoid that infinite looping. Thanks  4. Alright, so I changed it around to avoid the infinite loop. I struggled a bit in actually making sure each prime factor occur just as often as it should, so I decided to reverse engineer a solution on the internet. Felt stupid afterwards, since the pattern seemed so obvious then. xD I at least actually got how it worked, so I'll be moving onto chapter 8. Popular pages Recent additions console, loop, numbers, prime, sum 