zhick

@Unimportant: You raise some valid points, namely that the size of int (and unsigned int) have been left implementation defined for a reason, but I think your suggestions overshoot by quite a bit.
E.g.:
Why? If the API returns an unsigned value it's likely because there's no possible way for the value to be negative (size, number of elements, age, there's a whole lot of types/values out there that logically never can be negative). Why would you convert them to a less fitting (and possibly slower, as unsigned integer arithmetic can be faster in some cases) data type? Also how do you go about converting the value safely? To convert safely from signed to unsigned you'll always need the next bigger signed type or make some assumptions about the possible/reasonable range of return values you expect. Which opens a whole new can of worms, like safely figuring out what the next biggest sized signed type is (the standard makes no guarantee that a long int is actually bigger than an [unsigned] int) or handling the possible error case that the conversion was not possible.
 
Ideally we'd all be using (u)int(8|16|32|64|...)_fast_t types when caring about performance while having requirements about the possible range of values, as these are supposed to be the fastest data-type large enough to handle the requested size (but may be larger), but unfortunately these also come with their own set of problems like not necessarily being correct for compatibility reasons.
 
In the end, there's no 100% clear cut solution. Especially not shunning unsigned integers completely.

@Unimportant: You raise some valid points, namely that the size of int (and unsigned int) have been left implementation defined for a reason, but I think your suggestions overshoot by quite a bit.
E.g.:
Why? If the API returns an unsigned value it's likely because there's no possible way for the value to be negative (size, number of elements, age, there's a whole lot of types/values out there that logically never can be negative). Why would you convert them to a less fitting (and possibly slower, as unsigned integer arithmetic can be faster in some cases) data type? Also how do you go about converting the value safely? To convert safely from signed to unsigned you'll always need the next bigger signed type or make some assumptions about the possible/reasonable range of return values you expect. Which opens a whole new can of worms, like safely figuring out what the next biggest sized signed type is (the standard makes no guarantee that a long int is actually bigger than an [unsigned] int) or handling the possible error case that the conversion was not possible.
 
Ideally we'd all be using (u)int(8|16|32|64|...)_fast_t types when caring about performance while having requirements about the possible range of values, as these are supposed to be the fastest data-type large enough to handle the requested size (but may be larger), but unfortunately these also come with their own set of problems like not necessarily being correct for compatibility reasons.
 
In the end, there's no 100% clear cut solution. Especially not shunning unsigned integers completely.

A simple c++ sudoku solver using recursive backtracking I wrote a few weeks ago. This version only solves 9x9 sudokus, but adjusting to other sizes is only a matter of initializing the Sudoku template with another value (eg. Sudoku<4> for 16x16 sudokus).
It's plenty fast for any 9x9 sudoku and some 16x16 sudokus, usually only taking a few microseconds, but on harder sudokus it will take several minutes or hours (or more).
It's 107 lines of code actually, but I'm counting it anyway since the actual program only starts at line 10.
To compile using gcc, save as sudoku_solver.cpp and then type g++ --std c++17 -O3 sudoku_solver.cpp -o sudoku_solver.
Usage: ./sudoku_solver sudoku.txt
#include <iostream> #include <fstream> #include <iomanip> #include <array> #include <algorithm> #include <optional> using namespace std; template<int n> struct Sudoku { static const int width = n * n; static const int n_cells = width * width; typedef array<int, width> Row; typedef array<Row, width> Field; Field m_field; inline Sudoku<n>() : m_field{} {} inline bool validate_row(int num, int i_row) const { return none_of(m_field[i_row].begin(), m_field[i_row].end(), [&](const int cell) { return cell == num; }); } inline bool validate_col(int num, int i_col) const { return none_of(m_field.begin(), m_field.end(), [&](const Row &row) { return row[i_col] == num; }); } inline bool validate_block(int num, int i_row, int i_col) const { const int block_row = i_row / n * n; const int block_col = i_col / n * n; for (int i = 0; i < width; ++i) if (num == m_field[block_row + i / n][block_col + i % n]) return false; return true; } inline bool validate_cell(int num, int i_row, int i_col) const { return validate_row(num, i_row) && validate_block(num, i_row, i_col) && validate_col(num, i_col); } inline optional<Sudoku<n>> get_solution() { Sudoku<n> solution(*this); return solution.solve_recursive(*this, 0) ? solution : optional<Sudoku<n>>{}; } inline bool solve_recursive(const Sudoku<n> &sudoku, int index) { if (index == n_cells) return true; const int i_row = index / width; const int i_col = index % width; if (sudoku.m_field[i_row][i_col] != 0) return solve_recursive(sudoku, index + 1); for (int num = 1; num <= width; ++num) { if (validate_cell(num, i_row, i_col)) { m_field[i_row][i_col] = num; if (solve_recursive(sudoku, index + 1)) return true; } } m_field[i_row][i_col] = 0; return false; } }; template<int n> ostream & operator<<(ostream &os, const Sudoku<n> &sudoku) { for (const auto &row: sudoku.m_field) { for (const auto &cell: row) os << setw(2) << cell << " "; os << "\n"; } return os; } template<int n> istream & operator>>(istream &is, Sudoku<n> &sudoku) { for (auto &row: sudoku.m_field) for (auto &cell: row) is >> cell; return is; } int main(int argc, char **argv) { Sudoku<3> sudoku; ifstream(argv[1]) >> sudoku; auto solution = sudoku.get_solution(); cout << "Input:\n" << sudoku << "\n"; if (solution) { cout << "Found a solution:\n" << *solution; return 0; } cout << "No solution found.\n"; return 1; } Example input file:
Example output:
 

Maybe to expand on this a little bit:
Yes, this is a very simple mistake, but mistakes of this kind are quite common and stem from doing "the same thing" at two different points, which makes it easy to mess up.
In this case you could restructure your program to make it so the input is only always read at one point:
Instead of
int user_input = 0; // ... printf("Enter an integer:\n"); scanf("%d", &user_input); while(user_input != 0) { // ... printf("Enter an integer:\n"); scanf("%d", &user_input); // ... } You could just have this as
do { int user_input = 0; printf("Enter an integer:\n"); scanf("%d", &user_input); if (user_input == 0) exit; // .. } while (1) This way it's always clear when input is read (only ever at the beginning of the loop) and when it's processed.

Exactly.

Again:
To be more precise: Which number are you using to decide whether a number is negative or positive?

Yeah, maybe I could've worded that better. What's the value of the variable you're comparing to zero (don't worry, that part is correct) at that point in the program?
Btw, I don't mean to lead you on, so if you'd prefer me to just tell you the solution just say so. I just think it's better to point someone in the right direction and let them figure out the rest of the way themselves.

Your problem is not that you're not counting negative numbers, but you're not counting the last number entered:
Enter an integer: 1 Enter an integer: 1 Enter an integer: 0 Overall: Count is 2, sum is 2, maximum is 1, minimum is 0, average is 1.000000 Positives: Count is 1, sum is 1, maximum is 1, minimum is 1, average is 1.000000 Negatives: Count is 0, sum is 0, maximum is -65535, minimum is 65535, average is 0.000000 Take a close look at when you do the counting.

Python + PyQT could be a good choice for your scenario. You could even use qt-designer for a fairly simple WYSIWYG-edior, with a simple google-search I came up with this tutorial: https://wiki.python.org/moin/JonathanGardnerPyQtTutorial.
Or you could just use plain qt (in that case, you're probably best of with reading the official qt-documentation, most things map pretty directly into PyQT).
Just understand that what you're asking for (looks like blender) is not an easy task (Blender is a very complex programm), especially since you don't seem very familar with programming. You'll have to do quite alot of research.

In my opinion I suggest people to never fall into the pc gaming trap, the 7950 is plenty fast enough. If I where you I would either save up the money, or spend it on steam games. 7950 to 780 is not that big of a boost, and in my opinion is not worth the money. 

Good job TechFan@ic. Nice write-up. Though I'm not sure I 100% agree with your point of Intels better energy-efficiency being solely a function of their better manufacturing-process. But that's hard to figure out I guess.
But your other points are pretty much spot-on.
 
To anyone who has doubts if APUs really are the future, just ask yourself this one question: What if PhysX was an AMD-technology?
Suddenly every gamer would get an APU just to have a dedicated PhysX-Processor build right into his CPU.
AMD's idea with the APUs was clearly right, they just could have executed it a bit better. But hopefully in the future more gaming/physics-stuff will move to OpenCL, and the power of the integrated graphics card will be better used for gaming.

How about building your own string class from scratch, its a reasonable sized challenge and tests concepts of pointers and classes (plus it is good practice, I had to do this for a university assignment).

This babe right here^

Nice build.
The Zalman heatsink made me feel nostalgic as it reminded me of my first pc, which also had a Zalman heatsink.
Actually it had a CNPS 9500, which is why I'm 99% sure your heatsink is some other modell as it looks quite a bit different (and probably wouldn't fit on a 1155). ;)

I'm not too sure about AVG myself. I'm not a fan of anti-viruses. 
 
I never use anti-viruses anymore and I haven't had a single hitch. I can't say the same for when I used to use one though.
 
My advice is, don't believe them when you're told there are sexy singles in your area ready to meet you and you should be fine.

s/Daft punk/Iron Maiden/ and I'm done. ;)

Woah, much younger demographic than I'd have expected. I expected more people around my age (23). No wonder someone asked what game Linus and Slick were playing during their Super Mario World playthrough-afterparty-thingy.
Kinda makes sense though, iirc it was around 16-17 when I was really excited for pc-hardware and so on.

I think the very first nickname I used was Aton (like the egyptian god) because at that time I was interrested in egyptian mythology.
I then eventually got tired of people confusing it with "Anton" (somewhat commong german name) and decided to switch my nickname to SickThought, mainly because I thought it sounded kool and evil-ish.
At some point I tried to register on a website but SickThought was already taken, so I used Zhick instead of Sick because I figured it would be pronounced the same (I'm not a native english speaker so I'm not 100% sure to this day ;) ).
Then a few years later I began feeling somewhat silly about my username, so I dropped the Thought part so the name would become more abstract. And that's how I ended up with my current name. :)
I still feel a bit silly about it, but as legodude I'm to lazy to go and change it. :)