• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

How do I do a get/post for an array in c#?

C

complete

Weaksauce
Joined
Aug 30, 2005
Messages
92
How do I do a get/post for an array in c#?

In C#, you get and set variables like this:

Code: 
public int ID { get; set; }

How would one get and set an array in C#?

This will not work:

Code: 
public uint [5] BIG_Hash {get; set;}
 
You can't set the size of the array in the declaration. You'd have to use
Code: 
public uint[] BIG_Hash { get; set; }
 
I remember I did something like this months ago but I cannot remember how it is done. It is a special case for special variables. You have to add some more code.

public uint[] BIG_Hash { get; set; }
...

obj.BIG_Hash = new uint[5]; // set

uint[] temp = obj.BIG_Hash; // get
Click to expand...
but the last two lines need to be inside a method, right? How would those methods look like?
 
complete said:
I remember I did something like this months ago but I cannot remember how it is done. It is a special case for special variables. You have to add some more code.


but the last two lines need to be inside a method, right? How would those methods look like?
Click to expand...

What are you trying to do with those properties? We can't help you based on what you've said.
 
^ Agreed.

Is an array truly the ideal way to expose data in your scenario?
 
++ Basing the hashcode on individual values what aren't related to the rest of the object (with their own public setters). Are you trying to demo bad code?
 
complete said:
In C#, you get and set variables like this:
Click to expand...

I do not think that you clearly understand what this syntax is for in C#. It's called a "property" and it is a construct that allows you to control access to a private member variable through implied get/set accessors. (If you want a more precise definition, go look up C# Properties on the MSDN documentation).

Essentially, you are using the quick hand version of a property, I believe called an Auto-property.

Here's the basic form...

Code: 
private string name;

public string Name
{
	get
	{
		return name;
	}
	set
	{
		if(name == null)
			throw new ArgumentException();
		name = value; // value is a special keyword
	}
}

public void Test()
{

	String s = Name; // since Name is on the right, it calls the "get accessor"
	Name = "al mac"; // since Name is on the left, it calls the  "set accessor"
}


// automatically creates a private variable for "Age" and wraps it in a property, you just don't see it
public int Age
{
	get;
	set;
}

// Now.. for an array
private byte[] someArray = new byte[1024];

public byte[] SomeArray
{
	get
	{
		return someArray;
	}
	set
	{
		someArray = value;
	}
}

Anyway, you can change the access of either the set or get to be less than the access of the property (for example private). Anyway, there's a lot of documentation on this already online.

You do need to give more information about what you are trying to do though.. of course there is nothing stopping you from doing this...
Code: 
public byte[] SomeArray = new byte[1024];

You do not have to use properties, whether you should or not depends on what you are doing.
 
Last edited:
The main issue here is the OP didn't understand that a property is not the same as a variable, but instead implements the equivalent of two methods that return an array and accept an array. Therefore, setting a size doesn't make sense on a property.

In C#, you get and set variables like this:
Click to expand...
In C#, you create properties like this:
Click to expand...
 
mikeblas said:
Which collection class doesn't?
Click to expand...

He has selected a framework which obfuscates *some* of the potential hurdles from working with collections. In the long run, he should learn the various idiosyncrasies of the types but for now he seems to need to focus on what collections *can do* rather than getting stuck on *why* they do.

I think List<T> is quite easy to use, and can do just about every thing he likely *intentionally* is doing with the array.
 
Technically, Arrays in C# are a data structure and are not a collection in regards to .NET. They can be implicitly cast to an Array Class in .NET which does implement the ICollection interface. In terms of the .NET framework an int[] is not a Collection or ICollection.

Now, Mike if you want to say that arrays, such as int[], are a managed data type and not array in the true sense of how the C language would implement it, then you are correct. Arrays in C# are of course managed data types that provide bounds checking and other methods and useful properties such as .Length
 
Well it's a managed language and you get features such as bounds checking and garbage collection as part of the package.

Being able to use new[] {1,2,3}, List<int>() {1,2,3} and int[] {1,2,3} with Linq is very nice indeed.
 
