Unimportant

Why not? Besides the handful of applications that require the latest and greatest there's a million more where a core 2 still does fine. Heck, my q6600 can still hold it's own in many games.

Honda, never had a single failure in 16 years, I stick with what works for me.

You can find lots of 6/7.2V soldering irons on google. I have a 6V ersa multitip. Simply use 2 18650 li ions in series and you're set. Been working great for me, and since they're standardized batteries, cheap to replace when worn.

You indeed have to add a series resistor to each led. The resistor divider values can be magnitudes higher, negating the power loss. It's a bit overkill to use a microcontroller for this imo. Also, with all this microprocessor playing ppl lose basic analog circuit knowledge (or never learn it). I'd suggest doing it with transistors simply for the knowledge, this is very basic stuff anyone serious about electronics should learn.

No, The BE junction will always have 0.7V over it max, it's like the Vf of a diode. The resistors limit the current, just calculate the resistor divider to never allow more base current then the transistor can handle at the maximum voltage. The range in minimum base current for the transistor to start conducting upto maximum current is so huge it won't pose a problem.

A NPN transistor + resistor voltage divider for each led would also work. The transistor will only start conducting when there's about 0.7V between the BE junction. By calculating different voltage dividers for each transistor you can make the transistors turn on one by one as voltage rises.

Actually, you should make it a habit of removing magic numbers from your code, a possible solution would be: int index, mean = 0; //Remove the array size from the brackets, now the array will //automatically be the size of the number of elements you //initialise it with. int response[] = { 6, 7, 8, 9, 8, 7, 8, 9, 8, 9, 7, 8, 9, 5, 9, 8, 7, 8, 7, 8, 6, 7, 8, 9, 3, 9, 8, 7, 8, 7, 7, 8, 9, 8, 9, 8, 9, 7, 8, 9, 6, 7, 8, 7, 8, 7, 9, 8, 9, 2, 7, 8, 9, 8, 9, 8, 9, 7, 5, 3, 5, 6, 7, 2, 5, 3, 9, 4, 6, 4, 7, 8, 9, 6, 8, 7, 8, 9, 7, 8, 7, 4, 4, 2, 5, 3, 8, 7, 5, 6, 4, 5, 6, 1, 6, 5, 7, 8, 7 }; //Divide the size of the array by the size of a int to get the number of //elements, this will now work for any array size without needing to change. //Since these are all compile time constants there will be no performance penalty. for(index = 0; index < (sizeof(response) / sizeof(int)); index++) mean += response[index]; printf("%d", mean);

Every time you call a function, the address to return to is stored on the stack. This way, when the function is done, it can get that address from the stack in order to continue execution on the next line after the function call. In your original code, the function "ContiniuousChecker" calls itself over and over again without ever returning. That means return addresses are endlessly put on the stack but never taken off, until the stack overflows. All you need is a endless loop like @espurritado demonstrated.

scanf is widely considered not safe, as there is no way to guard against buffer overflow when the user enters more characters then the length of the array. Common practice is to use fgets on stdin, which allows to pass a maximum amount of characters to read: char stringarray[256]; fgets(stringarray, 256, stdin); And simply extract the first word manually, ignoring the rest, this could be easily done by searching the string and replacing the first space with a 0, effectively truncating the string after the first word.

Whoa there, it's a little more complicated then that... stringarray decays into a pointer pointing to the first element of the array, stringarray[0] IS the first element in the array, 2 very diffirent things: char stringarray[] = "Foo"; //stringarray decays into a pointer pointing to the first element, thus: stringarray == &stringarray[0] //However: sizeof(stringarray) != sizeof(&stringarray[0]) //The first returns the size of the entire array, the latter returns the //size of a char* pointer. There is also a difference between stringarray and &stringarray: //stringarray and &stringarray both point to the first element in the array, thus: stringarray == &stringarray //but, they are of diffirent types, thus: (stringarray + 1) != (&stringarray + 1) //Because stringarray is of type char* and &stringarray is of type //char (*)[4]

int getMapFromFile(char ***map) Being a 3 star programmer is not a compliment. You're doing something very wrong if you have to resort to this imho. It's a telltale sign your code needs to be simplified, which will probably solve the bug in the process. I'd flatten the whole thing out into a normal 1D array and simply use index arithmetic to access rows/columns. It'll be less of a memory management hassle and passing the array along to functions will be much cleaner. The index arithmetic can be neatly wrapped in some accessor functions.

Files and directories starting with a dot are simply hidden files on Linux.

You don't want work - you want the things created by the work. If robots could do all the work while humans lie at the beach all day we'd be just as rich while relaxing all day long. The difficult part is getting from here to there. The gains would off course go to the owners of the robots and not the displaced workers. But in stead of once again looking to government to forcefully redistribute and putting a monkey wrench into the whole process we should be looking toward systems of shared ownership. Every person should be able to buy his 'robot share'. Share the risk and the rewards, not the current system of taxing the risk taker to pay the non-risk taker thereby retarding risk taking and thus the economy, because it's the risk takers that get stuff done, we can't all be employees, somebody has to stick out his neck and start things up in the first place.

