If you're looking for speed, I recommend LZ4 (http://en.wikipedia.org/wiki/LZ4_(compression_algorithm)), if you're looking for high compression LZMA is pretty much the best freely available algorithm (as stated above). If you want a good trade off between those, zlib is still pretty competitive.
If WinRAR is faster than your LZ77 implementation, then your LZ77 implementation is very very slow.
In your case, all the pointers point to a const object, meaning you can't change the object through that pointer. You can, however, have the pointer point somewhere else, as is evident from the assignment of mD3dscene.
If you want the pointer itself const, you have to put a const after the *.
Examples: int * ptr; // non const pointer to non const object const int * ptr; // non const pointer to const object int const * ptr; // non const pointer to const object (same as above) int * const ptr = something; // const pointer to non const object const int * const ptr = something; // const pointer to const object int const * const ptr = something; // const pointer to const object (same as above)
I think these are all cases and I hope that helps!
Posted by Rattenhirn
on 23 February 2014 - 05:55 AM
data compression means to move data from the space dimension to the time dimension...
From Wikipedia: "Lossless compression reduces bits by identifying and eliminating statistical redundancy."
So nothing is moved between dimensions, whatever that might even mean in this case.
Maybe you try to space/time trade offs that are often the case with CS algorithms, including compression. For instance, a better compression rate will typically take a longer time. So by spending more time working on the data one can save space or, vice versa, by using more space, one can cut down the processing time.
Firstly, many companies or teams do not distinguish sharply between gameplay programmers and other programmers. The skillsets overlap too much to make that a useful distinction anyways. It's rather an affinity towards certain kinds of problems.
Secondly, scripting languages are usually only available for very specifc domains. Like the GUI, AI scripting or cutscenes. And they are supposed to be used by non-programmers. The reason you can script everything in engines like UDK and Unity is that they do not like giving out the source code or native APIs, making scripting pretty much the only option.
Thirdly, there's nothing wrong with knowing C++. I'd say, it's probably one of the most useful programming languages to know, even if you don't use it, as it gives a lot of insight into how programming languages do things and what the costs of certain features are.
Hello all, been a while, I'm working on this project for a university assignment and I would really like
delegates in C++ haha, so I came up with something in a side test project and I'm pretty sure its
evil, could someone explain to me what could happen if it is in fact evil (ignoring the usual errors that could happen)
Delegates per se are not evil. There are plenty of implementations out there, with various pros and cons.
Your particular implementation has a pretty nasty fault, that's also very easy to spot: The c-style cast to "handler_t". Pretty much anything can happen at that point. From compiler errors to obvious runtime errors to subtle runtime errors.
As a general rule, when programming C++, stick to static_cast and dynamic_cast. When interfacing with legacy code or low level, use reinterpret_cast and const_cast. Never ever use c-style cast, especially if you only put it in there to shut the compiler up.
When new-ing an array of non-PODs, the compiler needs to store how many elements are in that array, so that it know how many destructors to call on delete. This value is often stored in memory before the array. By extension, this also means that it will allocate a bit more memory than N times sizeof(element), so your original placement new might write over the end of your buffer.
This behaviour is compiler specific, the best advice is to stay away from placement new for non-pod arrays!
If you can't do that, you may need to adapt your implementation for each compiler, so it might be easier to use a vector with a custom allocator.