You declared functions modify, initialize, show and free in CGameApp, but you never defined them, which could be the cause for your error. Either provide a definition, or declare them as pure virtual using the following syntax :
The web (as in HTTP + HTML) is just a specific kind of client/server model, with its own benefits and drawbacks, which may or may not apply to the project you are dealing with.
For instance, HTTP is a pull-only stateless protocol, which is both a benefit (you can handle more clients per server, and you can spread the load across multiple servers) and a drawback (the server cannot initiate communication with the client, every request must carry all necessary state information). So, it would be a great choice for a game that involves millions of low-bandwidth clients, and a bad choice for games with a handful of high-bandwidth users.
The web does have the benefit of being fairly platform-independent and requiring no software download (although you can achieve this with a client/server model using Flash or Java, too), but you will be limited in terms of rendering power. Presenting static dialogs and forms, along with simple 2D graphics and animations, is possible, but anything more complex than that (including, say, playing sounds) is going to require specific software on the client side.
To be able to tell more, we would need more information about your project.
Original post by shurcool What function would you recommend to use instead?
As you might have guessed, the issue here is that GetNextFloat involves a subtle side-effect that is easy to miss - despite being called 'Get', the 'Next' part involves a change in the underlying stream object.
The solution is to make this side-effect obvious. In a functional language, you would simulate the side-effect by having GetNextFloat return a pair composed of the float and the remaining data in the stream. This way, you can't get the float without noticing that a stream was also returned. Of course, this requires a proper implementation of streams as immutable lazy linked lists, which is too complex for weak languages like C++ to handle elegantly.
The C++ solution follows this idea but gives up on immutability: stream operations return the modified stream, which means that if you need to access the read value, you need to add a variable access and unless you're deep into code obfuscation, you'll use a distinct statement (solving the problem). Still, streams are not immutable, which means that the original stream is also modified (and thus, returned for optimization purposes) which means that stream reading remains vulnerable to exceptions (an exception does not "roll back" the read data back into the stream).
In short, that line of code (at least in C++) should have been:
float x, y, z; fileStream >> x >> y >> z; // operator precedence constrains order of evaluation vertices[vertl].mLocation = KMath::CVector3(x,y,z);