FreeGameDev

I see a lot of stream operators (operator>>) in the code that "replace" the ctor: Have an empty ctor and stream all the data into the object, like this

{l Code}: {l Select All Code}

Obj* foo = new Obj;
stream >> foo;


I don't like these kind of constructions for non-"string-like" objects. Looks rather bug-catchy and overly complicated to me. The other way round (operator<<) is logical of course, to easily generate a string that describes the object.

Are there any good reasons and best practices to do it this way? Wouldn't it be better to use default constructors? Ctors that provide default values so that they can be used empty or alternatively with all parameters. Then stream into variables and call the ctor with these variables. One big advantage here is that IDE's, compilers and static analysers report mistakes here (e.g. forgetting to set a variable or setting in wrong order). But when moving the construction task to streams you don't have this feature.
And after all, in most cases we have to stream into variables first anyway instread of directly into the object: when the values need to go through functions (setters, parsers or modifiers or something).

Another problem I see here is the possible "re-streaming" of existing objects (not sure if this actually done currently somewhere in our code) instead of a proper destruction and re-construction. This cancels out all the object-orientation, if it's possible to avoid the c/dtors and just re-assign new values.

Problem number three is the complexity. IMHO it's confusing if you only see:

{l Code}: {l Select All Code}

stream >> a >> b >> c >> d;

There's also the IDE's autocompletion missing: If you call the constructor it tells you what it needs, this is not possible for streams.

Any opinions here? Maybe I'm just not seeing the big advantage of the stream method.

I think it makes sense with the current sequential level format . But I would be okay with either method, as long as we are consistent. (Unless they are used for anything else than loading from map/console/network.)
Maybe it would be more logical to construct the objects from a string, e.g:

{l Code}: {l Select All Code}

std::getline(stream, string);
list.push_back(new Object(string));


For the creature definitions it won't make sends to use a stream once they are put in XML files. (And potentially other objects if we start splitting this up more later.)
I suppose we might want to make the map format more flexible at a later stage, if the map files are not sequential, then the streams won't make as much sense.

I like the construct-by-string method you suggested very much. But if we later switch to XML files and normal constructors anyway it won't make sense to change it now to this string way first, I think.

With this is mind I think it's best to leave it as it is now and switch to "normal" constructors after we have the new file formats.