[Dune] ParameterTree

[Carsten Gräser]

Am 28.01.2011 01:27, schrieb Jö Fahlke:
> Am Fri, 28. Jan 2011, 00:50:28 +0100 schrieb Carsten Gräser:
>> Dear Dune,
>> for for historical reasons ParameterTree contains
>>
>>   int    ParameterTree::get(const string& key, int default);
>>   double ParameterTree::get(const string& key, double default);
>>
>> and the new methods with template parameter
>>
>>   template<class T>
>>   T ParameterTree::get(const string& key, const T& default);
>>
>> IMHO we should removed the non-template methods since for
>> key=0.1 you have the really ugly behaviour
>>
>>   get("key", 1.0) == 0.1
>>   get("key", 1)   == 0
>>
>> due to the internal usage of atoi(). With the newer template methods
>> you get an exception in this case since they use streams for conversion.
> 
> Seconded.  We should probably drop the overload for std::string as well (but
> we should keep the one for char*).
> 
>> However the essential problem persists since the implicitly derived
>> conversion type might not be what you expected. For example for key=1
>> you have
>>
>>   char defaultValue=0;
>>   get<int>("key", defaultValue) == 1
>>   get     ("key", defaultValue) == 49
>>
>> In order to avoid this I suggest to forbid implicit determination
>> of the template argument using
>>
>>   template<class T>
>>   struct DefaultType
>>   { typedef T type };
>>
>>   template<class T>
>>   T ParameterTree::get(const string& key, const DefaultType<T>::type& default);
> 
> Objection.
> 
> I always understood the implicit determination of the conversion type as the
> official way to select the particular overload of the get()-method with
> default parameter, and I'm using it extensively.  The simple fact that these
Indeed this was what I originally intended. However it does not do what you
naturally expect: Select the type of the return value. Instead it selects
the typ of the expression that might be different.

> methods were sometimes implemented as overloads made this the only reliable
> way.  I consider The fact that most of these overloads are provided by a
> method template an implementation detail.
In my opinion it provides a natural way to select a type: using a template parameter.

> Instead I propose specialize the ParameterTree::Parser struct for char to read
> a numerical value instead of a character.
You might also want the character depending on your application.
The main reason to forbid the implicit type determination is that
similar unexpected behaviour might appear if the user defines the
conversion for custom types.

Best,
Carsten

> 
> Bye,
> Jö.