Writing Application "Drivers"

[Peter Duniho]

For things like this, I generally prefer a table. Of course, my
background is in C++ where tables can be EXTREMELY efficient for things
like this, while C# can be very different.

I'm not sure what you mean by "table". If you're just referring to an
array, they are about as efficient in C# as in C++, and I wouldn't say
they are especially more efficient as compared to other data structures,
as long as those other data structures are in fact used in an efficient way.

Efficiency has a lot to do with context. An array is a pretty
inefficient way to store data if you need random access via something
other than an integer index into the array, and is very efficient if
accessing by integer index is the only expected usage. It just depends.

By the way, modern C++ compilers do a very effective job optimizing
"switch" statements as well. Don't be afraid of them.

I like this a lot, and I'll just take your word for it that it would be
much faster than Activator.CreateInstance().

Well, you don't have to take my word for it (and in fact, I encourage
you not to). You can implement it each way, and then benchmark each
implementation.

Of course, even if you find a difference in the benchmark, if your own
runtime usage isn't like the benchmark, the performance difference may
not matter. This is another "it depends". Benchmarks generally are
written to exercise a particular piece of code repeatedly over a large
number of iterations, for long enough that performance differences are
magnified enough to see them.

But if your code only calls this kind of thing once every five minutes,
you'll never ever notice the difference in the real world.

Of course, it's my opinion that there are other reasons than performance
to avoid reflection whenever possible. But if that's your only reason
for avoiding reflection, and you prefer it for some other reason, the
raw performance difference won't tell you the whole story.

While I enjoy static tables where the data is initialized in the EXE
image, C# doesn't really support that anyway.

Not exactly. But note that in C++, except for simple data structures,
they are initialized in very much the same way C# data structures are.
If you declare an array of ints in C++, then sure...the compiler can
generate an actual block of integers to be embedded into the executable
image. But if you've got an array of class instances with a non-trivial
constructor, then C++ still has to go through the same kind of static
initialization C# would do.

And so calling the Add
method to build the collection would not appear to be a disadvantage.

Note that if you really want to, you can embed your dictionary data into
a serialized block of data, and the deserialize it at runtime. The data
can be stored, for example, in your executable's resources.

More overhead, but simpler code.

Another alternative would be to initialize the dictionary from an array
of KeyValuePairs. You'd still need a loop, but at least you'd only have
to write the call to Add() once.

Pete

 

[Peter Duniho]

Ugh. Did I really write "Affilied"? I guess I did. Sorry.

I'm definitely liking this. However, I can't seem to get this syntax to
work for me.

I tried adding a type cast like this:

AffiliateTypes.Add("RegNow", () => return (AffiliateFeed)new
AffililiateFeedRegNow());

Did you write "Affililiate" just to make me feel better about my own
typo?

But the compiler still complains that I have an invalid argument.

Sorry again. I should have included my usual disclaimer about not
having compiled, never mind tested the code.

A simple lambda expression like that is not allowed to include a
"return" statement, contrary to what I actually wrote. The cast is not
actually required, if you fix the lambda expression by removing the
"return".

The line of code really should look like this:

AffiliateTypes.Add("RegNow", () => new AffiliateFeedRegNow());

The compiler will infer the correct return type from the context. You
should not need to cast the result to make it work.

Pete

 

[Jonathan Wood]

I'm not sure what you mean by "table". If you're just referring to an
array, they are about as efficient in C# as in C++, and I wouldn't say
they are especially more efficient as compared to other data structures,
as long as those other data structures are in fact used in an efficient
way.

No, in C++ it's possible to declare very complex arrays that require zero
code at run time. C# seems to require run-time code to allocate the same
type of arrays.

By the way, modern C++ compilers do a very effective job optimizing
"switch" statements as well. Don't be afraid of them.

I use switch statements all the time. But I've been a developer since 1987
and let's just say I've developed a few preferences during that time, which
would require some very concrete and specific arguments before I'd give them
up.

Well, you don't have to take my word for it.

