Sometime you might want to protect your data in memory – the greatest example is when dealing with anything related to passwords. It is simply not smart to keep that data around in a plain-text. In .NET there are multiple methods you can use for this purpose, starting with SecureString, ProtectedMemory, and my favorite ProtectedData.…
via: Found this via +Ilya S a post from +Josip Medved – Stuff like this should be way built into an OS, and RTL’s should have a secureMalloc()… – Joe C. Hecht – Google+
Empty arrays are not used often as arrays usually are about the presence data, not about the absence.
Here are two ways based on the int data type in C# (the original [WayBack] examples [WayBack] are using string, but since string itself is also a kind of array…):
Specify a size of zero:
int[] a = new int[0];
Specify an empty initialisation:
int[] a = new int[] { };
Though many people think arrays are a thing of the past, I think it is one of the first generic types and have their place. For one, enumerating over arrays using foreach is a lot faster in many environments than enumerating over other data types. Another thing is that the fixed nature of arrays can be very beneficial in setting constraints.
It comes down to these cases for XML elements having maxOccurs="1" (which the default for maxOccurs):
adding nillable="true" will convert from a regular type to a nullable type.
adding minOccurs="0" will add boolean …Specified properties in the generated C# for each element.
you can have both nillable="true" and minOccurs="0" in an element which gets you a nullable type and a …Specified property.
Note I’m not considering fixed or default here, nor attributes (that have use instead of minOccurs/maxOccurs, but do not allow for nillable) nor larger values of maxOccurs (which both xsd.exe and xsd2code regard as unbounded).
From the above, XML has a richer type system than C#, so in XML there are subtle a differences between:
an explicit nil in the XML element
the XML element being absent
the XML element being empty.
Hopefully later more text and examples to show how to actually work with this.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters