You probably want to switch to inherited classes. Either way, you're going to need to return a pointer instead of the struct itself. First, you'll probably want some way to tell which one is returned, so you should add an integer called type or something first in your structs. Then, make a third struct, called simply XMLReturn or something, that contains only the type variable. Have your function return a pointer of that type, and then just, return whichever struct you allocate normally. You can read the type of your XMLReturn variable and decide what to cast it back to.

struct typea
int type
String something

Struct typeb
int type
float somenumber

Struct basetype
int type

basetype* function
if something
typea *ret=malloc(typea) ;
ret.type=1
return ret


basetype *xml=function ()
if xml.type=1
typea *a=(typea*) xml

That looks incredibly messy and like the equivalent of constantly abusing dynamic_casts in C++ to check types. It seems like conceptual nonsense to be "deriving" unrelated things like Person and Errors from one base and introduce the mess of dynamically allocating/deallocating objects (especially after all the wild brute force casting) to implement the misguided idea of a single function returning completely different types of objects. Sometimes the question isn't "how can I do this", but "why on earth would I WANT to do this".

Either do what tons of C libraries do and have functions always return an error code while using an output parameter for your data, which will look like this


Person person;
Error error = parseXML(xml, &person);



or return a (well defined) dummy Person on error and set a global error object (C typically does both, with functions returning -1 on error and additionally setting the global error number, a completely separate function will then map error codes to error strings). Of course a global error has other problems of its own (not thread safe, the next call might overwrite your previous error, etc.)

In C++ you could use exceptions for errors, which makes some things very convenient (if your calls go through several levels, you don't have a dozen places to do error checking), but also a little messy (you need to learn writing exception safe code and all the try/catch can go a little out of hand).

Make a function to get the type of the data and then call geterror or getplayer, whichever is the right one, passing them the xml already parsed by the gettype thing hopefully (figure out better names for them)

What you are after is a factory pattern and most of those in C++ require RTTI in some way or other. I use class registrars to collect the creation functions at compile time to create objects from a factory http://code.google.c...sRegistration.h, http://code.google.com/p/dxengine/source/browse/trunk/src/RTTI.h, http://code.google.com/p/dxengine/source/browse/trunk/src/RTTIMacros.inl. But I think you can do this with a templated factory as well http://stackoverflow...ry-pattern-in-c

One idea is to return a tuple of optional Person, Error:

template<typename T>
struct ParseResult {
boost::optional<T> success;
boost::optional<Error> error;

ParseResult(const T &success) {
// ...
}

ParseResult(const Error &error) {
// ...
}
};

The caller can inspect the optional values to determine which value was returned. A more generalised version of this is boost::variant, or in extreme cases boost::any. I'm not aware of these types being included in C++0x.

If the file contains many objects, the above could be two containers:


template<typename T>
struct ParseResults {
std::vector<T> successes;
std::vector<Error> errors;
};

If the order is important (e.g. parsing a list of elements and you want to correlate errors with particular entries) then you can store the index in the vectors too.