hashtable with irregular values, casting

C

cate

.... ht = new Hashtable()
{
{"op1", (string)""},
{"op2", new Hashtable()}
}

When I access this hash, the compiler requires I cast it. Why?
Didn't I just define it?

This is required

string s = (string)ht["op1"];

where I would think the following would suffice. (it doesn't)

string s = ht["op1"];

Is this requirement to cast correct or do I have something else going
on? Thank you.
 
A

Alberto Poblacion

cate said:
... ht = new Hashtable()
{
{"op1", (string)""},
{"op2", new Hashtable()}
}

When I access this hash, the compiler requires I cast it. Why?
Didn't I just define it?

This is required

string s = (string)ht["op1"];

where I would think the following would suffice. (it doesn't)

string s = ht["op1"];

Is this requirement to cast correct or do I have something else going
on? Thank you.

Yes, you do need the cast. ht["something"] returns an Object. At compile
time, it is not possible to know the type of the object, because at runtime
you can add or remove different things to the hashtable, so the compiler
can't know the type of the object stored there. If _you_ know the type, you
inform the compiler by means of the cast. Otherwise, the compiler doesn't
know whether there is a conversion to the target type. Since C# is a
strongly-typed language, requiring that all conversions be specified at
compile time, you have to write the conversion (cast) whenever the compiler
can't deduce it by itself.
 
P

Peter Duniho

cate said:
.... ht = new Hashtable()
{
{"op1", (string)""},
{"op2", new Hashtable()}
}

When I access this hash, the compiler requires I cast it. Why?
Didn't I just define it?

This is required

string s = (string)ht["op1"];

where I would think the following would suffice. (it doesn't)

string s = ht["op1"];

Is this requirement to cast correct or do I have something else going
on? Thank you.

As Alberto points out, yes…for that type (System.Collections.Hashtable),
the cast is required.

Note, however, that there is (since .NET 2.0) generics and the
System.Collections.Generic namespace. In there, you will find the
Dictionary<TKey, TValue> class, with which you can declare the actual
types used by the hashtable dictionary, which in turn allows the
dictionary members to be strongly typed, avoiding the need for casting.

Pete
 
A

Arne Vajhøj

... ht = new Hashtable()
{
{"op1", (string)""},
{"op2", new Hashtable()}
}

When I access this hash, the compiler requires I cast it. Why?
Didn't I just define it?

This is required

string s = (string)ht["op1"];

where I would think the following would suffice. (it doesn't)

string s = ht["op1"];

Is this requirement to cast correct or do I have something else going
on?

C# is a relative strong typed language. The compiler tries
to check the assignment. When assigning an object to a string
an explicit cast is necessary, because by doing that you tell
the compile "I know this is a string". If you lied to the compiler,
then you get an exception at runtime.

The string cast on "" is completely unnecessary though. It does
not provide any value at all.

Arne
 
A

Arne Vajhøj

cate said:
.... ht = new Hashtable()
{
{"op1", (string)""},
{"op2", new Hashtable()}
}

When I access this hash, the compiler requires I cast it. Why?
Didn't I just define it?

This is required

string s = (string)ht["op1"];

where I would think the following would suffice. (it doesn't)

string s = ht["op1"];

Is this requirement to cast correct or do I have something else going
on? Thank you.

As Alberto points out, yes…for that type (System.Collections.Hashtable),
the cast is required.

Note, however, that there is (since .NET 2.0) generics and the
System.Collections.Generic namespace. In there, you will find the
Dictionary<TKey, TValue> class, with which you can declare the actual
types used by the hashtable dictionary, which in turn allows the
dictionary members to be strongly typed, avoiding the need for casting.

It would not work in this case, because the type of the two values
are different.

Arne
 
P

Peter Duniho

Arne said:
[...]
It would not work in this case, because the type of the two values
are different.

Well, sort of. The original code is pretty awful in conception, so IMHO
using the generic class should guide the OP toward a better design.

Even Dictionary<string, object> is better than using Hashtable, even if
it does still wind up requiring casting for some things.

Pete
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top