I'm doing my c# more and more like i used to code c++, meaning i'm casting
more often than creating an instance of objects.
like :
protected void gvOrderDetailsRowDataBound(object sender,
GridViewRowEventArgs e)
{
if (e.Row.RowType == DataControlRowType.DataRow)
{
switch (((Sale)e.Row.DataItem).SzPN)
{
case "LTM0001":
case "ANU0001":
Person PER =
PersonManager.GetItem(((Sale)e.Row.DataItem).IPersonID);
if (PER.BActive)
((Label)e.Row.FindControl("lblOwner")).Text =
PER.FullName;
else
((Label)e.Row.FindControl("lblOwner")).Text = "Not
Yet Active";
break;
default:
break;
}
}
}

would an instance created once for (Sale)e.Row.DataItem,
where the row is bound to a custom business object, be faster, slow or no
different than just casting the e.row.DataItem each time i need a value?
--
Share The Knowledge. I need all the help I can get and so do you!

You seem to be inferring that a cast takes time at runtime.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

"Yankee Imperialist Dog" <(E-Mail Removed)>
wrote in message news:00CD68BF-EB3C-4B2C-B078-(E-Mail Removed)...
> I'm doing my c# more and more like i used to code c++, meaning i'm casting
> more often than creating an instance of objects.
> like :
> protected void gvOrderDetailsRowDataBound(object sender,
> GridViewRowEventArgs e)
> {
> if (e.Row.RowType == DataControlRowType.DataRow)
> {
> switch (((Sale)e.Row.DataItem).SzPN)
> {
> case "LTM0001":
> case "ANU0001":
> Person PER =
> PersonManager.GetItem(((Sale)e.Row.DataItem).IPersonID);
> if (PER.BActive)
> ((Label)e.Row.FindControl("lblOwner")).Text =
> PER.FullName;
> else
> ((Label)e.Row.FindControl("lblOwner")).Text = "Not
> Yet Active";
> break;
> default:
> break;
> }
> }
> }
>
> would an instance created once for (Sale)e.Row.DataItem,
> where the row is bound to a custom business object, be faster, slow or no
> different than just casting the e.row.DataItem each time i need a value?
> --
> Share The Knowledge. I need all the help I can get and so do you!

that is possible. Does creating an instance take time at runtime where a cast
would not?
--
Share The Knowledge. I need all the help I can get and so do you!


"Bob Powell [MVP]" wrote:

> You seem to be inferring that a cast takes time at runtime.
>
> --
> Bob Powell [MVP]
> Visual C#, System.Drawing
>
> Ramuseco Limited .NET consulting
> http://www.ramuseco.com
>
> Find great Windows Forms articles in Windows Forms Tips and Tricks
> http://www.bobpowell.net/tipstricks.htm
>
> Answer those GDI+ questions with the GDI+ FAQ
> http://www.bobpowell.net/faqmain.htm
>
> All new articles provide code in C# and VB.NET.
> Subscribe to the RSS feeds provided and never miss a new article.
>
> "Yankee Imperialist Dog" <(E-Mail Removed)>
> wrote in message news:00CD68BF-EB3C-4B2C-B078-(E-Mail Removed)...
> > I'm doing my c# more and more like i used to code c++, meaning i'm casting
> > more often than creating an instance of objects.
> > like :
> > protected void gvOrderDetailsRowDataBound(object sender,
> > GridViewRowEventArgs e)
> > {
> > if (e.Row.RowType == DataControlRowType.DataRow)
> > {
> > switch (((Sale)e.Row.DataItem).SzPN)
> > {
> > case "LTM0001":
> > case "ANU0001":
> > Person PER =
> > PersonManager.GetItem(((Sale)e.Row.DataItem).IPersonID);
> > if (PER.BActive)
> > ((Label)e.Row.FindControl("lblOwner")).Text =
> > PER.FullName;
> > else
> > ((Label)e.Row.FindControl("lblOwner")).Text = "Not
> > Yet Active";
> > break;
> > default:
> > break;
> > }
> > }
> > }
> >
> > would an instance created once for (Sale)e.Row.DataItem,
> > where the row is bound to a custom business object, be faster, slow or no
> > different than just casting the e.row.DataItem each time i need a value?
> > --
> > Share The Knowledge. I need all the help I can get and so do you!
>

On Jun 17, 12:05 am, "Bob Powell [MVP]"
<bob@_spamkiller_bobpowell.net> wrote:
> You seem to be inferring that a cast takes time at runtime.

You seem to be implying that it doesn't

