Valik

Locked per the rules.

Thread locked per the rules.

I think this is a bit overkill? I beat New Game+ in cloth. When the DLC comes out on Xbox 360 next month I'll go through New Game++ in cloth. Anyway, this thread was reported but doesn't violate the rules. It's just number crunching.

That is not our language. Discussion of game automation is against the forum rules anyway. Thread locked.

Thread locked.

Image removed per the user's request. Thread locked because I just don't like this one.

Wow, way to take the suggestion on using those tags so literal you just copy and pasted them including the spaces meaning they didn't do fuck all. Post preview any? Use it. Thread moved to the correct forum.

Was it the threat of death on anybody who touches them besides me? Yeah, probably that.

Locked.

That has what to do with this subject? That has what to do with multi-threading at all?

Err, why would you want to complicate an example by getting the correct currency format? Is that the example? No? Then why the fuck should the example contain it? Examples should work in language neutral ways. If you find that in order to do that you need to add a bunch of extra code... re-think the example.

You have a horrible design actually that is wasting more CPU cycles than you ever will with a polling solution. Thread creation and destruction is expensive. Besides, a quick look at the documentation shows that you can have pcap_next() block until it receives a packet or times out. So no, this isn't really a good use of threading. The program should only have two threads, the first thread would be for the user-interface (This may not be required if you are using a console application). The second thread captures and processes all the packets and sends whatever important information back to the main thread to display. There is no need to add further threads for the pcap stuff.

It's not great feature in a heavily typed language. It's not type safe. That's why printf() and similar are so dangerous and crash prone.

Variable argument lists are very rarely used in user code. They are useful in specific cases in libraries and by far the most common use I have for them is in a wrapper or hook function. The intermediary function accepts some of the arguments and a variable argument list. It does it's thing on the arguments it cares about and then forwards everything to the original function. In C++ the only time I've ever used it is centered around using some of the C string formatting functions. The point is, while it can be a useful feature, it's not a game changer or anything. Most people do not need it. No.

I didn't realize it moved the global file since I set SciTE_Home to the SciTE root directory. Still, is this a big deal?