Thanks, but I already knew that.

Note that if you really want to, you can embed your dictionary data into a
serialized block of data, and the deserialize it at runtime. The data can
be stored, for example, in your executable's resources.

But I'd still need to build the collection at run time, so it wouldn't buy
me anything.

A simple lambda expression like that is not allowed to include a "return"
statement, contrary to what I actually wrote. The cast is not actually
required, if you fix the lambda expression by removing the "return".

The line of code really should look like this:

AffiliateTypes.Add("RegNow", () => new AffiliateFeedRegNow());

The compiler will infer the correct return type from the context. You
should not need to cast the result to make it work.

Yeah, that seems to be working well now. One thing I do like about C# is
some ways it can use delegates and lambda expressions, but I often find the
syntax confusing and sometimes elusive.

Thanks!

Jonathan

 

[Tim Roberts]

No, in C++ it's possible to declare very complex arrays that require zero
code at run time. C# seems to require run-time code to allocate the same
type of arrays.

That's true, but it's generally true in languages for garbage-collected
environments. C++ /clr only allows it for value types.

 

[Jonathan Wood]

That's true, but it's generally true in languages for garbage-collected
environments. C++ /clr only allows it for value types.

Right. My comments could've been more general to .NET languages. C# just
happens to be the .NET language that I use.

Jonathan

 

[Arne Vajhøj]

As I see it, inheritance provides a number of advantages over
interfaces. However, when you don't know where the object is coming
from, the decoupling you mentioned may outweigh those advantages.

You will be very disappointed if the next big language completely
drop implementation inheritance then (I consider that
a >66% probability).

Arne

 

[Arne Vajhøj]

No, in C++ it's possible to declare very complex arrays that require
zero code at run time. C# seems to require run-time code to allocate the
same type of arrays.

Will you app performance be ruined by a few microseconds spend on this?

If not, then you are fine.

I use switch statements all the time. But I've been a developer since
1987 and let's just say I've developed a few preferences during that
time, which would require some very concrete and specific arguments
before I'd give them up.

New language should lead to new preferences.

Very few things is as crippling for learning a new language
as sticking to the paradigms of an old language.

Arne

 

[Arne Vajhøj]

Thanks, this looks interesting. On closer inspection, I'm not sure it
makes good sense for my current task, but I could definitely see putting
this to use sometime.

It is pretty cool!

Arne

 

[Arne Vajhøj]

Do you need dynamic, run-time loading of the code? If so, then I think
the Add-In Framework is in fact a very good bet.

Only if he need some of all the other features provided by
the add-in framework.

If he just needs runtime loading of assembly, then add-in framework
will add a lot of unnecessary complexity.

Arne

 

[Arne Vajhøj]

I think that information has been provided, both in terms of the way one
used to have to do it (Assembly.Load(), etc.) and in terms of what .NET
supports today (Add-In Framework).

Add-in framework is not really a replacement for Assembly Load/LoadFrom.

It requires a lot of additional code and provides a lot of additional
functionality.

If the requirements is just to load an assembly with no isolation from
app, no dynamic version lookup, no special security etc. then Assembly
Load/LoadFrom is still the solution.

Add-in is great to replace various home-grown solutions on top of
Load/LoadFrom.

Arne

 

[Jonathan Wood]

You will be very disappointed if the next big language completely
drop implementation inheritance then (I consider that
a >66% probability).

I'll also be disappointed if they drop classes, but I'm not going to worry
about that right now.

Jonathan

 

[Jonathan Wood]

Will you app performance be ruined by a few microseconds spend on this?

If not, then you are fine.

Call me weird. But I think I'm the best one of us to determine the
importance of speed on my own apps.

New language should lead to new preferences.

Very few things is as crippling for learning a new language
as sticking to the paradigms of an old language.

There's nothing about any new paradigms that make data-driven code obsolete.
I'm not going to spend time explaining it. If you want to assume my ideas
are all outdated, go right ahead.

Jonathan