• Timo Sirainen (9/9) Apr 19 2004 Is there a reason not to support const qualifier for pointers/objects? W...
• C. Sauls (10/11) Apr 19 2004 Already supported.
• Walter (13/16) Apr 19 2004 With C
• Matthew (16/32) Apr 20 2004 const

Timo Sirainen <Timo_member pathlink.com> writes:

Is there a reason not to support const qualifier for pointers/objects? With C
code I've found this to be really useful in function parameters as it clearly
tells the caller that the given parameter won't be modified.

Only reason I'm still using some #defined values in C code is that enum is
signed and can't handle values larger than INT_MAX. This is really needed in
code which accesses 32bit integer as a bitmask. How about adding support for
unsigned enum type? Looks like currently only possibility is to declare "static
const uint" variable which doesn't even seem to be optimized out of the binary..

Other than those I don't see a reason why I wouldn't use D one day.

"C. Sauls" <ibisbasenji yahoo.com> writes:

Timo Sirainen wrote:
 How about adding support for unsigned enum type?

Already supported.

------------------------------
enum : uint {
     SOME_CONST = 4294967294,
     ANOTHER_ONE
}
------------------------------

-C. Sauls
-Invironz

"Walter" <walter digitalmars.com> writes:

"Timo Sirainen" <Timo_member pathlink.com> wrote in message
news:c60vnh$o2d$1 digitaldaemon.com...
 Is there a reason not to support const qualifier for pointers/objects?

With C
 code I've found this to be really useful in function parameters as it

clearly
 tells the caller that the given parameter won't be modified.

There were a couple of long threads about this issue. The case against const
(which not everyone agrees with) is:

1) const types are not reliably constant, even in legal code
2) const as a type qualifier adds a lot of complexity to the language and
compiler
3) const adds a lot of unaesthetic 'noise' to declarations
4) in 15 years of using const, it has never found an actual bug (in my code,
anyway)

So, too much cost, too little benefit.

"Matthew" <matthew.hat stlsoft.dot.org> writes:

"Walter" <walter digitalmars.com> wrote in message
news:c61osu$2c17$1 digitaldaemon.com...
 "Timo Sirainen" <Timo_member pathlink.com> wrote in message
 news:c60vnh$o2d$1 digitaldaemon.com...
 Is there a reason not to support const qualifier for pointers/objects?

 With C
 code I've found this to be really useful in function parameters as it

 clearly
 tells the caller that the given parameter won't be modified.

 There were a couple of long threads about this issue. The case against

const
 (which not everyone agrees with) is:

You're not wrong!

 1) const types are not reliably constant, even in legal code

(As I've said inumerable times) They don't need to be.

 2) const as a type qualifier adds a lot of complexity to the language and
 compiler

I believe you on this point.

 3) const adds a lot of unaesthetic 'noise' to declarations

Don't agree. You could say that about D's template syntax, or char[], or
whatever. Any decent engineer just gets used to such things.


 4) in 15 years of using const, it has never found an actual bug (in my

code,
 anyway)

Hugely disagree. In 13 years of using const, it has found thousands of
potential bugs. Maybe you don't use the full power of const? (Incidentally,
in your reviews of "Imperfect C++", I never heard a murmur from you
regarding my strong use of const. Was this just to avoid a pointless debate,
or were you unwilling to admit the power of my argument? <G>)

 So, too much cost, too little benefit.

Much cost, huge benefit. But I know you're never going to go for it, so once
again I'll get my const rock out, and creep under.