Declaring a constant

[Chris Saunders]

I have made a declaration like this:

private const Complex I = new Complex(0.0, 1.0);

When I try to build this I get the error:

The expression being assigned to 'ComplexNumberLib.ComplexMath.I' must be
constant.

I do not understand why this constructor is not considered to be constant
nor how
to correct this error. (Just learning C#)

Regards
Chris Saunders

 

[Randy A. Ynchausti]

Chris,

I have made a declaration like this:

private const Complex I = new Complex(0.0, 1.0);

When I try to build this I get the error:

The expression being assigned to 'ComplexNumberLib.ComplexMath.I' must be
constant.

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.

Regards,

Randy

 

[Guest]

Hi Chris,
a constant expression needs to be something that can be evaluated at
compile time, so you can only use consts with value types not reference types
(apart from string which is a little bit different and null).

If you want to have a non changeable reference type use the readonly keyword
instead.

Hope that helps
Mark Dawson
http://www.markdawson.org

 

[Guest]

Did you write the code for Complex? If so, can you provide the code for the
constructor you're calling?

 

[Vladimir Matveev]

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.

Possibly you need "readonly" field

 

[Marc Gravell]

And if you *did* write this code, then note that Complex should probably be
a value-type (struct), not a reference type (class); this would solve this
problem, plus allow for value-type symantecs, which is what people probably
expect from a complex (or quarternian for that matter) number.

Marc

 

[Vladimir Matveev]

Even if Compex type shall be changed from "class" to "struct" it will
not solve the problem.

Constant expression is evaluated in compile time and embedded into IL
code and it is impossible for complex data structures

C# language specification
7.15 Constant expressions
A constant-expression is an expression that can be fully evaluated at
compile-time.
constant-expression:
expression
The type of a constant expression can be one of the following: sbyte,
byte, short, ushort, int, uint, long, ulong, char, float, double,
decimal, bool, string, any enumeration type, or the null type

 

[Chris Saunders]

My thanks for the many responses.
Particularily Vladimir Matveev since you led me to
the specification - which I will read.
I have just been learning C# for a couple of days now
and was just writing the Complex class as a way to
learn.
One person suggested that I should use a struct and I
will give that option a try - don't know C# well enough
yet to understand the implications.
I am mostly accustomed to Eiffel which is quite different -
in Eiffel you can make a class a value type.

Anyways, many thanks for the help.

Regards
Chris Saunders

 

[Marc Gravell]

Fair enough;

</retract> ;-p

Marc

 

[Marc Gravell]

Phew... you saved my dignity there by vindicating at least *part* of my
previous post ;-p

IMO, yes, you should be using a struct for this; an alternative would be an
*immutable* class (e.g. one where all the fields are formally readonly and
the class is marked [Immutable]) - otherwise you could get some very
unexpected results, particularly if two objects have a Complex property, and
the same Complex instance is assigned to both; when one of them updates the
object (e.g. adds 2 to the real part), then the value would appear to change
for *both* objects that hold it, which is probably not what is intended.

Marc

 

[Jon Skeet [C# MVP]]

Fair enough;

</retract> ;-p

Well, before you retract it - if you have a readonly value type, that's
largely "good enough" (not the same as const, but quite close). The
same can be achieved with a reference type, but you need to make sure
that the reference type is immutable, as otherwise clients can change
the "constant". (This is a major issue when people make readonly arrays
- the array reference itself is readonly, but the contents can be
changed.)

Jon

 

[Marc Gravell]

revision: [System.ComponentModel.ImmutableObject(true)]

(not [Immutable])

 

[Nick Hounsome]

Well, before you retract it - if you have a readonly value type, that's
largely "good enough" (not the same as const, but quite close). The
same can be achieved with a reference type, but you need to make sure
that the reference type is immutable, as otherwise clients can change
the "constant". (This is a major issue when people make readonly arrays
- the array reference itself is readonly, but the contents can be
changed.)

Jon

It is my hope that one day the whole world will realize that leaving out C++
const is too high a price to pay for extra compatibility with other
languages.

 

[Jon Skeet [C# MVP]]

It is my hope that one day the whole world will realize that leaving out C++
const is too high a price to pay for extra compatibility with other
languages.

I go back and forth on this. One of the troubles with C++ const is that
you can cast it away, which reduces its value significantly - but means
you don't need to get everything right to start with. Another is in
terms of expressing concepts succinctly. Presumably I should be able to
have const string[] and (const string)[] and them be different things -
bring generics in and it gets even worse.

Now, this sounds very negative, but I feel the pain too - I would
really like some way of indicating that something *won't* change an
object significantly, or that an object *can't* be changed, etc.

I suspect people will work out a way of doing this cleanly some time. I
also suspect that it's too late to ever put it into .NET - to be
effective, it would have to pervade the existing libraries, and that
would be horrific in terms of backward compatibility, I suspect.

Jon

 

[Nick Hounsome]

I go back and forth on this. One of the troubles with C++ const is that
you can cast it away,

But the whole beauty of having it in .NET is that you couldn't cast it away.

which reduces its value significantly - but means
you don't need to get everything right to start with.

I've never found it difficult.

Another is in
terms of expressing concepts succinctly. Presumably I should be able to
have const string[] and (const string)[] and them be different things -
bring generics in and it gets even worse.

simplify using typedefs - another omission and one that it would cost
nothing to add. (of course your example is not relevant to C# cos is const
anyway)

Now, this sounds very negative, but I feel the pain too - I would
really like some way of indicating that something *won't* change an
object significantly, or that an object *can't* be changed, etc.

I hate having to write wrappers to ensure constness and I hate it that I
have to do runtime checks to see whether the IList i'm passed is readonly or
not.

You can get around the problem by going down the IConstList path but nobody
does because you need too many interfaces.

I suspect people will work out a way of doing this cleanly some time. I
also suspect that it's too late to ever put it into .NET - to be
effective, it would have to pervade the existing libraries, and that
would be horrific in terms of backward compatibility, I suspect.

Jon

I think you'll find that its those VB programmers who are the source of the
problem (Although that wouldn't explain java)

 

[Jon Skeet [C# MVP]]

Nick Hounsome wrote:

I think you'll find that its those VB programmers who are the source of the
problem (Although that wouldn't explain java)

I disagree on the cause - partly coming from a Java background, where
this has been a fairly lively topic for discussion for years.

Have a look at
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4211070
for views on both sides. (I haven't read the whole thing.)

As I said, I'd love to see a solution to this, but I can't see it being
part of .NET itself. Maybe .NET's successor...

Jon