   problem with default construction of templated type
  I have a template class that is basically a policy class that looks like this:template<typename V>struct PropValueCreator {    V create() {   V value;   return value;    }};Now this particular instantiation is meant to be used with primitive types and std::strings. In the case of std::strings everything works fine because strings have a default constructor. However, in the case of int or short, etc., it produces warnings because these types don't have default constructors. As it turns out, the usage is completely valid because I don't care about what value is being returned. What I care about is the type -- it's going to initialize a boost::variant -- so the code works correctly, but obviously I don't want the warnings. So how can I return a value of type V, where V could be an int or an std::string, and not produce a "you're using an uninitialized variable" warning? I could make a separate policy instantiation for int types but I have a feeling that there's some way of massaging the above.   
V create() { return V(); }If you don't want warnings, you pretty much have to (zero-)initialize primitive types.However, if you don't need a value at all, I don't see why you have a function to return one. You know the type (V), why don't you use that directly?   ;  Thanks. I just tried it and getting rid of the temp variable as you did above gets rid of the warning under VS 2008. Couldn't I also doreturn V(0);since in the string case std::string(0) is valid?   ;  string(0) may compile, but that isn't the same as being valid.   ;Quote:Original post by SiCranestring(0) may compile, but that isn't the same as being valid.I thought in that case it would use the constructor string::string(const char*) or can I not count on default conversion from 0 to const char*? Anyway, it doesn't matter: I'll just use two policies that do something less sketchy.   ;  Yes, it would use that constructor, but the result of passing NULL to it is undefined (e.g GCC throws exception, other implementation might just crash). Empty set of parenthesis is the way to go to get a default-constructed / zero-initialized value.   ;  You could avoid the warnings by providing explicit specialisations for built-in types.   ;Quote:Original post by iMalcYou could avoid the warnings by providing explicit specialisations for built-in types.Yeah, you can set V values to zero (valid for all primitive types) and specialise the string case. Shame that string crashes (null pointer error) when you construct it with zero. But if string is the only non-primitive type you're using, you'll still only need two copies of the function.   ;Quote:However, if you don't need a value at all, I don't see why you have a function to return one. You know the type (V), why don't you use that directly?This is a sort of degenerate case needed to handle strings and primitive types, which is why I wanted it to handle both i.e. it seems better to have one edge case than two. Other versions of the policy class actually do create things that are specific to the application.Anyway, I decided to just do a specialized verson for strings, as people suggested upthread.[Edited by - jwezorek on May 7, 2010 10:11:41 AM]