objects in arrays...

  • Thread starter Thread starter Dan
  • Start date Start date
D

Dan

Given some object that I define as:

class myItem
{
public string szItemName = "";
public string szItemValue = "";
public string szOrderNumber = ""
}



that is collected into an ArrayList

ArrayList aryItems = new ArrayList();
// code to populate aryItems here



Now say I go through the array with a "foreach" loop, and change some
values, do I need to do the following?

foreach ( myItem itm in aryItems )
{

if ( itm.szItemName == "fred" )
{
// first remove the element from the array
int nIndex = aryItems.IndexOf ( itm );
aryItems.Remove (itm);

// now change the object in some way
itm.szItemValue = "flintstone";

// reinsert the object back into the array
aryItems.InsertAt ( itm )
}

}



or can I do this?

foreach ( myItem itm in aryItems )
{

if ( itm.szItemName == "fred" )
{
// just change the object in some way, this
// updates the object in stored in the collection as well...
itm.szItemValue = "flintstone";
}

}


Basically in the foreach enumeration is each object being copied to another
object that I reference, or does it provide a point back to the object
existing in the collection...
 
Given some object that I define as:

class myItem
{
public string szItemName = "";
public string szItemValue = "";
public string szOrderNumber = ""
}

that is collected into an ArrayList

ArrayList aryItems = new ArrayList();
// code to populate aryItems here

Now say I go through the array with a "foreach" loop, and change some
values, do I need to do the following?

foreach ( myItem itm in aryItems )
{

if ( itm.szItemName == "fred" )
{
// first remove the element from the array
int nIndex = aryItems.IndexOf ( itm );
aryItems.Remove (itm);

// now change the object in some way
itm.szItemValue = "flintstone";

// reinsert the object back into the array
aryItems.InsertAt ( itm )
}

}

You can't do that, to start with - you can't modify the collection
while you're iterating through it. You'll get an exception at runtime.
or can I do this?

foreach ( myItem itm in aryItems )
{

if ( itm.szItemName == "fred" )
{
// just change the object in some way, this
// updates the object in stored in the collection as well...
itm.szItemValue = "flintstone";
}
}

Yup, you can do that.
Basically in the foreach enumeration is each object being copied to another
object that I reference, or does it provide a point back to the object
existing in the collection...

The object isn't in the collection at all. What's in the collection is
a *reference*, and it's that reference which you've been given.

I suggest you read up on reference types. My article on parameter
passing has some information on this - I haven't got round to writing a
full article on the topic yet.
http://www.pobox.com/~skeet/csharp/parameters.html
 
Thanks Jon.

What about an instance where an index counter is used?
Instead of
foreach (...)
it was
for ( x = 0; x < aryItems.Count; x++ )...

Same thing?

Thanks.
 
What about an instance where an index counter is used?
Instead of
foreach (...)
it was
for ( x = 0; x < aryItems.Count; x++ )...

Same thing?

It's the same thing in terms of what's in the collection, but there you
can modify the collection. Of course, if you remove the "current" item,
everything gets shifted down one place, so if you're not careful you
can end up missing the next item.
 
Jon said:
Yup, you can do that.
To tag onto someone else's post, but with similar information....


If I know the position of the item I want to modify, can I avoid looping
through the arraylist?

....
myItem itm = aryItems
itm.szItemValue = "flinstone"
....

Thanks.
-Ben
 
To tag onto someone else's post, but with similar information....

We'll let you off, just this once. ;o)
Good question to follow up though.

Later.

Dan.
 
Ben Bloom said:
If I know the position of the item I want to modify, can I avoid looping
through the arraylist?

...
myItem itm = aryItems
itm.szItemValue = "flinstone"
...


Yes, although you'll need to cast. You don't even really *need* a
separate variable:

((myItem)aryItems).szItemValue = "flinstone";

Splitting the lines up may well help with readability though. (As would
ditching Hungarian notation :)
 
Splitting the lines up may well help with readability though. (As would
ditching Hungarian notation :)

Hey I like my hungarian! ;o)

Is there a style for c#? I read the microsoft jargon on it when c# first
came out, and I thought they used some variation of hungarian.

It's good for distinguishing between
szAge and
nAge
 
Hey I like my hungarian! ;o)

Is there a style for c#? I read the microsoft jargon on it when c# first
came out, and I thought they used some variation of hungarian.

It's good for distinguishing between
szAge and
nAge

Search in groups.google.com for my opinions on the topic :)

