rip-off

The best you can say is that some languages were built as scripting languages first, and only incidentally received standalone runtimes. Lua, for example, is mostly used to script existing programs, but you can write full applications in it if you want. Javascript is most famous as the scripting language for browsers, but with Node.js it becomes a powerful platform for standalone server applications.

I don't see the distinction as being particularly useful anymore.

I guess we're both having conflicting definitions of 'fix'. The mistake, in my mind, was using 'i++' when '++i' should have been used instead. In order for the compiler to 'fix' that mistake, it'd need to invoke the pre-increment instead of the post-increment operator. I disagree that the compiler can fix the mistake, however, I do agree that in some cases the compiler can hide the mistake.

I don't see the point in this argument. The point here is the result. If the resulting executable is equally fast, then there is no "mistake". If I know the compiler will manage this for me, why should I waste precious brain cycles worrying about it, when I can put them to better use finding and eliminating bottlenecks. Your whole line of argument appears to be counter-productive and just pedantic really.

Optimising for size doesn't change much. Here is the output assembly:

; 13   : 	// Print post
; 14   : 	for(std::vector<int>::iterator it = v.begin(); it != v.end(); it++) {

	mov	esi, ebx
	cmp	ebx, edi
	je	SHORT $LN4@main
$LL82@main:

; 15   : 		printf("%d\n", *it);

	push	DWORD PTR [esi]
	push	OFFSET $SG-31
	call	_printf
	add	esi, 4
	pop	ecx
	pop	ecx
	cmp	esi, edi
	jne	SHORT $LL82@main
$LN4@main:

; 16   : 	}
; 17   : 	
; 18   : 	// Print pre
; 19   : 	for(std::vector<int>::iterator it= v.begin(); it != v.end(); ++it) {

	mov	esi, ebx
	cmp	ebx, edi
	je	SHORT $LN1@main
$LL112@main:

; 20   : 		printf("%d\n", *it);

	push	DWORD PTR [esi]
	push	OFFSET $SG-32
	call	_printf
	add	esi, 4
	pop	ecx
	pop	ecx
	cmp	esi, edi
	jne	SHORT $LL112@main
$LN1@main:

Code speaks louder than words. Next time you make an assertion that can be trivially proven using code, kindly do so. It spares me the time debunking your statements.

If you're putting your iterator implementation in a DLL and optimising for size then maybe you aren't too worried about performance after all.

Why not write the File constructor in terms of the standard file APIs. Unlike the other functions you are not using any unusual system calls. One path is easier to maintain and will mean less work when you include proper error checking, plus std::fstream objects are RAII to boot. You might be able to rewrite some of your other functions in terms of them too, those that don't require the file modification times.

Why WIN_DOWS? There are already standard Windows definitions.

This is more curiosity than anything else, but what is the purpose of the template parameter to ReceiveCompressedBuffer, given that it is not used?

You have an assignment in your conditional. The line if(x = 11) sets x to 11, and then tests if 11 is non-zero. It is, so the function always returns immediately.

Having a firewall is the way to preemptively drop such connections. Otherwise you'll have to adopt the other approach of closing the connections after they've been accepted.

This site gives you a journal for free. Click on your user name in the top left and there should be a link  to "My Journal", which you can post such things in. There are plenty of places you can create free blogs, such as wordpress.com.

The forums are for mainly for technical discussion, with some exceptions including the lounge.

Your posts could do with more paragraphs to keep them readable. But the main thing they suffer from is bouncing all over the place. They are really hard to follow and you digress and digress again. If you want to rant about mining or the price of fuel don't do it in a thread about programming, it makes no sense; the topics are unrelated. I would make two blog posts about these topics, had I something to say about them.

Clarity and brevity would add much to your writing style. Knowing what to exclude is often the key to simple, understandable writing.

The same way SimonForsman suggested, with the following in some source file:

std::list<MyClass*> MyClass::instances;

You said earlier you had no main source file but you can put such definitions in any source file - which you must have at least one of anyway, for main().

Besides, I'm sure PhysX has some way of handling this... usually such libraries provide some "user data", often an opaque or void pointer, which you can set to whatever you want and you can retrieve in the callback. Such a suggestion is included in this thread.

If this allows you to avoid the global instance list, then I would recommend doing so.

The static keyword allows you to create non-member functions that can access private data. I might do this when I have a function which logically operates on a pair of objects, or maybe a collection of them. For the former, if you write a.function(b) this appears to give some kind of "priority" to "a", because it is the method invoker. I'd prefer to write function(a, b) if there is no logical priority between the two objects in the function body.

Of course, ideally you wouldn't need to access private data in non-member functions, but at the same time sometimes writing a small static function offers better encapsulation than exposing this private information in the public interface, which is available to all callers.

A classic example might be having private constructors and a public static function which returns an instance of the class. I sometimes do this so I can be more explicit about the nature of the constructor, SomeParser(true) or SomeParser(false) aren't as clear as SomeParser::buildCaseSensitive() and SomeParser::buildCaseInsensitive().

I would be 100% surprised if your custom dynamic array class comes even close to the performance of std::vector<>, used properly. Most of the time when people say "vectors are slow", they are actually saying "I don't know how to use vectors".

To eliminate bottlenecks, you must first understand them. I can guarantee you that either std::vector<> is being used incorrectly, or your bottleneck is that you are using the wrong data structure/algorithm and replacing it with a custom dynamic array will not help.



As Antheus mentioned, just passing the right set of flags to the compiler can result in a massive performance boost.

Consider using std::vector<> for managing dynamic numbers of objects (it is a resizeable array that is easy to use and hard to break). Consider using smart pointers rather than managing memory yourself. Also, if possible, see if you can keep a std::vector<> of values, this is the simplest solution.

Manual dynamic allocation should be rare. You probably don't need it here.

Your game is not going to be running at thousands of frames per second. The tearing would be unacceptable - you will be vertically synced. Benchmark real situations.

I suspect you might have a dual core processor, and the difference is that if your application is started on a "busier" core, that it will run fractionally slower. OSes try not to switch threads between processors if they can avoid it, because doing so is quite expensive. This is why it varies from run to run.

I don't think it is worth worrying about.

Consider using classes to manage such memory, typically std::vector<> or std::string. These classes remember their sizes, even when passed to functions.

First of all, realise that local variables in different functions are totally unrelated, even if they share the same name.

Ok, let us look at your original code where you called userInput():

userInput(guessLetter);

What you are doing here is passing a copy of the variable guessLetter to the function. The parameter is modified inside the function, but this doesn't matter as the modifications are to a local copy. You are not capturing the return value, so it is lost.

To get it to work, change the return type of userInput() to char, drop the parameter to the function (it is unnecessary) and change the line above to: guessLetter = userInput();.

Two other points. First, drop the character arrays, use std::string everywhere. Secondly, you should be able to write the entire program without using a single (non-constant) global variable. This means you have to pass and return more information to each function, but it will make your code easier to read and maintain.

You want to use a container to store an arbitrary number of blocks. A simple example for the moment might be std::vector<>, or you might want to look into a data structure that can take advantage of the spatial nature of the data. An arbitrary sized 2 dimensional array would be an example if your platforms are "tile" based.

bool registerCallback(int(*callback)(int,int,int,int*,float*))

If "callback" is the name of the variable, what do you think the type is?
<hr>Consider making your argument list a structure. It will ease maintenance if you decide to extend or change your signature in future. It is also a good idea to include a void pointer to opaque data, which allows for arbitrary state during callbacks. You might even be able to remove some of your parameters if you are including them "just in case".