King Mir

You need to handle the case where there are no variatic arguements seperately. If that's not your problem, post you GameState constructors.

It looks like you need to think about your problem more, because I cannot see a useful application of what you're trying to do.

That said, the way to create a copy on the heap is this:

struct wheel
{
       wheel *copy;
       wheel() 
       {
              copy = new wheel(*this);
       }
       //also needs copy constructor, assignment, and destructor, to handel freeing correctly.
};

 
Even better you can use this:
 

#include<memory>
 
struct wheel
{
       std::shared_ptr<wheel> copy;
       wheel() 
       {
              copy.reset(new wheel(*this));
       }
       //copy constructor, assignment, and destructor not needed; free does not need to be called.
};

SiCrane is right to point out that you need to use std::move inside DoSomething.

The only time an lvalue reference binds an rvalue reference, is in when it's a deduced type, such as a template dependant type, an auto type, or an argument to decltype. Using declarations may also qualify. In these case the rvalue reference behaves as a universal reference, used for perfect forwarding. Whenever an lvalue is passed to such a type, the deduced type is an lvalue reference. In all other cases, the code will not compile.

Also note, the only reason strA cannot be used after it's moved, is because the library part of the standard says so. std::move does not by itself cause that. You could write a class which is safe to move then use.

T

Using prefixed member variables (e.g. m_) is useful for writing optimized code.
 
You may or may not know it, but all member variables alias other pointer variables (e.g. function arguments and other members) because of the implicit this-pointer. This affects code optimization and often leads to less optimal code because of redundant loads. Therefore I like all member variables to clearly stand out by using a prefix, so they aren't used in e.g. tight inner loops, but moved to a local variable first. Aliasing basically happens all over the place.
 
Google for "pointer aliasing", "strict aliasing rule", "type punning" and "restricted pointers" if you're interested.

That's something that the compiler should be able to optimize on its own. Accessing a member of a struct can trivially be proven not to alias with another member of the struct. Also, member variables will be moved to registers if they are used in tight inner loops, so there wouldn't be redundant loads.

I recommend jumping in and working on the game you want to make. Having a project to apply programming skills to and is useful to learning and provides motivation.

You can't go wrong with either C++ or Java as a primary language. C++ is the darling of the games industry whilst Java can be used for Android games.
 
However, if you are learning from scratch then its wise to leave alone OOP languages until you have the basics of structured programming nailed. Both C or JavaScript are ideal beginner languages and share almost identical basic syntax with both C++ and Java. Well, C and C++ are considered the same language but there are some differences beside the obvious use of OOP in C++...

This is bad advice, IMO. Firstly, because OOP is a good thing to learn early, so you should start with an OOP language. Secondly, because when learning C as a precursor to C++ there are a number of things that are common practice in c, that are bad practice in C++.

C and C++ are different languages, and not just because of OOP. Two big differences are how to write constants, and how to write generic code.

It looks like the creation of the postFix variable was the minimal change to make the code valid c++ (because of undefined behavior, like you mentioned). It's the stock way of breaking up an expression by replacing a part of the expression with a intermediate variable. Your alternative code is much cleaner.

Thanks for the prompt responses. What's the main differences between C# and C++?

A lot. C++ is a harder language to learn, the hardest out of all popular general purpose programing languages. But it is the top choice for writing fast programs, when that is the highest priority.

C# is a managed language, on par with Java. I recommend Python over both, but it's reasonably easy too. C# is a language developed by Microsoft, so is only preferred for Windows development, but that's not a small audience, especially for games. And while I said C++ is preferred for speed, C# is not by any means slow.

My usual advice for starting programming, is get a python book, and go from there. Your prior programming experience will help you, but I still recommend this path. You don't need to buy anything but the book, and even that can be found online for free.

 
My advice is to never ever touch python whilst it is really easy to pick up it is a pain to find why your thing isn't doing what it is supposed to (whitespace is a bad indentation indicator especially when tab and space are handled differently). You are better of starting with C# or Java both have additional libraries that allow you to make games with them.
Eclipse is free and a good IDE for Java development and for C# there are the Express editions of Visual Studio to work with. There are numerous tutorial sites out there that help with either language and the game development packages for them.

The language's choice of Line terminator and block syntax is a pretty lousy reason to avoid a popular language. Python has libraries for making games too. Pygame is especially good for beginners. Java and C# are good too, but for both a simple hello world program is littered with references to constructs that can only confuse a beginner. They aren't as beginner friendly. Meanwhile, python is beginner friendly, but not a beginner language in that it's suitable for writing large applications by experienced developers. The reason experts use python is that it's designed for rapid development, and when you're paid for how much your application can do, not how fast it runs, that can be a good choice.

