By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,727 Members | 768 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,727 IT Pros & Developers. It's quick & easy.

What is the alternative to lack of C++ style "const" in C#

P: n/a
There are many threads on the lack of a true unmanaged C++ const like
behavior in C# (.Net) and that's not what this topic is about. The
topic is, what is the best practical way to live with it.

Some developers feel any function that returns an object should copy
it. This gets pretty expensive performance wise and development wise
and hard to enforce. It also defeats a lot of what C# intentionally
did.

Other developers feel you should build your own protection. This has
good performance but again. This is a high development cost to add to
all your objects and on a large team with faces coming and going and
wide range of experience, pretty hard to enforce.

The last option is, screw it, and don't worry about it. You'll create
more bugs or performance issues by trying to fix it than the problem
(lake of protection) will likely cause. Super critical objects could
be manually protected as needed. Hopefully good design will avoid most
issues.

What is your thoughts and practices?

Nov 17 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
mswlogo,

Not to be flippant, but I take option #3 (screw it). While I do see the
practical application of const in C++, the fact that you can just cast it
away made the statement (in my eyes) pretty worthless.

Also, I'm a strong believer in the last statement in option #3, that
good design will alleviate this in most cases (of course not all, but that's
the ideal).
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"mswlogo" <ms*****@hotmail.com> wrote in message
news:11*********************@g43g2000cwa.googlegro ups.com...
There are many threads on the lack of a true unmanaged C++ const like
behavior in C# (.Net) and that's not what this topic is about. The
topic is, what is the best practical way to live with it.

Some developers feel any function that returns an object should copy
it. This gets pretty expensive performance wise and development wise
and hard to enforce. It also defeats a lot of what C# intentionally
did.

Other developers feel you should build your own protection. This has
good performance but again. This is a high development cost to add to
all your objects and on a large team with faces coming and going and
wide range of experience, pretty hard to enforce.

The last option is, screw it, and don't worry about it. You'll create
more bugs or performance issues by trying to fix it than the problem
(lake of protection) will likely cause. Super critical objects could
be manually protected as needed. Hopefully good design will avoid most
issues.

What is your thoughts and practices?

Nov 17 '05 #2

P: n/a
I would go for the 'screw it' approach.

Happy Screwing
- Michael S
"mswlogo" <ms*****@hotmail.com> wrote in message
news:11*********************@g43g2000cwa.googlegro ups.com...
There are many threads on the lack of a true unmanaged C++ const like
behavior in C# (.Net) and that's not what this topic is about. The
topic is, what is the best practical way to live with it.

Some developers feel any function that returns an object should copy
it. This gets pretty expensive performance wise and development wise
and hard to enforce. It also defeats a lot of what C# intentionally
did.

Other developers feel you should build your own protection. This has
good performance but again. This is a high development cost to add to
all your objects and on a large team with faces coming and going and
wide range of experience, pretty hard to enforce.

The last option is, screw it, and don't worry about it. You'll create
more bugs or performance issues by trying to fix it than the problem
(lake of protection) will likely cause. Super critical objects could
be manually protected as needed. Hopefully good design will avoid most
issues.

What is your thoughts and practices?

Nov 17 '05 #3

P: n/a
Screw it.

There are times when it is nice to design a system with many overriding
ideals in place, however often when you do so as you said in point 1, you end
up costing yourself a lot for not a lot of actual benefit.

When coding, I often keep MacLennan's Language Principles
(http://csis.pace.edu/~bergin/slides/Maclennan.html) in mind, especially in
cases like this, #6 comes into play "Localized Cost: Users should only pay
for what they use; avoid distributed costs." Where needed a new instance will
be returned, otherwise it’ll just be a reference, and in either case, such
ends up being well documented... granted this does kind of violate #15.

Brendan
"mswlogo" wrote:
There are many threads on the lack of a true unmanaged C++ const like
behavior in C# (.Net) and that's not what this topic is about. The
topic is, what is the best practical way to live with it.

Some developers feel any function that returns an object should copy
it. This gets pretty expensive performance wise and development wise
and hard to enforce. It also defeats a lot of what C# intentionally
did.

Other developers feel you should build your own protection. This has
good performance but again. This is a high development cost to add to
all your objects and on a large team with faces coming and going and
wide range of experience, pretty hard to enforce.

The last option is, screw it, and don't worry about it. You'll create
more bugs or performance issues by trying to fix it than the problem
(lake of protection) will likely cause. Super critical objects could
be manually protected as needed. Hopefully good design will avoid most
issues.

What is your thoughts and practices?

Nov 17 '05 #4

P: n/a

"Brendan Grant" <gr****@NOSPAMdahat.com> wrote in message
news:9A**********************************@microsof t.com...
When coding, I often keep MacLennan's Language Principles
(http://csis.pace.edu/~bergin/slides/Maclennan.html) in mind,


Thanks for the link. I like what I read.

- Michael S
Nov 17 '05 #5

P: n/a
In a multi threaded situation I would consider using immutable objects.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***
Nov 17 '05 #6

P: n/a
Nicholas,

Of course one can cast const away, but it can only be done explicitely
(const_cast, or _deprecated_ C-style cast). If it is intentional then there
is no problem with encapsulation (like friend) or constness.

The lack of const in C# has the result that the implementor of an interface
has to enforce constness, by either using readonly properties, or copying
objects. But it is hard to enfore though IMO. One could for instance use
enumeration interface to expose collections, so that a user cannot change
contents of the collection.

Cheers,
--
Tom Tempelaere.
"Nicholas Paldino [.NET/C# MVP]" wrote:
mswlogo,

Not to be flippant, but I take option #3 (screw it). While I do see the
practical application of const in C++, the fact that you can just cast it
away made the statement (in my eyes) pretty worthless.

Also, I'm a strong believer in the last statement in option #3, that
good design will alleviate this in most cases (of course not all, but that's
the ideal).
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"mswlogo" <ms*****@hotmail.com> wrote in message
news:11*********************@g43g2000cwa.googlegro ups.com...
There are many threads on the lack of a true unmanaged C++ const like
behavior in C# (.Net) and that's not what this topic is about. The
topic is, what is the best practical way to live with it.

Some developers feel any function that returns an object should copy
it. This gets pretty expensive performance wise and development wise
and hard to enforce. It also defeats a lot of what C# intentionally
did.

Other developers feel you should build your own protection. This has
good performance but again. This is a high development cost to add to
all your objects and on a large team with faces coming and going and
wide range of experience, pretty hard to enforce.

The last option is, screw it, and don't worry about it. You'll create
more bugs or performance issues by trying to fix it than the problem
(lake of protection) will likely cause. Super critical objects could
be manually protected as needed. Hopefully good design will avoid most
issues.

What is your thoughts and practices?


Nov 17 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.