I have a simulation that stores values set while running in the form of a "Profile" template container into a "State" class. At the moment there are 5 types of values that could be set to the State (Matrix, Quaternion, double, int, bool). A Profile is a list< pair<double, T> > (where the double is the time, and the T is the value), and a State is one map for each type in the form of map<string, Profile<XXX> > (where the string is the variable name and the Profile is previously defined). When the user wants to get a value from the State at a later time, right now he must call state.getDoubleAtTime(double time, string varname), or state.getLastInt(varname), or one of many type specific calls (3 different calls for each type). I _ASSERTE'd the heck out of the calls to inform the user when they are asking for a value in the wrong type from the type that the string was set to, but that's just in debug mode. I still have to have a return value for those functions for when they actually call it in release, and those values are all null. However, the user might not know this, and inadvertantly use the wrong values which is not an acceptible solution. I think this falls into the just-in-time compiling vs compile-time type checking, so that in C++ I'm pretty sure I can't specify the return from one of those functions as <T>, and let it find the right value... Is there a way to get around this that doesnt have bad bad consequences?

Quote:Original post by chaospilot
I think this falls into the just-in-time compiling vs compile-time type checking, so that in C++ I'm pretty sure I can't specify the return from one of those functions as <T>, and let it find the right value...

no. it get's into good ol'fashion error checking:



when it returns false you modify your form to display an in-line error message: "that input was not a number".

good GUI programming == lots of if checks to validate the user's data. You also want to be sure that you leave the user-entered values in the form fields so it's easier for them to fix a typo. The only exception would be online website forms where you cannot store the CC number anywhere on your system.

asserts should _never_ be used to verify user input. they should be used to find programming logic problems; users don't obey logic.

asserts crash a program. you never want a released program to crash. therefore, if you hit an assert you have a bug that needs to be fixed before anyone uses your program.

-me

Hummm, I dont think I explained myself clearly enough. The user is going to write simple C++ code to define some functionality of the thing we are simulating. Then he is going to compile his code and throw in some input files and set it running for a few days. (I'm building a simulation framework that will be modified for further use by the customer). If at any time is operating on invalid data (whether we are cout'ing "Invalid data type referenced, returning null values." or not the simulation is a bust.

Is there any way to return a type T, or keep Profile<T>'s of multiple types in the same map and specify the return type during runtime?

Like having the user make a call to the getStateValue(variablename) that returns a type T profile where the type is defined when the variable is looked up?

No i don't think there is but I'm sure you could construct something that would do what you want. Off the top of my head:



However, I think that's the wrong approach. You should have code built in that checks the code that the user writes to guarantee that these crashy edge cases will never happen.

If the text input is bad that also can be handled with a pre-process pass over the data to ensure proper formatting and such.

If the data is well constructed and your app well designed their code should never be allowed to generate the errors. If the data is mal-formatted your app should be able to tell and let them know before anything gets executed.

If I'm still not understanding perhaps you could post a specific example of a data-set and the code that the user would write.

-me

I think what you are talking about is our last implementation a "StateVar" container, which was saving variables as a container with a type and empty data variables for EACH type. Then when you set it, it would set it's type and the data in that member type to the correct data, and all other data would be set to zeros. But you could still try and read the wrong data from that StateVar without generating a compile time error (just a cout warning). Can you manually generate compile-time errors?

//My simplified example is someone setting data via:
double timeIn= 23.4;
double doubleIn = 9.3490581;
Profile<double> doubleProfIn(make_pair(timeIn, doubleIn));
State newState;
newState.setValue("ImportantDoubleToSave", doubleProfIn);

//Then reading the wrong data via:
int importantValue = newState.getLastInt("ImportantDoubleToSave");

This would generate a debug ASSERT error now(but you said that wasn't a good idea). But in release mode, it would just cout an error message from the state when it checks its map of int profiles and sees no key equal to that. Since we have to return a value, it would return NULL (which is significantly different than 9.3490581).

More explanation.. The state get() check does a key find in the map where the key is the variable name. However, there are multiple maps (one for each Profile template type since you can't mix different template types in one map *I think*). So, when the find by key returns the end iterator, we can't look in the other containers, because we're already committed to returning the type the user is asking for (which could be int when the data is a Matrix). How can we generate compile-time errors when the user is setting a (string,double) to the map and then asking for a Matrix with the correct string?

I'm really tired and inattentive at the moment, but it sounds like boost::any and/or boost::variant might be relevant?

I looked at the boost libraries and saw things for conversions between single types, but all the return types were the same. I think the problem is more fundamental. You can't define return types at run-time with key lookups on strings in a number of maps. That said, however, I think if we forced the user to create all variable names through a template Key<T>(string Varname) in the same area and under penalty of death disallowed them from creating Keys on the fly in their code... then unless an idiot declared two keys at the top with identical variable names then it should be fine... that is...

class Subsystem
{
Subsystem();

~Subsystem();

void doSomethingFunction(const State& oldState, State& newState)
{
// USER - INSTANTIATE KEYS HERE
VarNameKey<double> XPositionKey("PositionX");
VarNameKey<Matrix> PositionKeyX("PositionX");
// USER - END KEY INSTANTIATION

pair<double, double> xPos = oldState.getValue(XPositionKey); // GOOD AND CORRECT
pair<double, Matrix> xPos = newState.getValue(XPositionKey); // BAD AND COMPILE TIME FOUND
pair<double, Matrix> xPos = newState.getValue(PositionKeyX); // BAD AND UNFOUND BUT REALLY STUPID (WILL RETURN NULL MATRIX)

double oldTime = xPos.first;
double oldX = xPos.second;

double newTime = oldTime + 2;
double newX = oldX * 2;

Profile<double> doubleProfIn(make_pair(newTime, newX));
newState.setValue(XPositionKey, doubleProfIn);
}
}