Find primes using “naive” algorithm

A quick detail

You've written inc == 2 ? inc = 4 : inc = 2; : this is not the ""right"" way to use the "ternary" operator. Don't get me wrong, it will do what you expect it to do. However, the whole point of the operator is to return a value. In your case, it is no different that : if (inc == 2) inc = 4; else inc = 2;.

This calls for a ternary operator but to write it in a simple way : inc = (inc == 2) ? 4 : 2;

Code style and good practices:

On a C++ program you should give preference to the standard C++ library. I know the syntax of printf and friends might be tempting some times, but std::cout is the proper C++ way of printing to the standard output.

You should also prefer to use std::numeric_limits over the macros of <climits> (ULLONG_MAX).

This block could be rewritten to use both numeric_limits and const:

ull limit = ULLONG_MAX;
if (argc > 1) limit = std::stoi(argv[1]);

Using the ternary operator:

const ull limit = (argc > 1) ? std::stoi(argv[1]) : std::numeric_limits<ull>::max();

Try to take advantage of const whenever you can.

Possible otimization:

Some time is probably being spent reallocating the vector primes when it has to increase its capacity. If you could pre-allocate some estimated space with vector::reserve() before entering the loops, it could potentially give a performance boost to your program.

Miscellaneous:

Judging by your use of std::stoi, your compiler is probably C++11 compliant. You can then try the new using alias to replace the older style typedef:

using ull = unsigned long long;

In terms of performance, the first thing to note is that writing to a terminal is slow. time ./primes gives 7.995 seconds on my machine, but time ./primes > primes.out gives 5.107 seconds, already 36% faster.

The next thing is that 64-bit integer division/modulo operations are horribly slow, something like 50 cycles each compared to around 5 for a 32-bit division. If you swap unsigned long long for unsigned int or std::uint32_t (from <cstdint>), the runtime drops to 2.383 seconds.

By the way, this line:

for (ull j = 0; primes[j] * primes[j] <= i && j < primes.size(); j++) {

is particularly scary because the primes[j] * primes[j] <= i check happens before the j < primes.size() check, potentially accessing outside the vector. But it turns out not to cause undefined behaviour because the first inequality will always become false before the second.

A simple way to make this faster: You check primes [j] * primes [j] <= i all the time, over and over again. In reality, lets say i = 1001, then you will check the primes up to 31. And you will check the primes up to 31 until i = 37*37 = 1369. So have a local variable n that indicates how many primes you might be checking at most, and if i == primes [n] * primes [n] then increase n by 1.

Also, start the loop with j = 2 since i is never divisible by 2 or 3.

You really should add more comments to your code. I'd also write out increment rather than abbreviating inc. After reading the other answer, I was wondering what inc did. It took me a little bit to find where it was actually used. In general, any time you do something clever, you should comment.

// 2 and 3 are the only primes that do not fit the pattern 6 * n +/- 1
// so we don't have to check every number, we can start with 7 (6*1+1)
// increment by 4 to 11 (6*2-1); increment by 2 to 13 (6*2+1);
// so on and so forth.  We alternate incrementing by 2 and 4 every time.
// we update the increment during the loop, so setting to 2 now
// means that we will set to 4 for the first iteration
int increment = 2;
for (ull i = 7; i <= limit; i += increment) {
    // 6 - 2 = 4 and 6 - 4 = 2, so subtracting increment from 6
    // alternates between 2 and 4, as we want
    increment = 6 - increment;

Your default limit won't work. The variable will never be greater than its maximum. This is especially bad because you are using <= and an increment greater than 1. It might barely work when incrementing by 1 with <. As is, you need a maximum limit of something like ULLONG_MAX - 7.