const functions in C# ?

  • Thread starter Thread starter Chris
  • Start date Start date
C

Chris

Hi,

can you define const-functions in C# as in C++ ?

for example (C++-code) :

int Cube :: GetSide() const
{
return m_side;
}

Thnx

Christian
 
Chris said:
can you define const-functions in C# as in C++ ?

for example (C++-code) :

int Cube :: GetSide() const
{
return m_side;
}
Click to expand...

No. I don't know whether or not it's being considered. Const-ness can
be very useful, but it does require a fair amount of discipline.

You may well be interested in http://constcli.sscli.net/
 
What is the benifit of a const funtion ?
Click to expand...

On its own, not a lot - but when combined with the idea of a const
object or variable, it means you can have more safety. For instance,
suppose you maintain a byte array within a class, and you wish to make
that array available in a "read-only" kind of way - you could expose it
with a "const" property, which would mean that clients would have to
do:

const byte[] foo = myObject.MyProperty;

instead of

byte[] foo = myObject.MyProperty;

They then couldn't do

foo[0] = 5;

but they could do

byte x = foo[0];

It means you can basically return references to mutable objects, but
with the "const" modifier meaning that the client could only call
methods marked as "const" as well. (So for instance, in StringBuilder
ToString might be marked as "const", but Append wouldn't.)
 
isnt that why we have the readonly keyword? Setonce then its locked from
setting.



Jon Skeet said:
What is the benifit of a const funtion ?
Click to expand...

On its own, not a lot - but when combined with the idea of a const
object or variable, it means you can have more safety. For instance,
suppose you maintain a byte array within a class, and you wish to make
that array available in a "read-only" kind of way - you could expose it
with a "const" property, which would mean that clients would have to
do:

const byte[] foo = myObject.MyProperty;

instead of

byte[] foo = myObject.MyProperty;

They then couldn't do

foo[0] = 5;

but they could do

byte x = foo[0];

It means you can basically return references to mutable objects, but
with the "const" modifier meaning that the client could only call
methods marked as "const" as well. (So for instance, in StringBuilder
ToString might be marked as "const", but Append wouldn't.)
Click to expand...
 
isnt that why we have the readonly keyword? Setonce then its locked from
setting.
Click to expand...

No, readonly will make the *variable* readonly. It says nothing about
the object that the reference in that variable refers to (which is why
you can't mark a method as returning a "readonly" reference).
 
Hi Jon,
This is not the idea behind the const members of a class in c++. What you
are talking about is method returning const object.
When a method is declared as *const* (in a way Chris did it in his original
post) that means that this method won't modify anything, but its local
variables nor call any function which is not declared as *const* but it has
nothing to do with the constness of the returned object. It just guarantee
that the method itself will not change anything.

So to answer Chris's question: No, C# doesn't have *const* methods.

B\rgds
100

Jon Skeet said:
What is the benifit of a const funtion ?
Click to expand...

On its own, not a lot - but when combined with the idea of a const
object or variable, it means you can have more safety. For instance,
suppose you maintain a byte array within a class, and you wish to make
that array available in a "read-only" kind of way - you could expose it
with a "const" property, which would mean that clients would have to
do:

const byte[] foo = myObject.MyProperty;

instead of

byte[] foo = myObject.MyProperty;

They then couldn't do

foo[0] = 5;

but they could do

byte x = foo[0];

It means you can basically return references to mutable objects, but
with the "const" modifier meaning that the client could only call
methods marked as "const" as well. (So for instance, in StringBuilder
ToString might be marked as "const", but Append wouldn't.)
Click to expand...
 
100 said:
This is not the idea behind the const members of a class in c++. What you
are talking about is method returning const object.
When a method is declared as *const* (in a way Chris did it in his original
post) that means that this method won't modify anything, but its local
variables nor call any function which is not declared as *const* but it has
nothing to do with the constness of the returned object. It just guarantee
that the method itself will not change anything.
Click to expand...

But there are two things here - the method could be declared not to
change anything in the current object, *and* it could also be declared
to return a reference to an object which then can't be changed by the
client. In other words, if something returns const Foo, then only the
methods declared as const within Foo are available.

I don't think you get anything like the full benefit without both
halves.
 
"When a method is declared as *const* (in a way Chris did it in his
original
post) that means that this method won't modify anything but its local
variables, nor call any function which is not declared as *const* "
Click to expand...

That was my idea indeed about the const-function.

So, unfortunately it doesn't exits in C# ? too bad.

thanks to you all for your time though !!

Christian

100 said:
Hi Jon,
This is not the idea behind the const members of a class in c++. What you
are talking about is method returning const object.
When a method is declared as *const* (in a way Chris did it in his original
post) that means that this method won't modify anything, but its local
variables nor call any function which is not declared as *const* but it has
nothing to do with the constness of the returned object. It just guarantee
that the method itself will not change anything.

So to answer Chris's question: No, C# doesn't have *const* methods.

B\rgds
100

Jon Skeet said:
What is the benifit of a const funtion ?
Click to expand...

On its own, not a lot - but when combined with the idea of a const
object or variable, it means you can have more safety. For instance,
suppose you maintain a byte array within a class, and you wish to make
that array available in a "read-only" kind of way - you could expose it
with a "const" property, which would mean that clients would have to
do:

const byte[] foo = myObject.MyProperty;

instead of

byte[] foo = myObject.MyProperty;

They then couldn't do

foo[0] = 5;

but they could do

byte x = foo[0];

It means you can basically return references to mutable objects, but
with the "const" modifier meaning that the client could only call
methods marked as "const" as well. (So for instance, in StringBuilder
ToString might be marked as "const", but Append wouldn't.)
Click to expand...
Click to expand...
 
I don't think you get anything like the full benefit without both
halves.
Click to expand...

Disagree. The fact that I'm calling *const* doesn't necessarily mean that I
don't want to change the returned object as well as the fact that the class
provides a method that is not *const* doesn't necessarily mean that the
returned value has to be changeable.
For example Clone method can be decalred as *const*. As user of this method
it gives me peace of
mind that this method won't change anything. As programmer it helps me to
avoid errors. Anyway it returns copy that the user can change.
Or if operators -- and ++ were prototyped as *const* methods. Errors like
"not creating new object but altering the one passed via method parameter"
will not occur. It doesn't mean though that the returned object cannot be
changed.

B\rgds
100
 
100 said:
Disagree. The fact that I'm calling *const* doesn't necessarily mean
that I don't want to change the returned object as well as the fact
that the class provides a method that is not *const* doesn't
necessarily mean that the returned value has to be changeable.
Click to expand...

But isn't the whole point of const methods and methods returning const
references to allow that decision to be made by the designer, not the
user?

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)
 
Hi Frank,
But isn't the whole point of const methods and methods returning const
references to allow that decision to be made by the designer, not the
user?
Click to expand...
Returning *const* object the designer force not changing the object. But my
point is that const method has nothing to do with returning const object.
The retuned object from *const* method might be *const*, but doesn't have to
be.

From the users point of view method declared as *const* has more informative
meaning.

For method returning *const* - Yes, designer makes the desicion. And that is
what Jon was talking about.
But the question was about the *const* methods. And with *const* methods
designer doesn't make any desicions about the returned object.

B\rgds
100
 
100 said:
Disagree. The fact that I'm calling *const* doesn't necessarily mean that I
don't want to change the returned object as well as the fact that the class
provides a method that is not *const* doesn't necessarily mean that the
returned value has to be changeable.
Click to expand...

You don't have to have both halves in the same *method*, and I never
suggested that you did.
For example Clone method can be decalred as *const*. As user of this method
it gives me peace of mind that this method won't change anything.
Click to expand...

That can be done with documentation though - the main benefit of
constness (IMO) is getting the compiler to notice that something you've
said won't change genuinely won't, and making sure you don't try to
change something you shouldn't do.
As programmer it helps me to avoid errors.
Click to expand...

How, if the compiler isn't going to enforce anything? Without both
halves, the compiler hasn't *got* anything to enforce.
Anyway it returns copy that the user can change.
Or if operators -- and ++ were prototyped as *const* methods. Errors like
"not creating new object but altering the one passed via method parameter"
will not occur. It doesn't mean though that the returned object cannot be
changed.
Click to expand...

No, and that's why I've said, they're separate things - but I *do*
believe you don't get much benefit unless both parts are available.
 
100 said:
Returning *const* object the designer force not changing the object. But my
point is that const method has nothing to do with returning const object.
Click to expand...

Yes it does - because when you've had a const object reference returned
to you, you should only be able to call const methods.
The retuned object from *const* method might be *const*, but doesn't have to
be.
Click to expand...

And no-one's claimed that it does.
From the users point of view method declared as *const* has more informative
meaning.

For method returning *const* - Yes, designer makes the desicion. And that is
what Jon was talking about.
But the question was about the *const* methods. And with *const* methods
designer doesn't make any desicions about the returned object.
Click to expand...

Yes - but any explanation of const methods which doesn't also include
how const variables/objects/references (I'm not so hot on the exact
terminology here) come about in the first place, which will often
include a method returning a const object reference, is incomplete IMO.
You seem to think I'm conflating the two ideas, and I'm not - but to
say they have "nothing to do" with each other is wrong, IMO.
 
From the users point of view method declared as *const* has more
informative
Yes - but any explanation of const methods which doesn't also include
how const variables/objects/references (I'm not so hot on the exact
terminology here) come about in the first place, which will often
include a method returning a const object reference, is incomplete IMO.
You seem to think I'm conflating the two ideas, and I'm not - but to
say they have "nothing to do" with each other is wrong, IMO.
Click to expand...

If the question was about the const variables or reference to const objects
(or in terms of c++ const variables, const members or pointers and
references to const objects) - yes, you should say something about const
methods as long as those are the only methods of the object that can be
called. But talking about *const* methods we may not mention const
variables, etc because those methods may use any type of variables and
members. They are not limited to access const fields or (as we both agree)
of returning const objects only.

B\rgds
100
 
100 said:
If the question was about the const variables or reference to const objects
(or in terms of c++ const variables, const members or pointers and
references to const objects) - yes, you should say something about const
methods as long as those are the only methods of the object that can be
called. But talking about *const* methods we may not mention const
variables, etc because those methods may use any type of variables and
members. They are not limited to access const fields or (as we both agree)
of returning const objects only.
Click to expand...

They're not *limited* to accessing const fields or returning const
objects, but I would argue that one of the great benefits of const
methods is that you can "label" methods which are safe to call on
objects which you don't really own - and that the compiler can check
that. The compiler *can't* check that, however, if you don't have any
concept of const variables to start with.
 
<snip>

Looking back at some of my previous posts, I certainly gave less-than-
great examples - a better example would be something like Hashtable,
where the CopyTo method could be const, but Clear wouldn't be. A method
in a user class may wish to return a const Hashtable reference, which
could then only have const methods (such as CopyTo) invoked on it.
 
Hi Jon,
Looking back at some of my previous posts, I certainly gave less-than-
great examples - a better example would be something like Hashtable,
where the CopyTo method could be const, but Clear wouldn't be. A method
in a user class may wish to return a const Hashtable reference, which
could then only have const methods (such as CopyTo) invoked on it.
Click to expand...

That is better ;) I agree in 100% with this example.
My point is that we hardly can have const objects beside the primitive ones
(which are used as litterals and .NET already has) without the consept of
const methods. But we can still have const methods without the concept of
const objects. Of course it is better to have them both.
Anyway I'm kind of sceptic about this in .NET since all languages in the
familiy would have supported them. Otherwise reusing code written in a
language, which has this concept from code, which doesn't, would either
compromise the const-ness or wouldn't be able to reuse the code.

B\rgds
100
 
100 said:
That is better ;) I agree in 100% with this example.
My point is that we hardly can have const objects beside the primitive ones
(which are used as litterals and .NET already has) without the consept of
const methods. But we can still have const methods without the concept of
const objects. Of course it is better to have them both.
Click to expand...

Right :)
Anyway I'm kind of sceptic about this in .NET since all languages in the
familiy would have supported them. Otherwise reusing code written in a
language, which has this concept from code, which doesn't, would either
compromise the const-ness or wouldn't be able to reuse the code.
Click to expand...

True - I hadn't thought of that. This is the kind of thing which makes
a multi-language platform tricky... but the same is true of generics,
presumably.
 
True - I hadn't thought of that. This is the kind of thing which makes
a multi-language platform tricky... but the same is true of generics,
presumably.
Click to expand...

I haven't had time to go through the c#'s generics specs. So I can't tell
anything about it.
But you are right a multi-language platform could be indeed very tricky.

B\rgds
100
 
Back
Top