mikeblas said:
How does a collection differ from a data structure that implements IEnumerable?
Click to expand...

Well if we are talking about ICollection then simply it provides the additional:

Properties
Count
IsSynchronized
SyncRoot

Methods
CopyTo

Since ICollection extends IEnumerable. But we are still just arguing over semantics in general which was my main point
 
mikeblas said:
How does a collection differ from a data structure that implements IEnumerable?
Click to expand...

Because ICollection inherits IEnumerable, not the other way around. (Though, to be fair, collections in the .NET framework have some Liskov violations)

List<T> has plenty of methods which are not defined by IEnumerable.
 
Zangmonkey said:
Because ICollection inherits IEnumerable, not the other way around. (Though, to be fair, collections in the .NET framework have some Liskov violations)

List<T> has plenty of methods which are not defined by IEnumerable.
Click to expand...

Which ones? How?
 
Zangmonkey said:
Are you asking which methods are exposed by List but not defined by IEnumerable? MSDN has an exhaustive page, but .add() for one....
Click to expand...

No no no, you said collections in .NET have Liskov violations. Can you be more specific? Which ones and how is it that they do not work? I'm having a hard time thinking of a violation here.
 
aL Mac said:
No no no, you said collections in .NET have Liskov violations. Can you be more specific? Which ones and how is it that they do not work? I'm having a hard time thinking of a violation here.
Click to expand...

ReadOnlyCollection inherits List, implements ICollection, throws on .Add and .Remove.
 
Zangmonkey said:
ReadOnlyCollection inherits List, implements ICollection, throws on .Add and .Remove.
Click to expand...

Hmm originally I agreed with you, but under careful look of the interfaces, I'm not so sure.

ReadOnlyCollection (which is new in the newest .NET 4.5) extends from List<T>. Therefore, it implements IList which does have a IsReadOnly property and clearly says that it throws a NotSupportedException if .Add and .Remove are used when it is read only. ICollection does not specify any add or remove methods (which IList extends)

It doesn't seem to be an unreasonable design to have a IsReadOnly property, but I do agree that the design is a bit strange. The ICollection interface isn't all that useful on its own. It's a bit weird that ReadOnlyCollection is actually a List. Also compare ICollection and ICollection<T>. ICollection<T> implements a lot more of the IList methods that make it more useful.

Anyway, I'm not sure that it is a good idea to have diverging inheritance paths either, for example, ICollection and IReadOnlyCollection. One post I saw suggested an IWriteable<T> and IReadable<T> and have IList implement both but that sounds like it could be more hassle than its worth. Hmm..
 
aL Mac said:
Hmm originally I agreed with you, but under careful look of the interfaces, I'm not so sure.

ReadOnlyCollection (which is new in the newest .NET 4.5) extends from List<T>. Therefore, it implements IList which does have a IsReadOnly property and clearly says that it throws a NotSupportedException if .Add and .Remove are used when it is read only. ICollection does not specify any add or remove methods (which IList extends)

It doesn't seem to be an unreasonable design to have a IsReadOnly property, but I do agree that the design is a bit strange. The ICollection interface isn't all that useful on its own. It's a bit weird that ReadOnlyCollection is actually a List. Also compare ICollection and ICollection<T>. ICollection<T> implements a lot more of the IList methods that make it more useful.

Anyway, I'm not sure that it is a good idea to have diverging inheritance paths either, for example, ICollection and IReadOnlyCollection. One post I saw suggested an IWriteable<T> and IReadable<T> and have IList implement both but that sounds like it could be more hassle than its worth. Hmm..
Click to expand...


ReadOnlyCollection exists in .NET4


I can accept that whether or not it's a liskov violation is debatable. I still contend it's awkward design because the same interface exposes a .Add() and a .IsReadOnly() when one is mutually exclusive to the other.

This is a relic of the fact that there are no ReadOnly interfaces for collections in the .NET framework as they added these collection types later.
The alternative would be new, standalone interfaces deriving from IEnumerable.... but anybody who had passed around IList or ICollection would have a codebreaking change, then.
 
You must log in or register to reply here.
Back
Top