But beginners benefit form rapid development too. Hugely. It means beginners can create working programs, with each feature learned, that much sooner. It means you can do more while knowing less, because the language does not force boilerplate on you that you could get wrong.

That's rather vague, but I'll give some comments about what I think of the language. It's mostly my opinions on language style.

• Semicolons are redundant to line ends in marking the end of a statement. For people reading, line ends are the more obvious signals that a statement is over, and a line not ending in a semicolon is likely a bug, unless the line wraps around. Therefore a language should just use line ends to mark the end of a statement.
• By a similar token, indentation is the primary indicator of a block for a person, so it's good if that's also what indicates a block to the language.
• AND behaves like multiplication and should have higher precedence than OR. This applies to both bitwise and logical operators. XOR and OR both behave like addition.
• Double precision floating point is used more than single precision. That's probably something you should know, and apply even outside the context of this project. At the least, add double precision floating point.
• C's syntax for declaring arrays is awkward because the type wraps around the variable. It's part of the reason why std::array was added to C++. Don't use it.

I really don't agree with your line end as ending a statement I want to be free to add layout to my code as I see fit and not as the langauges syntax sees fit.
Block constructs that are marked by tokes is far easier to read when the blocks start spanning 25> lines of code and after that you step back one indentation level. Also only using indentation doesn't allow you to mix tabs and spaces even though the indentation level looks the same. This has lost me quite a bit of time when writing python stuff sadly.

If you ever get a chance to read other people's Perl code, you'll get a better appreciation of language conventions. If you write code with a weird layout, your code is difficult to read. When the language prevents that, it's a service to programmers reading the code. Code intended for reading; and really all code is intended for reading, throwaway code is a myth; should properly indent every statement to the depth of the block it's in, which is always more than the previous block. Lines in the same block should be indented by the same amount, using either spaces or tabs and not a mix. Otherwise it makes your code look different to different developers, based on their editor settings. So again, it's a service to programmers reading your code that you're unable to do so. These are conventions that should be followed in any language, so when the language enforces it it only helps you.

And it means you never have to read about another missing semicolon when both you and your compiler know exactly what you intend.

By the way, Python actually does allow you to use braces and semicolons.

My usual advice for starting programming, is get a python book, and go from there. Your prior programming experience will help you, but I still recommend this path. You don't need to buy anything but the book, and even that can be found online for free.

If the tasks you do in parallell has no dependencies on each other, you might get close to NumberOfThreads times the performance, but a game engine states is by its nature quite dependent on each other, having lots of requirements on what needs to be done before what, and is very tricky to multithread in an efficient way.

Slight nitpick: The speedup potential of parallel threads approaches the number of cores, not the number of threads.

Any language that has has the ability to execute an arbitrary string as code needs to have an interpreter, and those are the languages that use interpreters as the primary launch point. You could compile such a language in principle, any code using the "exec" functionality would need to compile in an interpreter. Especially problematic are cases where exec is used commonly, such as when implementing exceptions in perl.

Similarly languages that provide a runtime interface to the implementation of the abstract machine, like java's ClassLoader, is difficult to make work when the language is not implemented as designed. It's essentially the same issue; the language specifies how code is loaded at runtime, including code that doesn't need to be loaded at runtime. So it's difficult to write a conforming compiled implementation that acts like an interpreted implementation.


However, these days interpreters usually compile critical parts of the execution during the course of a run, using a JIT. They aren't pure interpreters.


Compiled languages have no problem being interpreted, and indeed interpreters do exist for traditionally compiled languages. Having an interpreter provides rapid startup, which can speed up development.

If they are just proportional codes, and there aren't that many, you might just forget the database and hard-code your redeem codes in your server scripts.

There are also be some tools for this built in to banking tools, like Google Checkout. That would be my first choice, if it's suitable to your use.

I think a good elementary use for multi threading is when you have a GUI that launches a background task. That's a fairly widely applicable kind of multi-threading. It comes up less often in simple games though, because they tend to need every calculation in every frame, so they just alternate between computing tasks, and drawing to the screen in a single thread.

In general, multi-threading is a way to achieve speedup, so it's not strictly necessary.

The best way to learn multi-threading is probably a book or course. There are a number of techniques that are used and which one is the best varies depending on your application, so you need to know all the tools in order to figure out how to parallelize a particular program. Unfortunately, in my experience courses have not been very comprehensive either, and I cannot recommend a good book.