MS convention is here:
http://tinyurl.com/2cun
 
Wow, I see what you mean, there are lots discussions involving yourself and
some really passionate people.

I'm from a C++ background where hungarian was simply a means to make your
code readable. Hungarian was not just this I'm sure, but that was the main
role it played for me... As VC++ evolved, the standard seemed to fit in with
the class tree view for example, because all the m_sz were grouped together,
all the m_n were grouped together etc. It makes sense to me simply because
that's what I was taught, and have always used. (C++ != C#) That doesn't
mean that the newer IDE's and languages all fit into the old, and I'm
prepared to change to whatever the current trends are if they are of benefit
or standard.

I think if you've got a good design, with proper implementation and tidy
code, then what specifics you go for isn't going to be the greatest of
tragidies if you happen to disagree. ButtonExit or ExitButton... Both seem
clear to me.

I'll read through that MS document again, and try applying that from now
on...
 
Age is "57 Years and 3 Months" or 57?

Age is 57. AgeString is "57 Years and 3 Months".

Age is numerical. Whenever you see an identifier called age, you can
safely presume (in my code, anyway) that it's a number.

In the case of an age represented as a string, such as in your stated
example, I'd use a postfix of 'String' to describe it. I prefer the
postfix to the prefix since it allows a natural order of words.
 
In the case of an age represented as a string, such as in your stated
example, I'd use a postfix of 'String' to describe it. I prefer the
postfix to the prefix since it allows a natural order of words.

The only reason I prefer the prefix is like I said in the other post, the
class view groups them together alphabetically, so the same typed variables
are together. It's just something I suppose I've gotten used to.
 
The only reason I prefer the prefix is like I said in the other post, the
class view groups them together alphabetically, so the same typed variables
are together. It's just something I suppose I've gotten used to.

Type doesn't have much semantic meaning though - whereas the name
should.

To my mind, age and ageString are closer in semantic meaning (as they
deal with the same thing, the age of the person or whatever the object
is) than age and height. I'd therefore rather see

age
ageString
height
heightString

than

nAge
nHeight
strAge
strHeight

Things which are close in meaning are close in sort order. Not that the
sort order is particularly important to me, as it happens - I group
things in code instead, and rarely use lists which don't allow me to
look in code order rather than alphabetical order.
 
I agree, although in this example you've got two instances of the same data,
which I doubt would happen, on a class wide scope anyway.

In code [very] generally, I've found that the strings all play some part in
being relatable to each other. For example, I'm currently using a lot of XML
in sending my data between different databases, SAP etc, and found it useful
to group them as so:

strXmlAttributeName = "name";
strXmlAttributeValue = "value";
strXmlNodeMessage = "MESSAGE";
strXmlNodeField = "FIELD";
strXmlNodeData = "DATA";

When using auto complete for example, i find it useful that they're all
grouped together into type.

How would you name these? (apart from putting String at the end of the
variable name)
 
I agree, although in this example you've got two instances of the same data,
which I doubt would happen, on a class wide scope anyway.

In code [very] generally, I've found that the strings all play some part in
being relatable to each other. For example, I'm currently using a lot of XML
in sending my data between different databases, SAP etc, and found it useful
to group them as so:

strXmlAttributeName = "name";
strXmlAttributeValue = "value";
strXmlNodeMessage = "MESSAGE";
strXmlNodeField = "FIELD";
strXmlNodeData = "DATA";

When using auto complete for example, i find it useful that they're all
grouped together into type.

How would you name these? (apart from putting String at the end of the
variable name)

I wouldn't even put String at the end of the variable name, to be
honest - I don't do that unless it's to distinguish it from something
else which deals with the same data.

Are these member variables or local variables? Local variables can get
a lot from the context - I might well just use name, value, message,
field and data.

I'd have to know the exact details, to be honest. If all those five
fields are related, that would suggest they might be better
encapsulated in another class in the first place.
 
I wouldn't even put String at the end of the variable name, to be
honest - I don't do that unless it's to distinguish it from something
else which deals with the same data.

Are these member variables or local variables? Local variables can get
a lot from the context - I might well just use name, value, message,
field and data.

I'd have to know the exact details, to be honest. If all those five
fields are related, that would suggest they might be better
encapsulated in another class in the first place.


I've just got a nice big list of constants in a static class! >8-)

If thought had been put into it I would have created a constant class, then
put catergories and sub catorgies into it to narrow down the fields of
association... yep yep.
 
Back
Top