Unless the compiler can guarantee that the cast is valid (and not even
then, sometimes) the cast *will* take time at execution time. Not a
lot, but some.

To the OP: I wouldn't worry about the performance side, but the
clarity side. Creating a new object and reuing an old one are usually
significantly different operations, wiith different implications. Go
with whatever produces the cleanest, most natural code. If you're
logically operating on an existing object, do so - if you're logically
creating a new one, do that instead

Jon

Thank You for replying, all of you.
Perhaps my terms were off and i stand corrected. The local variable in my
case is a class and as it is atomic in it's scope i guess this does make it a
variable. The root here is memory usage and time. From what all of you said
it seems that there really is no difference. Creating a variable of type
"Sale" and storing all the objects from the data row is not any different
than time or memory wise than casting for each object i need from that data
row.

Please correct me if i am wrong here

Thanks
--
Share The Knowledge. I need all the help I can get and so do you!


"Peter Duniho" wrote:

> On Mon, 16 Jun 2008 15:51:06 -0700, Yankee Imperialist Dog
> <(E-Mail Removed)> wrote:
>
> > [...]
> > would an instance created once for (Sale)e.Row.DataItem,
> > where the row is bound to a custom business object, be faster, slow or no
> > different than just casting the e.row.DataItem each time i need a value?
>
> As Bob's reply suggests, casting really isn't a performance issue. It's
> not true that it's completely free -- unless the compiler can tell that
> the cast is perfectly safe (and most of the time, it can't), there's a
> run-time check for the type. But the check is relatively insignificant.
>
> That said, the real issue here is that you seem to be under the impression
> that casting is equivalent to _creating_ an instance of an object. It's
> not.
>
> Now, it's possible that when you write "an instance created once", you
> really just mean casting the value once as you assign it to a local
> variable. And in fact, I would do that. Not because it's more
> performant, but just because if you're using the value more than once, it
> makes the code nicer to read.
>
> But doing the cast doesn't create an instance, not even if you do it when
> assigning to a local variable of the target type. If you're trying to
> learn C#, it will be important for you to be careful about correctly
> describing what the code is doing, and in particular describing a simple
> assignment as "creating an instance" is incorrect and will likely lead to
> misunderstandings in the future if that description continues to be used.
>
> Pete
>

On Jun 17, 1:26 pm, Yankee Imperialist Dog
<YankeeImperialist...@discussions.microsoft.com> wrote:
> Thank You for replying, all of you.
> Perhaps my terms were off and i stand corrected. The local variable in my
> case is a class and as it is atomic in it's scope i guess this does make it a
> variable. The root here is memory usage and time. From what all of you said
> it seems that there really is no difference. Creating a variable of type
> "Sale" and storing all the objects from the data row is not any different
> than time or memory wise than casting for each object i need from that data
> row.
>
> Please correct me if i am wrong here

It feels like your terminology is still a bit off - a class can't be
atomic, for example.

Could you post a short but *complete* program demonstrating what you
mean?

Certainly creating instances and casting *are* different in time and
memory, but whether or not they're *significantly* different will
depend on the situation.

Jon

i'll describe

Sale is a class. Having firstname, lastname, .......
if i create an object ("by casting the DataItem to type of Sale)
Sale SAL = ((Sale)e.row.DataItem;
if (SAL.SzPn == "YYY")
SAL.FirstName;
SAL.LastName;


if i cast the DataItem to
if (((Sale)e.Row.DataItem).SzPN == "YYY")
(((Sale)e.Row.DataItem).SzFirstName;
(((Sale)e.Row.DataItem).SzLastName;
....;
ok I think we can agree that SAL it is an object of Type Sale. The question
here is, as implied from other answers/comments above. Is SAL a "Variable" of
Type Sale or an "Instance" of type Sale. I, up to this point, would have
considered it an instance. However, it suggested above by another poster
(Peter) that it should be considered a variable(?) Now i understand that it's
values can vary, but i've always considered an object created from a class to
be an instance(?)

That asside say i'm going to be setting the 50 public properties of object SAL
is there a time or memory difference between
Sale SAL = ((Sale)e.row.DataItem;
SAL.FirstName = "TTT";
....
....
... to property #50
and
(((Sale)e.Row.DataItem).SzFirstName = "TTT";
....
....
.... to row 50

It may be splitting hairs, but I'm curious, because i tend to like the latter.

Thanks
--
Share The Knowledge. I need all the help I can get and so do you!


"Jon Skeet [C# MVP]" wrote:

> On Jun 17, 1:26 pm, Yankee Imperialist Dog
> <YankeeImperialist...@discussions.microsoft.com> wrote:
> > Thank You for replying, all of you.
> > Perhaps my terms were off and i stand corrected. The local variable in my
> > case is a class and as it is atomic in it's scope i guess this does make it a
> > variable. The root here is memory usage and time. From what all of you said
> > it seems that there really is no difference. Creating a variable of type
> > "Sale" and storing all the objects from the data row is not any different
> > than time or memory wise than casting for each object i need from that data
> > row.
> >
> > Please correct me if i am wrong here
>
> It feels like your terminology is still a bit off - a class can't be
> atomic, for example.
>
> Could you post a short but *complete* program demonstrating what you
> mean?
>
> Certainly creating instances and casting *are* different in time and
> memory, but whether or not they're *significantly* different will
> depend on the situation.
>
> Jon
>

And your code is so ugly it is OOOGLY ;-)
Here's some resources to help you make the suggested transition...

http://msdn.microsoft.com/en-us/library/czefa0ke.aspx
http://dotnet.mvps.org/dotnet/faqs/?...ingconventions

<%= Clinton Gallagher


"Yankee Imperialist Dog" <(E-Mail Removed)>
wrote in message news:9AEA2F84-2A43-4DC2-B8BB-(E-Mail Removed)...
> i'll describe
>
> Sale is a class. Having firstname, lastname, .......
> if i create an object ("by casting the DataItem to type of Sale)
> Sale SAL = ((Sale)e.row.DataItem;
> if (SAL.SzPn == "YYY")
> SAL.FirstName;
> SAL.LastName;
>
>
> if i cast the DataItem to
> if (((Sale)e.Row.DataItem).SzPN == "YYY")
> (((Sale)e.Row.DataItem).SzFirstName;
> (((Sale)e.Row.DataItem).SzLastName;
> ....;
> ok I think we can agree that SAL it is an object of Type Sale. The
> question
> here is, as implied from other answers/comments above. Is SAL a "Variable"
> of
> Type Sale or an "Instance" of type Sale. I, up to this point, would have
> considered it an instance. However, it suggested above by another poster
> (Peter) that it should be considered a variable(?) Now i understand that
> it's
> values can vary, but i've always considered an object created from a class
> to
> be an instance(?)
>
> That asside say i'm going to be setting the 50 public properties of object
> SAL
> is there a time or memory difference between
> Sale SAL = ((Sale)e.row.DataItem;
> SAL.FirstName = "TTT";
> ....
> ....
> ... to property #50
> and
> (((Sale)e.Row.DataItem).SzFirstName = "TTT";
> ...
> ...
> ... to row 50
>
> It may be splitting hairs, but I'm curious, because i tend to like the
> latter.
>
> Thanks
> --
> Share The Knowledge. I need all the help I can get and so do you!
>
>
> "Jon Skeet [C# MVP]" wrote:
>
>> On Jun 17, 1:26 pm, Yankee Imperialist Dog
>> <YankeeImperialist...@discussions.microsoft.com> wrote:
>> > Thank You for replying, all of you.
>> > Perhaps my terms were off and i stand corrected. The local variable in
>> > my
>> > case is a class and as it is atomic in it's scope i guess this does
>> > make it a
>> > variable. The root here is memory usage and time. From what all of you
>> > said
>> > it seems that there really is no difference. Creating a variable of
>> > type
>> > "Sale" and storing all the objects from the data row is not any
>> > different
>> > than time or memory wise than casting for each object i need from that
>> > data
>> > row.
>> >
>> > Please correct me if i am wrong here
>>
>> It feels like your terminology is still a bit off - a class can't be
>> atomic, for example.
>>
>> Could you post a short but *complete* program demonstrating what you
>> mean?
>>
>> Certainly creating instances and casting *are* different in time and
>> memory, but whether or not they're *significantly* different will
>> depend on the situation.
>>
>> Jon
>>

And your code is so ugly it is OOGLY ;-)
Here's some resources to help you make the suggested transition...

http://msdn.microsoft.com/en-us/library/czefa0ke.aspx
http://dotnet.mvps.org/dotnet/faqs/?...ingconventions

<%= Clinton Gallagher


"Yankee Imperialist Dog" <(E-Mail Removed)>
wrote in message news:9AEA2F84-2A43-4DC2-B8BB-(E-Mail Removed)...
> i'll describe
>
> Sale is a class. Having firstname, lastname, .......
> if i create an object ("by casting the DataItem to type of Sale)
> Sale SAL = ((Sale)e.row.DataItem;
> if (SAL.SzPn == "YYY")
> SAL.FirstName;
> SAL.LastName;
>
>
> if i cast the DataItem to
> if (((Sale)e.Row.DataItem).SzPN == "YYY")
> (((Sale)e.Row.DataItem).SzFirstName;
> (((Sale)e.Row.DataItem).SzLastName;
> ....;
> ok I think we can agree that SAL it is an object of Type Sale. The
> question
> here is, as implied from other answers/comments above. Is SAL a "Variable"
> of
> Type Sale or an "Instance" of type Sale. I, up to this point, would have
> considered it an instance. However, it suggested above by another poster
> (Peter) that it should be considered a variable(?) Now i understand that
> it's
> values can vary, but i've always considered an object created from a class
> to
> be an instance(?)
>
> That asside say i'm going to be setting the 50 public properties of object
> SAL
> is there a time or memory difference between
> Sale SAL = ((Sale)e.row.DataItem;
> SAL.FirstName = "TTT";
> ....
> ....
> ... to property #50
> and
> (((Sale)e.Row.DataItem).SzFirstName = "TTT";
> ...
> ...
> ... to row 50
>
> It may be splitting hairs, but I'm curious, because i tend to like the
> latter.
>
> Thanks
> --
> Share The Knowledge. I need all the help I can get and so do you!
>
>
> "Jon Skeet [C# MVP]" wrote:
>
>> On Jun 17, 1:26 pm, Yankee Imperialist Dog
>> <YankeeImperialist...@discussions.microsoft.com> wrote:
>> > Thank You for replying, all of you.
>> > Perhaps my terms were off and i stand corrected. The local variable in
>> > my
>> > case is a class and as it is atomic in it's scope i guess this does
>> > make it a
>> > variable. The root here is memory usage and time. From what all of you
>> > said
>> > it seems that there really is no difference. Creating a variable of
>> > type
>> > "Sale" and storing all the objects from the data row is not any
>> > different
>> > than time or memory wise than casting for each object i need from that
>> > data
>> > row.
>> >
>> > Please correct me if i am wrong here
>>
>> It feels like your terminology is still a bit off - a class can't be
>> atomic, for example.
>>
>> Could you post a short but *complete* program demonstrating what you
>> mean?
>>
>> Certainly creating instances and casting *are* different in time and
>> memory, but whether or not they're *significantly* different will
>> depend on the situation.
>>
>> Jon
>>

On Jun 17, 2:36 pm, Yankee Imperialist Dog
<YankeeImperialist...@discussions.microsoft.com> wrote:
> i'll describe
>
> Sale is a class. Having firstname, lastname, .......
> if i create an object ("by casting the DataItem to type of Sale)
> Sale SAL = ((Sale)e.row.DataItem;

What makes you think that's creating an object? It's not. It's not
creating anything, it's just casting a reference.

> if (SAL.SzPn == "YYY")
> SAL.FirstName;
> SAL.LastName;
>
> if i cast the DataItem to
> if (((Sale)e.Row.DataItem).SzPN == "YYY")
> (((Sale)e.Row.DataItem).SzFirstName;
> (((Sale)e.Row.DataItem).SzLastName;
> ....;
> ok I think we can agree that SAL it is an object of Type Sale. The question
> here is, as implied from other answers/comments above. Is SAL a "Variable" of
> Type Sale or an "Instance" of type Sale.

SAL itself is definitely a variable.

> I, up to this point, would have
> considered it an instance. However, it suggested above by another poster
> (Peter) that it should be considered a variable(?) Now i understand that it's
> values can vary, but i've always considered an object created from a class to
> be an instance(?)

It's neither an object, nor an instance. It's a variable. It's a local
variable which has a particular value.

Here's another example:

int x = 0;

"x" isn't an int. It's a variable of type int. The *value* of x is an
int.

> That asside say i'm going to be setting the 50 public properties of object SAL
> is there a time or memory difference between
> Sale SAL = ((Sale)e.row.DataItem;
> SAL.FirstName = "TTT";
> ....
> ....
> ... to property #50
> and
> (((Sale)e.Row.DataItem).SzFirstName = "TTT";
> ...
> ...
> ... to row 50
>
> It may be splitting hairs, but I'm curious, because i tend to like the latter.

Well it doesn't make sense to perform a cast 60 times or indeed
evaluate the Row and DataItem properties 60 times, and personally I
don't like the readability of the version which casts all the time, so
I'd use the former. What do you like about the latter?

Jon