Re: Boxing and Unboxing ??

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


Jon wrote:
Bruce Wood <brucewood@xxxxxxxxxx> wrote:

<snip>

Jesse, I think that you misunderstand. C++ has a concept of "const" by
which you can pass a reference type, but can indicate that none of its
fields can be changed.

To my knowledge, the C# team is considering such a construct, but they
still haven't figured out how to fit it cleanly into the language (and
possibly the CLR) taking into account security concerns, etc.

For what it's worth, this has been debated around Java for *ages* (well
before .NET came on the scene) - C# is moving somewhat quicker in
general, but there are certainly lots of thorny issues :(

Indeed. C++ sidesteps the problems by providing an un-cost-cast by
which you can remove the "constness" of something. In other words, C++
provides "const", but the language doesn't guarantee that none of the
called methods will modify the object. As such, "const" in C++ is more
a suggestion to the programmer that carries weight only if the
programmer decides to abide by it.

I believe that the C# team's concern is that they want a tight
contract: they want a "const" that guarantees "const", not just a
guideline for programmers.

As well, there's the ugly C++ cascading-const problem. As a programmer,
even if you want to abide by a "const" contract imposed upon you, it's
not uncommon to find yourself in the situation in which "if a is
'const' then that means that parameter b to function F must be 'const',
but then if that's 'const' then parameter c to function G must also be
'const', but then...." If you haven't carefully used 'const' throughout
your libraries and code from the very start, it can get ugly pretty
quickly. Doubly so if you buy a library from someone and _they_ haven't
bothered using 'const' everywhere they could.

Anyway, I trust the C# team to introduce this (very useful) feature
only when they have it sorted out and not before. As Anders Heljsberg
said, "It's easy to add new features to a language later; it's very
difficult to change them if you include them and then later decide that
you didn't get it right" or words to that effect. Wise man.

.

Relevant Pages

  • Re: Boxing and Unboxing ??
    ... still haven't figured out how to fit it cleanly into the language (and ... programmer decides to abide by it. ... even if you want to abide by a "const" contract imposed upon you, ... I trust the C# team to introduce this feature ...
    (microsoft.public.dotnet.languages.csharp)
  • OK to disguise a macro function as a function?
    ... functions to warn the programmer to be picky about what arguments they ... Currently I'm using an embedded systems compiler for programming ... because there's no stack (another strategy to save memory). ... the compiler is very particular about what it considers const. ...
    (comp.lang.c)
  • Re: Anders Hejlsberg comment on immutable objects
    ... >reasonably be expected to enfore the concept of 'const'. ... I expect it to enforce the concept of const, ... not to guarantee that a programmer provides a correct implementation. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Whats the deal with the "toupper" family?
    ... No matter what you think `const' means in this context, ... it's up to the programmer to pass the right value. ... and doesn't want to validate the string for such ... Under what circumstances will casting to unsigned char fail, ...
    (comp.lang.c)
  • Re: const argument
    ... > compiler optimized code and used the const qualifier as a hint. ... It serves as a hint to the compiler, "The programmer intends ... it enhances the readability of the code. ...
    (comp.lang.c)