John,

You have crossposted (nothing wrong with) however I think that you be better
of with crossposting this to a language newsgroup too, because we don't know
what program language you are using now.

The two largest developer newsgroups of Microsoft are beside Excel.developer
and ASPNET

microsoft.public.dotnet.csharp
and
microsoft.public.dotnet.languages.vb

At least when you post to the two newsgroups that you are posting now, tell
us than what program language you use.

I hope this helps,

Cor

Reflection doesn't have to be slow. You can't get rid of the overhead, but
if you code it correctly it can be quite fast.

Return an object and unbox it (if applicable) after the delegate returns.
This will have less overhead than reflection.

Or, if you can resolve the actual type of the value being parsed you can
create a sort of generic converter function using Convert.ChangeType:

public object TryParse(object /* string */ val, System.Type type) {
   try {
       return Convert.ChangeType(val, type);
   }
   catch {
       return null;
   }
}

And call it like:

string s = "3.41";
double d = (double) TryParse(s, System.Double);

John,

I thought that Paul was more active in some other newsgroups the last time.

However I see he is it here as well.

See what he wrote about your problem in this newsgroup.
http://groups-beta.google.com/group/microsoft.public.dotnet.general/msg/a7c29549
7ae67bf4?hl=en&

I am not so familiar with those Ini files so maybe you can search for that
when the message from Paul is not sufficient enough or wait until he sees
this. Your subject is however not one that in my opinion gets direct the eye
from Paul.

I hope this helps,

Cor

Your problem is easily handled using the decorator pattern with a builder
pattern to construct the parsing.  Observer pattern can be used, but is not
terribly efficient.  Switch statements are not needed in the parsing, but
may be needed in the builder.

Take at look at the builder pattern and the decorator pattern by googling
these names.  They are standard OO patterns from the Gang of Four (GoF).

Let me know if you want help implementing them.

John,
In addition to the other comments.

My first choice would be Convert.ChangeType as Klaus shows.

My second choice would be an Adapter pattern, similar to your array of
Wrapper Delegates. In addition to using Delegates as you did, I would
consider using a series of classes that implemented an interface or shared a
common base class.

Something like:

   Public Interface IConverter

       Function Parse(ByVal s As String) As Object

   End Interface

   Public Class DoubleConverter
       Implements IConverter

       Public Function Parse(ByVal s As String) As Object Implements
IConverter.Parse
           Return Double.Parse(s)
       End Function

   End Class

   Public Class ConverterCollection
       Inherits DictionaryBase

       Public Sub Add(ByVal type As Type, ByVal converter As IConverter)
           MyBase.InnerHashtable.Add(type, converter)
       End Sub

       Default Public ReadOnly Property Item(ByVal type As Type) As
IConverter
           Get
               Return DirectCast(MyBase.InnerHashtable.Item(type),
IConverter)
           End Get
       End Property

   End Class

   Public Shared Sub Main()
       Dim converters As New ConverterCollection
       converters.Add(GetType(Double), New DoubleConverter)

   End Sub

The disadvantage of the interface/class method is the proliferation of
classes. The advantage of the delegate method is the elimination of all the
classes...

As to performance: Remember the 80/20 rule. That is 80% of the execution
time of your program is spent in 20% of your code. I will optimize (worry
about performance, memory consumption) the 20% once that 20% has been
identified & proven to be a performance problem via profiling (CLR Profiler
is one profiling tool).

For info on the 80/20 rule & optimizing only the 20% see Martin Fowler's
article "Yet Another Optimization Article" at
http://martinfowler.com/ieeeSoftware/yetOptimization.pdf

Hope this helps
Jay