Roll your own std::vector ???

[Jon Skeet [C# MVP]]

It would still seem like far less than the best possible design of all possible
designs. It still seems like run-time overhead that could have been done at
compile-time.

I strongly suggest that you wait until you've got a bit more experience
with the type system as a whole before passing judgements like that.
Considering you were still unsure about the differences between value
types and reference types until a few days ago (at least, so this
thread suggests) you're not in an ideal situation to comment on design
decisions.

In particular, you've been convinced before now that the
boxing/unboxing overhead was prohibitively expensive due to a benchmark
which actually demonstrated nothing of the kind.

The actual overhead involved due to boxing and unboxing in most .NET
applications is miniscule, but the advantages provided by it in terms
of type unification are very great.

Jon

 

[Joanna Carter [TeamB]]

"Peter Olcott" <[email protected]> a écrit dans le message de [email protected]...

| > If you call (for instance) myInt.ToString() then boxing isn't involved.

My apologies, I assumed boxing occurred here.

| It would still seem like far less than the best possible design of all
possible
| designs. It still seems like run-time overhead that could have been done
at
| compile-time.

Rathermore, it is usually down to developer laziness, using object
parameters to methods where strictly typed methods would be more efficient


Many times, developers, wanting to do the same thing to different types,
will use the following method signature :

string ConvertToString(object value)
{
return value.ToString();
}

Now, this means that any type may be passed to the method, but that boxing
will occur. However if, in .NET 1.1, we use overloaded method signatures :

string ConvertToString(int value)
{
return value.ToString();
}


string ConvertToString(double value)
{
return value.ToString();
}

void Test()

{
int i = 123;

string s = ConvertToString(i);
}

.... the correct overloaded method will be called for the true type of the
parameter and the native version of ToString() for each type will be called.

Or you could use generics to simplify this even further :


string ConvertToString<T>(T value)
{
return value.ToString();
}


void Test()

{
int i = 123;

string s = ConvertToString(i);
}

The compîler infers the type of the generic method from the type being
passed to the value parameter. A true int gets passed to the method and
ToString() gets called on the native type with no boxing.

So, you can see, for a little more effort on the part of the develpoer,
boxing can be avoided again.

Joanna

 

[Peter Olcott]

"Peter Olcott" <[email protected]> a écrit dans le message de [email protected]...

| > If you call (for instance) myInt.ToString() then boxing isn't involved.

My apologies, I assumed boxing occurred here.

| It would still seem like far less than the best possible design of all
possible
| designs. It still seems like run-time overhead that could have been done
at
| compile-time.

Rathermore, it is usually down to developer laziness, using object
parameters to methods where strictly typed methods would be more efficient


Many times, developers, wanting to do the same thing to different types,
will use the following method signature :

string ConvertToString(object value)
{
return value.ToString();
}

Now, this means that any type may be passed to the method, but that boxing
will occur. However if, in .NET 1.1, we use overloaded method signatures :

string ConvertToString(int value)
{
return value.ToString();
}


string ConvertToString(double value)
{
return value.ToString();
}

void Test()

{
int i = 123;

string s = ConvertToString(i);
}

... the correct overloaded method will be called for the true type of the
parameter and the native version of ToString() for each type will be called.

Or you could use generics to simplify this even further :


string ConvertToString<T>(T value)
{
return value.ToString();
}


void Test()

{
int i = 123;

string s = ConvertToString(i);
}

The compîler infers the type of the generic method from the type being
passed to the value parameter. A true int gets passed to the method and
ToString() gets called on the native type with no boxing.

So, you can see, for a little more effort on the part of the develpoer,
boxing can be avoided again.

Joanna

This would now seem to make much more sense. As long as the unnecessary overhead
can be easily avoided, and the purpose of this overhead is to make it a little
easier on the programmer for applications where performance is not important,
then there would be no problem. Now that Generics exist, the fast way is also
just as easy. I was pleasantly surprised to find that managed code in 2005
seemed to perform better that native code under Visual C++ 6.0 on two critical
benchmarks.