#C, 72#

i;main(){for(scanf("%d",&i);i;i--)0x952BD7AF7EFC>>i&1||printf("%d ",i);}

Another hardcoded answer. This counts downwards (there's nothing in the rules about the order the numbers have to be output in.) In theory it should work. The constant has a bit set to 1 for all the numbers into which a cube can NOT be cut, and a 0 for the numbers which can. In theory, the constant when right shifted by a very large number should be zero, so the large number should always be printed.

What's interesting is that in practice this does not work. The code above compiles and runs fine on GCC up to 65. But above that number there is a bug (or "feature") in the compiler. it interprets 0x952BD7AF7EFC>>i as 0x952BD7AF7EFC>>i%64. So it skips (for example) the numbers 66 through 71 (64+2 through 64+7).

To run in Visual Studio, a bit more boilerplate is needed (it doesn't let you get away with things like implied integers and #includes.) Once the program's up and running, it's fine up to 257... Then it skips 258 through 263 (256+2 through 256+7.) So it's taking i%256.

I may fix it later (if I can be bothered.) Moral: compiler manuals don't normally tell you the upper limit on bitshifts. There's a reason for that!

C, 72

i;main(){for(scanf("%d",&i);i;i--)0x952BD7AF7EFC>>i&1||printf("%d ",i);}

Another hardcoded answer. This counts downwards (there's nothing in the rules about the order the numbers have to be output in.) In theory it should work. The constant has a bit set to 1 for all the numbers into which a cube can NOT be cut, and a 0 for the numbers which can. In theory, the constant when right shifted by a very large number should be zero, so the large number should always be printed.

What's interesting is that in practice this does not work. The code above compiles and runs fine on GCC up to 65. But above that number there is a bug (or "feature") in the compiler. it interprets 0x952BD7AF7EFC>>i as 0x952BD7AF7EFC>>i%64. So it skips (for example) the numbers 66 through 71 (64+2 through 64+7).

To run in Visual Studio, a bit more boilerplate is needed (it doesn't let you get away with things like implied integers and #includes.) Once the program's up and running, it's fine up to 257... Then it skips 258 through 263 (256+2 through 256+7.) So it's taking i%256.

I may fix it later (if I can be bothered.) Moral: compiler manuals don't normally tell you the upper limit on bitshifts. There's a reason for that!

#C, 73#

i;main(){for(scanf("%d",&i);i;)0x952BD7AF7EFC>>i--&1||printf("%d ",i+1);}

Another hardcoded answer. This counts downwards (there's nothing in the rules about the order the numbers have to be output in.) In theory it should work. The constant has a bit set to 1 for all the numbers into which a cube can NOT be cut, and a 0 for the numbers which can. In theory, the constant when right shifted by a very large number should be zero, so the large number should always be printed.

What's interesting is that in practice this does not work. The code above compiles and runs fine on GCC up to 65. But above that number there is a bug (or "feature") in the compiler. it interprets 0x952BD7AF7EFC>>i as 0x952BD7AF7EFC>>i%64. So it skips (for example) the numbers 66 through 71 (64+2 through 64+7).

To run in Visual Studio, a bit more boilerplate is needed (it doesn't let you get away with things like implied integers and #includes.) Once the program's up and running, it's fine up to 257... Then it skips 258 through 263 (256+2 through 256+7.) So it's taking i%256.

I may fix it later (if I can be bothered.) Moral: compiler manuals don't normally tell you the upper limit on bitshifts. There's a reason for that!

#C, 72#

i;main(){for(scanf("%d",&i);i;i--)0x952BD7AF7EFC>>i&1||printf("%d ",i);}

Another hardcoded answer. This counts downwards (there's nothing in the rules about the order the numbers have to be output in.) In theory it should work. The constant has a bit set to 1 for all the numbers into which a cube can NOT be cut, and a 0 for the numbers which can. In theory, the constant when right shifted by a very large number should be zero, so the large number should always be printed.

What's interesting is that in practice this does not work. The code above compiles and runs fine on GCC up to 65. But above that number there is a bug (or "feature") in the compiler. it interprets 0x952BD7AF7EFC>>i as 0x952BD7AF7EFC>>i%64. So it skips (for example) the numbers 66 through 71 (64+2 through 64+7).

To run in Visual Studio, a bit more boilerplate is needed (it doesn't let you get away with things like implied integers and #includes.) Once the program's up and running, it's fine up to 257... Then it skips 258 through 263 (256+2 through 256+7.) So it's taking i%256.

I may fix it later (if I can be bothered.) Moral: compiler manuals don't normally tell you the upper limit on bitshifts. There's a reason for that!