Thanks for all the answers!
If you can use C++11, you could use variadic templates and std::forward your arguments to constructor. If you can't you can still template arguments, though it will be a bit more work (you have to define templates for all possible numbers of arguments, or use some macro magic - with variadic templates its just one line of code).
The varidic templates definitily sounded interesting, but unfortunately they are not supported by Visual Studio 2012... If I were to write templates for all the possible number of arguments given, would I also need to overload the function for each of these templates (Arguments1<>, Arguments2<>, ...) or is there some way to templatize (is this a word) the templates so that I can have "Component::Component(Arguments args)" for me to pass as many arguments as I want?
And I don't think there is anything wrong with constructing component object outside and attaching it to entity - you may want to do some sort of pre-processing and set various information so why not do it this way? As long as you have clear state of ownership of such component it won't be a problem.
I'll pick that approach if I fail to implement something else, yet I still prefer the more "automated" approach since I've already got a pretty interface around it using a string to identify the component...
The approach I have used before (and currently use, though in a language like Lua it is very easy to do, given the dynamically-typed nature of the language) is to use some sort of variant class. A variant is a data object that can hold anything. (within reason). That is, something like boost::any. Typically, I'll write my variants to be more specific than boost::any, though. For the argument list, I pass a map keyed on string of variant properties.
Sounds interesting too, is there any guide/tutorial or sample code on how to implement a variant? I googled a bit but didn't find anything related to my problem.
As for the file format, thats not really what I am looking for right now, I'll consider it some other time, but for beginning I think I'll stay code only.
You could also pass in a map object. The map object would contain all required inputs and the initialize function would just read the map object for the values it needs.
Only problem is that the arguments need to be of different type - one (Model) might need a pointer to my RenderQueue, and Material-ID and a Filename, the other one (ParticleEmitter) might want itself a map of force-fields, and a bunch of parameters regarding the particle generation/handling. A map with variant types would do, but simple a map isn't the solution...
See example in the EntityXlibrary how this can be done. It is C++11 based on variadic template arguments, which is a little difficult. But it also supports that you construct the component first, and then attach it.
Pretty cool, I'll have a closer look to see how they implemented it (though like I said, variadic templates aren't an option for me, unfortunately). Speaking of which, in your example, they define components like Position and Direction. I though more about having something like a WorldComponent, RenderComponent, PhysicsComponent ... Therefore, I would also apply logic to the components, and not rely completely on systems like EntityX does. From what I've read some people tend to use components just as data containers, while others prefer more components with more logic like I wanted to have. Is there any huge advantage/disadvantage from any of those approaches or is it more a thing of preferrence? What would you recommend me to do starting out?