I use this type of construct often.
response = new LocationResponse ();
response.LocationDetails = new LocationDetail[4];
response.LocationDetails[0] = new LocationDetail();
response.LocationDetails[0].site = "ABCDE";
...
The piece I don't fully understand is this piece:
response.LocationDetails[0] = new LocationDetail();
Why does each individual element of the array have to be instantiated?
If you leave it out, you get undefined exceptions.
Well if an array elements were automatically instantiated, you would be locked into which classes you defined the array with. You wouldn't be able to use arrays of abstract classes or interfaces or any object which doesn't have a default constructor. This is just naming a few problems with automatically instantiating objects in an array.
You don't need to instantiate LocationDetail if it is a value type (struct). You have to instantiate it if it's a class because the default value for a reference type is null.
This code works:
public struct LocationDetail
{
private string site;
public string Site
{
get { return site; }
set { site = value; }
}
}
static void Main(string[] args)
{
LocationResponse response = new LocationResponse();
response.LocationDetails = new LocationDetail[4];
response.LocationDetails[0].Site = "ABCDE";
Console.Write(response.LocationDetails[0].Site);
}
Think of it as a reference pointer, if you don't initialize you have a null value on each of the LocationDetail items.
It set each element to null, which is the default value for a class until you say otherwise.
How can C# automatically instantiate the elements for you? Perhaps that type in your array doesn't even have a default constructor. Maybe you don't want to consume the memory required by an entire array of elements before you actually have them.
I don't see the advantage to having the runtime try to fill that array in advance.
I think of arrays as egg-cartons. You can declare an egg carton, but that doesn't put eggs in your carton - you still have to decide what kind of egg to put in each slot of the carton. You might want easter eggs in some, but grade AA free-roam brown eggs in others.
The array itself can't know what you want ahead of time, so it defaults to putting nothing in your slots.
It would be a costly operation, depending on what needs to be done to create the objects. Furthermore, what if the objects cannot simply be instantiated? Or if you need an array of a given type, where only some fields will eventually contain an object and others shoud be null?
As others have pointed out, the array will be full of nulls after you declare it. You can simplify your initialization logic somewhat by doing this:
response.LocationDetails = new LocationDetails [] {
new LocationDetails(),
new LocationDetails(),
new LocationDetails(),
new LocationDetails()
};
And what would be even nicer is if the LocationDetails constructor had an overload that took a siteid:
response.LocationDetails = new LocationDetails [] {
new LocationDetails("ABCDE"),
new LocationDetails("FGHIJ"),
new LocationDetails("KLMNO"),
new LocationDetails("PQRST")
};
Or the super fancy C# 3.0 stuff that Justice points out :)
response = new LocationResponse() {
LocationDetails = new LocationDetail[] {
new LocationDetail { site = "ABCDE" }
}
}
Related
In my code,I do have a List, named lstDetails.
It contains another List, named lstcheckdetails.
As output, lstcheckdetails returns an empty list as it calls Clear function.
Until now I thought the list will get committed after adding data to it.
Can you help me out?
List<AttendanceDetails> lstDetails = new List<AttendanceDetails>();
List<CheckDetails> lstcheckdetails = new List<CheckDetails>();
CheckDetails checkdetails = new CheckDetails();
for loop
{
if(condition)
{
checkdetails.Item1 = item1;
checkdetails.Item2 = item2;
lstcheckdetails.Add(checkdetails);
}
else
{
lstDetails.Add(new AttendanceDetails { TimeCard = lstcheckdetails });
lstcheckdetails.Clear();
}
}
I would recommend reading up on how reference types work in C#. Jon Skeet as always, is a good person to listen to. References and Values - however there are plenty of sources on this out there
To make a quick summary reference types as their name implies are passed around by reference, so unless you explicitly make a copy of that object (in this case creating a new list by using .ToList()) you new object and the loop both point to the same object in memory, that's why called .Clear() empties the list in both places you are looking at it.
A quick fix for you piece of code would be ... { TimeCard = lscheckdetails.ToList(), ... This creates a new copy of the list and lets you clear the one in your loop.
I have a multidimensional array called SensorGetResult. In some cases this array can have a single array in it. If that happens, I must copy this one array and add it again, so I must have 2 arrays now. Then I need to change these array's dateTime property. This is my code:
var helperArray = sensorGet.SensorGetResult[0];
sensorGet.SensorGetResult.Add(helperArray);
sensorGet.SensorGetResult[0].dateTime = end; //It works correctly including this line
sensorGet.SensorGetResult[1].dateTime = start; //At this line both array's dateTime property changes
Why can't I assign dateTime properties to each array individually?
It looks like you are using a reference type for your helperArray.
When the following code executes:
var helperArray = sensorGet.SensorGetResult[0];
sensorGet.SensorGetResult.Add(helperArray);
What actually happens is you take a the first element of SensorGetResult which is a reference to the object (which I believe you intend to copy) and append the reference to the list thus resulting in a list which has two references to the same object in the memory.
If you want it to make a copy of the object, you have to implement that by yourself. Usually this means creating a new object of the same type and copying all the properties.
var objectToCopy = sensorGet.SensorGetResult[0];
var helperArray = new WhatEverTypeIsYourHelperArray {
Property1 = objectToCopy.Property1,
Property2 = objectToCopy.Property2,
// etc.
};
sensorGet.SensorGetResult.Add(helperArray);
But you have to be aware if any of the properties is furthermore a reference type, you need to do this recursively for all the properties.
If WhatEverTypeIsYourHelperArray is type you own, you could utilize Object.MemberwiseClone method and make it all easier for yourself. You can do this by implementing a method like the following. As a note, MemberwiseClone is a protected method hence the need of a new method in your class.
public WhatEverTypeIsYourHelperArray Clone() {
return (WhatEverTypeIsYourHelperArray)this.MemberWiseClone();
}
But even the MemberwiseClone() method doesn't copy reference types for you, rather just copies the pointers to the objects which means that all the properties of reference type of both the original and the cloned object will point to the same objects in the memory.
SensorGetResult row seems to be a reference type.
So when you wrote
var helperArray = sensorGet.SensorGetResult[0];
sensorGet.SensorGetResult.Add(helperArray);
you actually said that new row in SensorGetResult will point to the same object as the first one.
You can implement method like below:
public SensorGetResultRow Clone()
{
return new SensorGetResultRow (this.field1, this.field2, etc...)
//or if you use parameterless constructor
return new SensorGetResultRow ()
{
field1 = this.field1
//etc.
}
}
and use it:
var helperArray = sensorGet.SensorGetResult[0].Clone();
First of all I will say that I've changed my design and no longer need that but getting a good answer for that will still be nice
I have the following class, ListContainer, in my code (The attached codes are all mcve):
class ListContainer
{
public object ContainedList
{
get; private set;
}
public int Value
{
get; private set;
}
public ListContainer(object list, int value)
{
ContainedList = list;
Value = value;
}
}
And in some other class in my code I have a List<ListContainer> and I need each ListContainer to contain this List<ListContainer>, so I can implement it like that:
//Field in the class
List<ListContainer> mContainers = null;
//In the constructor:
mContainers = new List<ListContainer>();
mContainers.Add(new ListContainer(mContainers, SOME_CONST));
mContainers.Add(new ListContainer(mContainers, SOME_OTHER_CONST));
Than it works fine, but when I've tried to use list initializer:
//Field in the class
List<ListContainer> mContainers = null;
//In the constructor:
mContainers = new List<ListContainer>
{
new ListContainer(mContainers, SOME_CONST),
new ListContainer(mContainers, SOME_OTHER_CONST)
}
You would expect the results to be equivalent but in reality the result looks like that:
mContainers
[0] - ListContainer
ContainedList = null
Value = SOME_CONST
[1] - ListContainer
ContainedList = null
Value = SOME_OTHER_CONST
Seeing this results I've inspected the output MSIL of this C# compilation and seen the following code:
Now, this explains why the problem occurs, and I've even checked out in the CSharp Language Specification document and this is the defined behavior:
A List can be created and initialized as follows:
var contacts = new List<Contact> {
new Contact {
Name = "Chris Smith",
PhoneNumbers = { "206-555-0101", "425-882-8080" }
},
new Contact {
Name = "Bob Harris",
PhoneNumbers = { "650-555-0199" }
}
};
which has the same effect as
var __clist = new List<Contact>();
Contact __c1 = new Contact();
__c1.Name = "Chris Smith";
__c1.PhoneNumbers.Add("206-555-0101");
__c1.PhoneNumbers.Add("425-882-8080");
__clist.Add(__c1);
Contact __c2 = new Contact();
__c2.Name = "Bob Harris";
__c2.PhoneNumbers.Add("650-555-0199");
__clist.Add(__c2);
var contacts = __clist;
where __clist, __c1 and __c2 are temporary variables that are otherwise invisible and inaccessible.
So obviously this behaviour is intended. Is there a good reason everything is done on the temporary variable and not on the original one? since it seems like a wrong behaviour to me.
The reason is to avoid race conditions with concurrent threads accessing the original variable where you would add your elements. An inconsistency would appear if a thread accesses the variable while not all elements are added to it yet.
Two threads accessing the same variable would therefore get an inconsistent list, with different elements in it.
This would not come as a shock if the elements are added on different lines, but since you use an object initializer, it is normal to perceive the object as directly initialized with all its elements in it, hence the need of a temporary, invisible, variable.
Is there a good reason everything is done on the temporary List and not on the original one?
There is no original list:
var __clist = new List<Contact>();
// …
__clist.Add(__c1);
// …
__clist.Add(__c2);
var contacts = __clist;
Only one list is ever created. What you probably mean is that it’s done on a temporary variable instead of the original variable, but that has no practical effect—other than probably being easier to implement. This is especially true if you think about that collection initialization is not limited to the context of variable assignments:
SomeMethodCall(new List<int>() { 1, 2, 3 });
Since there is no reference to that list, the simplest solution to implement this is just to use a temporary variable that holds the list, and put that variable at the place of the initializer then.
What’s also important about this is that the old value is completely overwritten. So in your mContainers = new List<ListContainer>, the old value of mContainers is never being looked at for the purpose of the initializer syntax.
It’s probably a good idea to think about the collection initialization as an “atomic” operation. The list only exists (at least to you) once the whole initializer completes. So you cannot reference itself from within the initializer.
Assignments are first evaluated on the right side of the = and then the assignment takes place. So mContainers is still null.
class Program{
static void Main(string[] args){
object[] array = new object[1];
CreateItem item = new CreateItem();
item.name = "Necklace";
item.value = 5;
array[0] = item;
Console.WriteLine(array[0].name); //This part of the code doesn't work.
//It can't find the property name.
Console.ReadLine();
}
}
public class CreateItem {
public string name;
public int value;
}
Hi there! First of all I'd like to say that I'm not very familiar with objects, so excuse any mistakes you can see in the code (Although feel free to correct them, it'd be a great way to learn).
I've been working on making a small game using C#, but I came across a problem: I can't access my object properties when I put them in an array. Does anyone know which code I should use to be able to access my object properties while they're in an array?
Thanks for reading, and once again, excuse any silly mistakes I made, I'm fairly new to working with objects.
You shouldn't use an object array when you have a strong type that you're interested in using (and you know the type already).
CreateItem[] array = new CreateItem[1];
CreateItem item = new CreateItem();
item.name = "Necklace";
item.value = 5;
array[0] = item;
Console.WriteLine(array[0].name);
Necklace will now be outputted as expected.
You should probably look at using Generics and Lists, it is a very common and a valuable concept to grasp, as is the concept of Boxing and Unboxing which Generics solves.
class Program{
static void Main(string[] args){
List<CreateItem> list = new List<CreateItem>();
CreateItem item = new CreateItem();
item.name = "Necklace";
item.value = 5;
list.Add( item );
Console.WriteLine(list[0].name); //This part of the code doesn't work.
//It can't find the property name.
Console.ReadLine();
}
}
You could cast the object to your type, i.e.:
Console.WriteLine(((CreateItem)array[0]).name);
or (more effectively)
define your array as CreateItem[] array = new CreateItem[1];
Line
object[] array = new object[1];
creates an array of elements of type Object which is the base class for all other classes in .NET.
When you do:
array[n] = item;
an implicit conversion to the base type occurs and through array[n] you can access only members of the Object type portion of the CreateItem object (like ToString() or GetType() - their overrides will be called).
If you want to access entire CreateItem object, you have to cast the reference to the base type back to the original type, by using cast operator for example:
var name = ((CreateItem)array[0]).name;
This explicit casting is error-prone, has a run-time overhead and it is a sign of the poor design. When you know the type of the collection in advance, declare the collection of that type as other answers are suggesting:
// you can use array if you know number of items in advance and that number of elements will not change
CreateItem[] array = new CreateItem[N];
// use list if number of elements might change
List<CreateItem> list = new List<CreateItem>();
I'm returning a Json'ed annonymous type:
IList<MyClass> listOfStuff = GetListOfStuff();
return Json(
new {
stuff = listOfStuff
}
);
In certain cases, I know that listOfStuff will be empty. So I don't want the overhead of calling GetListOfStuff() (which makes a database call).
So in this case I'm writing:
return Json(
new {
stuff = new List<ListOfStuff>()
}
);
which seems a bit unnecessarily verbose. I don't care what type of List it is, because it's empty anyway.
Is there a shorthand that can be used to signify empty enumerable/list/array? Something like:
return Json(
new {
stuff = new []
}
);
Or have I been programming JavaScript too long? :)
Essentially you want to emit an empty array. C# can infer the array type from the arguments, but for empty arrays, you still have to specify type. I guess your original way of doing it is good enough. Or you could do this:
return Json(
new {
stuff = new ListOfStuff[]{}
}
);
The type of the array does not really matter as any empty enumerable will translate into [] in JSON. I guess, for readability sake, do specify the type of the empty array. This way when others read your code, it's more obvious what that member is supposed to be.
You could use Enumerable.Empty to be a little more explicit:
return Json(
new {
stuff = Enumerable.Empty<ListOfStuff>()
}
);
Although it isn't shorter and doesn't get rid of the type argument.
dynamic is also a better option when dealing with an anonymous type
Enumerable.Empty<dynamic>()
this worked well for me
You might not care what type of list it is, but it matters to the caller. C# does not generally try to infer types based on the variable to which it is being stored (just as you can't create overloads of methods on return type), so it's necessary to specify the type. That said, you can use new ListOfStuff[0] if you want an empty array returned. This has the effect of being immutable (in length) to the caller (they'll get an exception if they try to call the length-mutating IList<T> methods.)
Yes, there is. You have to define an array with as least one element, and use linq to filter the array leaving no elements. Example:
var foo = new
{
Code = 1,
Name = "Bar",
Value = (float?)5.0
};
//use an empty object (or any object) to define the type of the array
var emptyArrayOfFooType = new[] {
new
{
Code = (int)0,
Name = (string)null,
Value = (float?)null
}
}.Where(e => false).ToArray(); //use linq to filter the array leaving no elements
//you can use an existing anonymous type variable too
var anotherEmptyArray = new[] { foo }.Where(e => false).ToArray();
//this array with one element has the same type of the previous two arrays
var fooArray = new[] { foo };
//all arrays have the same type, so you can combine them
var combinedArrays = emptyArrayOfFooType.Concat(anotherEmptyArray).Union(fooArray);
send a generic type?:
List<Object>()
or send an empty object array: new Object[0]
I guess you are talking about C# here. My knowledge is limited in C# but I don't think you can create a new object with no type. Why can't you return a generic new List[] ? (might be mixing Java generics here, am not sure is one can return a generic type list in C#).