Constant arrays in C#

[Michel Andr?]

Whats the reasoning for not being able to instantiate const arrays in
C# or have I missed something

void Foo()
{
const int i = 0;
const string str = "s";

// error CS0133: The expression being assigned to 'intArray' must be
constant
const int[] intArray = { 1,2,3 };
const string[] strArray = { "1","2","3" };
}

My solutin which isn't as elegant is to use at class scope
static readonly string[] _strArray = { "1","2","3" };

I can't reinitialize the array but _strArray[0] will change the
contents.

This is easy enough to do in C++ eg.

Regards
/m

 

[Bogdan Lachendro]

Whats the reasoning for not being able to instantiate const arrays in
C# or have I missed something

void Foo()
{
const int i = 0;
const string str = "s";

// error CS0133: The expression being assigned to 'intArray' must be
constant
const int[] intArray = { 1,2,3 };
const string[] strArray = { "1","2","3" };
}

My solutin which isn't as elegant is to use at class scope
static readonly string[] _strArray = { "1","2","3" };

I can't reinitialize the array but _strArray[0] will change the
contents.

From MSDN:

"A constant expression is an expression that can be fully evaluated at
compile time. Therefore, the only possible values for constants of
reference types are string and null."

 

[Michel Andr?]

From MSDN:

"A constant expression is an expression that can be fully evaluated at
compile time. Therefore, the only possible values for constants of
reference types are string and null."

I realize this and read it to. I just cant understand it since
constant objects come in quite handy often, both since they cannot be
misstakenly change and their construction can be obtimized, compiled
beforehand. But I guess it's my C++ mindset shining trough . I
actually miss const methods and objects as well, since the only way of
knowing noone will tinker with an objects state that I own is cloning
just in case somebody might change the state or depend that the user
clones the object if they change the state and how can they know what
state changes if that isn't marked (another of those C++ isms i miss).

/Michel

 

[AlexS]

This refers to reference types. They are different from value types. Please
check
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csspec/html/vclrfcsharpspec_4.asp

and following sections. They explain the difference.

If you want to monitor for changes in referenced objects, I think properties
can help you to avoid cloning. You can always monitor where from call
originates and use declarative or security on methods. I would suggest to
check
http://msdn.microsoft.com/library/d...n-us/cpguide/html/cpconcodeaccesssecurity.asp

As about const methods, possibly you should take a look at static methods /
properties. If I remember properly what is const method ;-))

HTH
Alex

 

[Michel Andr?]

This refers to reference types. They are different from value types. Please

check
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csspec/html/vclrfcsharpspec_4.asp

and following sections. They explain the difference.

I know the difference between a value type and a reference type. In
C++ it can be implemented more effiecient than in C# .NET CLR type
languages. And you don't have to sacrifice the one for the other at
design time as you have in C# where you choose value and ref by
interchanging struct and class. In C++ you have to decide if you want
an value or ref class, if you implement a value class by
implementening assignment,copy and destructory correctly you still can
pass the class by reference in a function call or return and then
decide at the caller site if you want to clone the value (calling a
non const function) or just "read" state. In C# and managed C++ you
decide up front as I understand it.

If you want to monitor for changes in referenced objects, I think properties
can help you to avoid cloning. You can always monitor where from call
originates and use declarative or security on methods. I would suggest to
check
http://msdn.microsoft.com/library/d...n-us/cpguide/html/cpconcodeaccesssecurity.asp

Using properties is a runtime check incurring runtime overhead and
failures, const correctnes can be verified at compile time in C++ and
makes it a lot faster than a runtime check each time you access the
property/method.

As about const methods, possibly you should take a look at static methods /
properties. If I remember properly what is const method ;-))

Static methods and const methods are not the same. A const method in
C++ can't change the state of an object but can read the state and
calculate return values and such from the state. And a static method
don't have access to the state of an object neither in C++ or C# they
are the same.

/Regards
Michel

 

[Jeff Louie]

Well you could wrap a reference with private visiblility in a class and
provide only read only methods.... or pass immutable objects.

Regards,
Jeff

I actually miss const methods and objects as well, since the only way

of
knowing noone will tinker with an objects state that I own is cloning
just in case somebody might change the state or depend that the user
clones the object if they change the state and how can they know what
state changes if that isn't marked (another of those C++ isms i miss).<

 

[Jon Skeet [C# MVP]]

Using properties is a runtime check incurring runtime overhead and
failures, const correctnes can be verified at compile time in C++ and
makes it a lot faster than a runtime check each time you access the
property/method.

Properties don't always involve a runtime overhead at all - usually
they'll be inlined into the same native code, especially if they're
very simple ones.

 

[Michel Andr?]

Well you could wrap a reference with private visiblility in a class and
provide only read only methods.... or pass immutable objects.

How do you pass immutable objects? Or do you mean implementing a class
wrapper with readonly access. It means duplicating code but I think it
would work.

/Michel

 

[Michel Andr?]

Properties don't always involve a runtime overhead at all - usually
they'll be inlined into the same native code, especially if they're
very simple ones.

But according to the reply I should use declarative code security and
monitor where calls come from and these checks must certainly be done
at runtime and incur an overhead. And adding declarative properties to
property accessor or making more advanced setters will make the chance
of inlining smaller.

/Michel

 

[Jeff Louie]

Hi Michel.... A class wrapper with read only access is one way to go, so
called "containment by reference".

http://www.geocities.com/jeff_louie/OOP/oop7.htm

The use of immutable objects requires a different approach to
programming. Most of use like to reuse code in memory so we write
mutable classes. This may not be the best approach in C# or Java. A
reference is "Effective Java" by Guy Steele Item 13 "Favor
Immutability."

So if you have a class that performs a complex calculation, that class
can
provide a method that returns an immutable result object (no getters) or
in C# a user defined structure.

http://www.geocities.com/jeff_louie/OOP/oop11.htm

Regards,
Jeff

How do you pass immutable objects? Or do you mean implementing a

class wrapper with readonly access. It means duplicating code but I
think
it would work.<

 

[Jeff Louie]

Argh. Methinks I mean no setters.

Regards,
Jeff

 

[Jon Skeet [C# MVP]]

But according to the reply I should use declarative code security and
monitor where calls come from and these checks must certainly be done
at runtime and incur an overhead.

No, the reply said you *could* do that if you needed to, not that you
*do* need to.

And adding declarative properties to
property accessor or making more advanced setters will make the chance
of inlining smaller.

Yup - but for the most part, just adding the property would be enough
to give read-only access.

I agree that it's a problem, and I would like some way of letting the
compiler know that an array itself should be viewed as being readonly
rather than just the reference - I was merely trying to get away from
the idea that having a property always made things slower.