Normally, one declares a class's structure in a header file and implement the actual member functions seperately outside the class, in a matching .cpp code file for example. When you write the full member functions implementation inside the class then the functions are automatically inlined. ( https://en.wikipedia.org/wiki/Inline_function ) The compiler is warning you that because one or more of your member functions includes a "while" or "for" it cannot make them inline and in stead makes them normal functions. The solution of choice to remove the errors is to place the member functions in their own seperate code file.

The US is piling on debt at a record rate with hardly any growth to show for it, bumbling toward the next recession with rates still at 0% and the rest of the economic surplus nations are working hard to replace the dollar as the reserve currency... The last thing you need is a president handing out stuff - you're in way farther then most ppl like to believe - There's a tiny chance Trump actually gets this as he talked about it in small occasions. The first point in trying to right the ship is acknowledging it's off course.

Goes to show how the main stream media can brainwash ppl. On our local news/radio it's the same shit, the world is gonne end now, while it would have been nirvana with Clinton. ... Gimme a fucking break... If Trump is the end of the world, Clinton would've been the end of the universe, that woman is batshit crazy. Try reading some of those leaked emails without getting sick, it makes pussygrabbing look like childsplay.

Some MSI mobo's have a USB overcurrent trigger on the pin where the cable shield would normally go. The constant triggering of USB overcurrent events once a device is plugged in (and bridges the shield and ground) makes the PC laggy. The solution is to disconnect the cable shield pin somehow (pin 10 on the header). If it isn't a MSI motherboard or perhaps a USB3 header then disregard this.

You can use the "SendInput" windows API function on C++ : https://msdn.microsoft.com/en-us/library/ms646310(v=vs.85).aspx

8031 family microcontroller with keyboard firmware loaded into it, probably ROM - so can't be reprogrammed. In other words, useless. If you want to play around with microcontrollers, google for microchip PIC or atmel AVR, among others.

The accepted answer made multiple changes to your code so I don't know if you now realize what the problem was and have learned anything? When you declare a static class member in C++ there is no memory allocated for it - you need to define it separately. The reason is obvious, the member lives outside the class data in it's own little space. This line in the accepted answer is what fixed things: double account::interestRate = 0.1; So your original code was fine, as such: class SavingsAccount { public: static double annualInterestRate; int accountNumber;//from 1000 to 4999 . . . }; . double SavingsAccount::annualInterestRate = 0.1; //Define and initialise. . static void SavingsAccount::modifyInterestRate(double percent) { cout << "Monthly interest rate is to be changed to " << percent << "%" << endl; annualInterestRate = percent; } Do note that non-const static data members are nothing more then glorified global variables, with all the evil that implies.

You keep breaking basic c++ best practices rules and running into trouble because of it, all the while ignoring advice I tried to give in previous posts. How long are you going to keep stumbling about like this ? Once again from the top: -Learn const correctness. -Never have a class manage more then 1 resource. -No naked new. use RAII to wrap them (std::unique_ptr)... -Rule of three... For starters...

I'd put the clear CMOS jumper in the clear position. Most boards do nothing when powered on with that jumper in the wrong position and I'm always amazed with how few ppl find the culprit. You disconnected the chipset fan -> Was it even running when connected? I remember having to RMA boatloads of early nForce4 motherboards like that one because the tiny crappy fan failed within months.

The compiler converts your code to machine code in the form of a object file. Each source file (larger projects are spread into multiple source code files) is converted to a object file, for example if your project contains: MainProject.cpp SomeLibrary.cpp AnotherLibrary.cpp Then after compilation you will end up with: MainProject.o SomeLibrary.o AnotherLibrary.o Combining all those object files into a single executable is done by the linker. It's important to understand this to be able to distinguish compilation errors from linker errors. A Debugger allows you to step trough your code line by line, keeping a watch on variables so you can see what happens and try to catch bugs. A compiler will have the option to compile code eigter for release or debug. Debug code contains all kinds of checks and hooks to ease the debugging process, but because of this runs much slower. Release code is used when the program is done and debugged, and is ready to be released. Release code is much faster then debug code. A IDE or integrated development environment combines a editor, compiler, linker, debugger and possible other tools into one package. It allows to easily overview, search and edit your program and compile and run/debug with a single click.

Once a full stl compatible iterator is implemented (the above is obviously only a small, incomplete, sample) one could do this in client code: auto it = std::find(MyList.begin(), MyList.end(), EntryToLookFor); it.Delete(); All this needs to work is for the "MyList" class to have a "begin" function that returns a "MyListIterator" to the beginning of the list (We already have that, MyListIterator's constructor does that). A "end" function that returns a "MyListIterator" to the list's end. (clearly trivial) and a ++ operator for the iterator, which we also already have.

I say test again. My code produces the required pattern, your code just prints 10 '*' on each line like i expected. You are simply overwriting the terminating 0 in stead of moving it up.