www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Writing C in D

reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
One aspect of D that is nice (or at least flexible ?)
is that you can write programs in ancient C style...

Without using objects, and without using exceptions,
garbage collection and other such modern facilities :-)


All you need to do is provide hooks for a few required
aspects of Phobos, such as GC and assert / OutOfMemory.


 import std.c.stdio;
 import std.c.stdlib;
 
 int main(char[][] args)
 {
     printf("Hello, World!\n");
     return EXIT_SUCCESS;
 }
 
 extern (C) void _d_OutOfMemory()
 {
     fprintf(stderr,"Out of memory!\n");
     exit(1);
 }
 
 extern (C) void _d_assert(char[] filename, uint line)
 {
     fprintf(stderr,"%s:%u: failed assertion\n",
             cast(char *) filename, line);
     exit(1);
 }


And such "C" code should compile with the regular
D too (with regular asserts and exceptions and GC) ?


A no-GC patch for Phobos (0.110) can be found here:
http://svn.dsource.org/svn/projects/bindings/trunk/
(coded by James Dunne, as posted on this NG earlier)

Of course, you would then have to 'delete' things
yourself - or face the wrath of the memory leaks...
(or to really get in the spirit, use malloc/free)


But you *can*. If you want to. (no flames, please)

--anders
Mar 05 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 05 Mar 2005 11:29:33 +0100, Anders F Björklund wrote:


 One aspect of D that is nice (or at least flexible ?)
 is that you can write programs in ancient C style...
 
 Without using objects, and without using exceptions,
 garbage collection and other such modern facilities :-)
 
 
 All you need to do is provide hooks for a few required
 aspects of Phobos, such as GC and assert / OutOfMemory.
 

 import std.c.stdio;
 import std.c.stdlib;
 
 int main(char[][] args)
 {
     printf("Hello, World!\n");
     return EXIT_SUCCESS;
 }
 
 extern (C) void _d_OutOfMemory()
 {
     fprintf(stderr,"Out of memory!\n");
     exit(1);
 }
 
 extern (C) void _d_assert(char[] filename, uint line)
 {
     fprintf(stderr,"%s:%u: failed assertion\n",
             cast(char *) filename, line);
     exit(1);
 }


 
 And such "C" code should compile with the regular
 D too (with regular asserts and exceptions and GC) ?
 
 
 A no-GC patch for Phobos (0.110) can be found here:
 http://svn.dsource.org/svn/projects/bindings/trunk/
 (coded by James Dunne, as posted on this NG earlier)
 
 Of course, you would then have to 'delete' things
 yourself - or face the wrath of the memory leaks...
 (or to really get in the spirit, use malloc/free)
 
 
 But you *can*. If you want to. (no flames, please)


I agree with you that this is also a strength of D.

Sometimes, OOP-everything is just overkill. 

-- 
Derek Parnell
Melbourne, Australia
5/03/2005 9:35:56 PM
Mar 05 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


One aspect of D that is nice (or at least flexible ?)
is that you can write programs in ancient C style...




[...]

But you *can*. If you want to. (no flames, please)


 
 I agree with you that this is also a strength of D.
 
 Sometimes, OOP-everything is just overkill. 


With a better standard library (or perhaps a 3rd party one),
it shouldn't be that hard to use D as a "native Java", either...

D has more features in common with Java than what eg. C++ has,
and should actually be pretty straight-forward with some docs.


Like many others, I think that C++ is a more "complete" language.
At least more mature, and with a lot more libraries and support ?


(like strings, garbage collection and unit tests, as Walter states)


And this is where D shines. As a "simpler C++", or C/Java crossover.
Buy maybe I'll get more respect for C++ after reading Matthew's book ?

--anders

PS. Some people make a religion out of hating OO programming,
     especially: http://www.geocities.com/tablizer/oopbad.htm
     And vice-versa... I'm finding *both* to be useful, myself.
     (since D supports both, this NG is not the place for a war)
Mar 05 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d0c4jb$fth$1 digitaldaemon.com...

 Like many others, I think that C++ is a more "complete" language.


I don't really understand why. As a *language*, what does C++ have over D?
Implicit function template instantiation. It's hard to find much else.


 At least more mature, and with a lot more libraries and support ?


That, I'll concede. It certainly ought to be more mature, being over 20
years old <g>. And certainly, with all the companies doing C++ tools, there
are more libraries and support.



 (like strings, garbage collection and unit tests, as Walter states)


C++ is significantly deficient for the reasons you list. I'll add UTF and
contracts as other areas where C++ falls short.
Mar 06 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:


Like many others, I think that C++ is a more "complete" language.


 
 I don't really understand why. As a *language*, what does C++ have over D?
 Implicit function template instantiation. It's hard to find much else.


D has some "simplified" versions of C++ features, like inout instead of
reference params, simplified const handling (storage instead of type),
etc, and I guess I'd have more examples if I had been using C++ more...
And this makes C++ more "complete" in that you can do more things,
but is also makes a lot harder and complex - at least at the start ?

I'll let the C++ experts fill in their own pet peeves about D 1.0.
(as I've said before, my own experience is with C and with Java)



(like strings, garbage collection and unit tests, as Walter states)


 
 C++ is significantly deficient for the reasons you list. I'll add UTF and
 contracts as other areas where C++ falls short.


Currently D also falls a little short on contracts and unittests,
compared to e.g. Eiffel and Java for instance, but it is definitely
on the right path there! And doxygen fills up for the "missing Javadoc"

Anyway, I have never really liked C++. With D, maybe I won't have to ?
Although if I started a complex project today, I would probably use C++
(if C or Java wasn't enough). Just hoping that tomorrow, I can use D...

--anders
Mar 06 2005
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d0gu9k$1n20$2 digitaldaemon.com...

 Walter wrote:


Like many others, I think that C++ is a more "complete" language.


 I don't really understand why. As a *language*, what does C++ have over D?
 Implicit function template instantiation. It's hard to find much else.




    const

    references

    bool

    namespaces

    compile-time testing (none of that hideous runtime generic comparison filth)

    TMP

    macro pre-processor

    'using'

    operators that look like operators

    compilers that warn

    proper cast operators, and the ability to fill the gaps in the spectrum
with user defined types

    support for shims (implicit template instantiation coupled with ability to
manipulate names in global/specific 
namespaces)

    lack of GC

    ability to produce extremely small applications (i.e. supports extremely
low coupling, and allows one to dispense 
with C/C++ Runtime Library)

    etc. etc. etc.

(For the record, I'm writing std.openrj right now, in 100% D, and enjoying it
for the most part. But it is *not* 
unalloyed tra-la-la-ing in wonderland ...)

Matthew
Mar 07 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:


I don't really understand why. As a *language*, what does C++ have over D?







     bool


D has 'bool' now, right ? A built-in type that only holds true/false.

Or did you mean boolean semantics with for instance conditionals ?
I know that D has the same booleans as C99 has, but not what differs
the D bool alias from the C++ bool keyword/type ? I *do* know what
differs D bool from Java boolean, and that language's semantics...


     macro pre-processor
     compilers that warn


Some people thinks lacking these is a Good Thing only. (I don't, but)


     lack of GC


Unless you disable GC yourself in Phobos, that is...


     ability to produce extremely small applications (i.e. supports extremely
low coupling, and allows one to dispense 
 with C/C++ Runtime Library)


Can't you do this in D too, by dispensing with Phobos ?


     etc. etc. etc.


I'll add these too:

	AltiVec vector types
         (http://developer.apple.com/hardware/ve/model.html)

	inline PPC assembler
         (you can of course put that in separate .s files now)

	debugging (with name demangling and all line numbers)

	doxygen (without filters/hacks to make the code parse)


But there is nothing stopping D from getting these, too...
Except that there are only 24 hours in each day, of course. ;-)

--anders
Mar 07 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d0h20f$1r88$1 digitaldaemon.com...

 "Anders F Björklund" <afb algonet.se> wrote in message


news:d0gu9k$1n20$2 digitaldaemon.com...

 Walter wrote:

 As a *language*, what does C++ have over D?
 Implicit function template instantiation. It's hard to find much else.




     const


Discussed in great depth elsewhere!


     references


See my response to Anders on that.


     bool


I'm not seeing it, Matthew!


     namespaces


I really see nothing in C++ namespaces that has anything over D modules.
Namespaces are a failed attempt to add module like semantics to C++, and I
say failed because several experts told me that exported templates were
needed in order to provide "coding hygiene", i.e. prevent the names in one
source file from stepping on those in another. I found that interesting
because that was exactly the problem that namespace was supposed to solve.


     compile-time testing (none of that hideous runtime generic comparison


filth)

?? D has static asserts.


     TMP


??


     macro pre-processor


You can use the C preprocessor with D, if you want.


     'using'


Replaced with 'alias'.


     operators that look like operators


Sorry, but that's a bug in C++.


     compilers that warn


Thrashed that one to death <g>.


     proper cast operators,


I know there's a thread on that, but I haven't gotten to it yet.


 and the ability to fill the gaps in the spectrum with user defined types


?? D has full UDT support.


     support for shims (implicit template instantiation coupled with


ability to manipulate names in global/specific

 namespaces)


Agreed.


     lack of GC


Lack of GC is a feature? How? One can program D just like you can in C,
strictly using malloc/free. Nary a GC object. D does not require GC.


     ability to produce extremely small applications (i.e. supports


extremely low coupling, and allows one to dispense

 with C/C++ Runtime Library)


Phobos is a part of D, just like the C/C++ runtime library is a part of
C/C++. In both languages, you can stub out what you don't want, or provide
some minimal alternative. Phobos is certainly not a VM that must be dragged
around for the trivialest apps.



     etc. etc. etc.


? ? ?


 (For the record, I'm writing std.openrj right now, in 100% D, and enjoying


it for the most part. But it is *not* > unalloyed tra-la-la-ing in
wonderland ...)

I predict that once you write enough D code, you'll discover that C++ is the
incomplete language <g>. Try supporting UTF in the C++ version of openrj.
Mar 07 2005
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
 Walter wrote:

 As a *language*, what does C++ have over D?
 Implicit function template instantiation. It's hard to find much else.




     const


Discussed in great depth elsewhere!


     references


See my response to Anders on that.


     bool


I'm not seeing it, Matthew!


Hmm... Using enum you can write your own bool.


     namespaces


I really see nothing in C++ namespaces that has anything over D modules.
Namespaces are a failed attempt to add module like semantics to C++, and I
say failed because several experts told me that exported templates were
needed in order to provide "coding hygiene", i.e. prevent the names in one
source file from stepping on those in another. I found that interesting
because that was exactly the problem that namespace was supposed to solve.


The header + translation unit system is crap, right. But namespaces aren't.



     compile-time testing (none of that hideous runtime generic comparison


filth)

?? D has static asserts.


     TMP


??


Template-Meta-Programming. I never tried to do that in D, so I can't say
anything usefull here.


     macro pre-processor




Matthew, do you realy want a C-like preprocessor? If D should get macros it
should get powerfull Lisp-like macros!


You can use the C preprocessor with D, if you want.


     'using'


Replaced with 'alias'.


     operators that look like operators


Sorry, but that's a bug in C++.


Sorry, I don't get it? Which operator doesn't look like an operator? "in"? D has
almost the same operators as C++. Or are you talking about these strange names
like "opAdd"?


     compilers that warn


Thrashed that one to death <g>.


     proper cast operators,


I know there's a thread on that, but I haven't gotten to it yet.


cast(Foo)bar looks cool at first, but you can't do something that looks like a
cast on your own (e.g boost::lexical_cast looks like the other C++-cast). And
the C++-Casts are more powefull. If you defenitly know that an object has the
type you want to cast to, you can use a static cast, if you aren't sure, you can
use a dynamic cast. In D you allways have to use a dynamic cast, which is far
more expensive.



 and the ability to fill the gaps in the spectrum with user defined types


?? D has full UDT support.


D isn't very good at types with value semantics, while being good at types with
reference semantics.


     support for shims (implicit template instantiation coupled with


ability to manipulate names in global/specific

 namespaces)


Agreed.


     lack of GC


Lack of GC is a feature? How? One can program D just like you can in C,
strictly using malloc/free. Nary a GC object. D does not require GC.


     ability to produce extremely small applications (i.e. supports


extremely low coupling, and allows one to dispense

 with C/C++ Runtime Library)


Phobos is a part of D, just like the C/C++ runtime library is a part of
C/C++. In both languages, you can stub out what you don't want, or provide
some minimal alternative. Phobos is certainly not a VM that must be dragged
around for the trivialest apps.



     etc. etc. etc.


? ? ?


 (For the record, I'm writing std.openrj right now, in 100% D, and enjoying


it for the most part. But it is *not* > unalloyed tra-la-la-ing in
wonderland ...)

I predict that once you write enough D code, you'll discover that C++ is the
incomplete language <g>. Try supporting UTF in the C++ version of openrj.
Mar 09 2005
next sibling parent reply pragma <pragma_member pathlink.com> writes:
[Chopped down from its original length]

In article <d0mrip$2656$1 digitaldaemon.com>, Matthias Becker says...

 Walter wrote:

 As a *language*, what does C++ have over D?
 Implicit function template instantiation. It's hard to find much else.







     compilers that warn


Thrashed that one to death <g>.


     proper cast operators,


I know there's a thread on that, but I haven't gotten to it yet.


cast(Foo)bar looks cool at first, but you can't do something that looks like a
cast on your own (e.g boost::lexical_cast looks like the other C++-cast). And
the C++-Casts are more powefull. If you defenitly know that an object has the
type you want to cast to, you can use a static cast, if you aren't sure, you can
use a dynamic cast. In D you allways have to use a dynamic cast, which is far
more expensive.


Sorry to butt-into the discussion, but I have some insight to share with respect
D's casting mechanism.

First off, one can accomplish a static-cast in D, although it looks a bit
hackish:


 myvar = cast(MyVar)cast(void*)myothervar;


I assume that casting through "void*" is waved away by the compiler into
something more succinct, so I wouldn't expect this to be any less efficient than
C.

Secondly, one can also write their own cast routine from scratch, as I have done
already:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/18665

.. which is a dynamic cast based on class/interface name.  D's built-in casting
mechanism is based on typeinfo reference.

By this you get "dyn_cast!(Type)(arg)" which IMO, is no less a cast than
"boost::lexical_cast<Type>(arg)" since its still relying on a template.

The ABI documentation is out of date, but all one needs to do is poke around in
phobos/object.d.  I would suspect that the future will bring an ABI that can be
used to code any manner of runtime-type mechanisms.

So with respect to cast(), D is surely on the same footing as C/C++, if not on
higher ground.

- EricAnderton at yahoo
Mar 09 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"pragma" <pragma_member pathlink.com> wrote in message 
news:d0n4cl$2g4k$1 digitaldaemon.com...

 [Chopped down from its original length]

 In article <d0mrip$2656$1 digitaldaemon.com>, Matthias Becker says...

 Walter wrote:

 As a *language*, what does C++ have over D?
 Implicit function template instantiation. It's hard to find much 
 else.







     compilers that warn


Thrashed that one to death <g>.


     proper cast operators,


I know there's a thread on that, but I haven't gotten to it yet.


cast(Foo)bar looks cool at first, but you can't do something that 
looks like a
cast on your own (e.g boost::lexical_cast looks like the other 
C++-cast). And
the C++-Casts are more powefull. If you defenitly know that an object 
has the
type you want to cast to, you can use a static cast, if you aren't 
sure, you can
use a dynamic cast. In D you allways have to use a dynamic cast, which 
is far
more expensive.


 Sorry to butt-into the discussion, but I have some insight to share 
 with respect
 D's casting mechanism.

 First off, one can accomplish a static-cast in D, although it looks a 
 bit
 hackish:


 myvar = cast(MyVar)cast(void*)myothervar;


 I assume that casting through "void*" is waved away by the compiler 
 into
 something more succinct, so I wouldn't expect this to be any less 
 efficient than
 C.

 Secondly, one can also write their own cast routine from scratch, as I 
 have done
 already:

 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/18665

 .. which is a dynamic cast based on class/interface name.  D's 
 built-in casting
 mechanism is based on typeinfo reference.

 By this you get "dyn_cast!(Type)(arg)" which IMO, is no less a cast 
 than
 "boost::lexical_cast<Type>(arg)" since its still relying on a 
 template.

 The ABI documentation is out of date, but all one needs to do is poke 
 around in
 phobos/object.d.  I would suspect that the future will bring an ABI 
 that can be
 used to code any manner of runtime-type mechanisms.

 So with respect to cast(), D is surely on the same footing as C/C++, 
 if not on
 higher ground.


Unless I'm stunningly misinformed - possible - this is complete piffle. 
In a recent conversation Walter informed me that cast() has pretty much 
sledge-hammer semantics. That was his main basis for not wanting 
warnings about truncation, since it would incline people to overuse 
casts, and casts can cast anything. I've not tested this out, yet, but 
I'm inclined to take it from the horse's mouth.

Given that, D's cast mechanism is nothing more than C's cast mechanism 
with more greppable syntax, and is, therefore, complete crap.

We need fine grained casts. There is no debate. The only question is 
whether we'll get them. C++'s casts, for all their comparative richness 
and syntactic extensibility, are not popular with Walter. Therefore, we 
will have another uphill battle to reach a sensible state. I'm a bit 
weary from the last few battles to take this on just now - and I want to 
delete delete first! - so maybe others might weigh in with what will 
undoubtedly be more reasoned language than I would conjure at this point 
...
Mar 09 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d0nsvu$c1h$2 digitaldaemon.com...

 Unless I'm stunningly misinformed - possible - this is complete piffle.
 In a recent conversation Walter informed me that cast() has pretty much
 sledge-hammer semantics. That was his main basis for not wanting
 warnings about truncation, since it would incline people to overuse
 casts, and casts can cast anything. I've not tested this out, yet, but
 I'm inclined to take it from the horse's mouth.


I remember saying that to you, but when casting class references, it does
behave like C++'s dynamic_cast. We weren't talking about class reference
conversions at the time, so I did not think to bring it up.
Mar 09 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d0o3dn$j7m$1 digitaldaemon.com...

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d0nsvu$c1h$2 digitaldaemon.com...

 Unless I'm stunningly misinformed - possible - this is complete 
 piffle.
 In a recent conversation Walter informed me that cast() has pretty 
 much
 sledge-hammer semantics. That was his main basis for not wanting
 warnings about truncation, since it would incline people to overuse
 casts, and casts can cast anything. I've not tested this out, yet, 
 but
 I'm inclined to take it from the horse's mouth.


 I remember saying that to you, but when casting class references, it 
 does
 behave like C++'s dynamic_cast.


Of course, I recognise that. But that's completely irrelevant. C's cast 
performs proper conversions when casting an int to a double. That does 
not detract from the legion flaws of C's cast.


 We weren't talking about class reference
 conversions at the time, so I did not think to bring it up.


Fair enough.

The problem with D's cast is exactly what prompted C++ to introduce its 
four built-in cast operators. There's nothing I can usefully add to 
their rationale, other than to say that C++'s template syntax and 
implicit instantiation makes a wonderfully powerful and extensible cast 
mechanism.

btw, I asked B.S. whether he'd planned it that way deliberately. With 
customary succinctness he said "it did occur to me". I consider this to 
be one of his many remarkable moments of genius in designing C++, and I 
heartily commend you to do the same, but better, for D.
Mar 09 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d0o48n$k21$1 digitaldaemon.com...

 btw, I asked B.S. whether he'd planned it that way deliberately. With
 customary succinctness he said "it did occur to me". I consider this to
 be one of his many remarkable moments of genius in designing C++, and I
 heartily commend you to do the same, but better, for D.


Yes, B.S. did deliberately choose to use template syntax for it, and said so
at the time. Just so you know!
Mar 09 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d0o6ca$m4g$1 digitaldaemon.com...

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d0o48n$k21$1 digitaldaemon.com...

 btw, I asked B.S. whether he'd planned it that way deliberately. With
 customary succinctness he said "it did occur to me". I consider this 
 to
 be one of his many remarkable moments of genius in designing C++, and 
 I
 heartily commend you to do the same, but better, for D.


 Yes, B.S. did deliberately choose to use template syntax for it, and 
 said so
 at the time. Just so you know!


Ah! Then I'm the bearer of old news. Still, old's better than bad I 
suppose. ;)
Mar 09 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthias Becker" <Matthias_member pathlink.com> wrote in message
news:d0mrip$2656$1 digitaldaemon.com...

 cast(Foo)bar looks cool at first, but you can't do something that looks


like a

 cast on your own (e.g boost::lexical_cast looks like the other C++-cast).


And

 the C++-Casts are more powefull. If you defenitly know that an object has


the

 type you want to cast to, you can use a static cast, if you aren't sure,


you can

 use a dynamic cast. In D you allways have to use a dynamic cast, which is


far

 more expensive.


You can do what you ask in D by first passing it through a 'void*' cast:

    b = cast(B)cast(void*)a;

which will do the same thing as C++:

    b = static_cast<B*>(a);
Mar 09 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d0o2qr$iif$2 digitaldaemon.com...

 "Matthias Becker" <Matthias_member pathlink.com> wrote in message
 news:d0mrip$2656$1 digitaldaemon.com...

 cast(Foo)bar looks cool at first, but you can't do something that 
 looks


 like a

 cast on your own (e.g boost::lexical_cast looks like the other 
 C++-cast).


 And

 the C++-Casts are more powefull. If you defenitly know that an object 
 has


 the

 type you want to cast to, you can use a static cast, if you aren't 
 sure,


 you can

 use a dynamic cast. In D you allways have to use a dynamic cast, 
 which is


 far

 more expensive.


 You can do what you ask in D by first passing it through a 'void*' 
 cast:

    b = cast(B)cast(void*)a;


Well, if that doesn't prove that cast() is overly coarse, I don't know 
what does.


 which will do the same thing as C++:

    b = static_cast<B*>(a);


This one is incontestably clearer.
Mar 09 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d0o3ln$jho$2 digitaldaemon.com...

 You can do what you ask in D by first passing it through a 'void*'
 cast:

    b = cast(B)cast(void*)a;


 Well, if that doesn't prove that cast() is overly coarse, I don't know
 what does.


 which will do the same thing as C++:

    b = static_cast<B*>(a);


 This one is incontestably clearer.


It is? I remember when static_cast came out, I had to read the spec several
times to figure out what it did. 'static' has no reliable meaning in C++.
Suppose I propose:

    extern_cast<B*>(a);

for C++. What does it do?
Mar 09 2005
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d0o6v7$mir$1 digitaldaemon.com...

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d0o3ln$jho$2 digitaldaemon.com...

 You can do what you ask in D by first passing it through a 'void*'
 cast:

    b = cast(B)cast(void*)a;


 Well, if that doesn't prove that cast() is overly coarse, I don't 
 know
 what does.


 which will do the same thing as C++:

    b = static_cast<B*>(a);


 This one is incontestably clearer.


 It is? I remember when static_cast came out, I had to read the spec 
 several
 times to figure out what it did. 'static' has no reliable meaning in 
 C++.
 Suppose I propose:

    extern_cast<B*>(a);

 for C++. What does it do?


Fine. So what? Off the point.

I don't care a rats about what it's called, and I have a hard time 
believing that you think I do.

The point is that there are _different_ casts for doing _different_ 
things. Axiomatically, this reduces the likelihood of the execution of 
such operation from inadvertently doing another.

Am I being unreasonable to hope that you might address my point, or 
simply acknowledge that you'd rather not complicate the 
language/compiler?

I mean, come on. That double cast thing above is just bloody ridiculous. 
Anyone new dipping in and reading that post from the language designer 
is going to have their confidence factor drop to zero. Or am I wrong? 
Please explain
Mar 09 2005
parent Ben Hinkle <Ben_member pathlink.com> writes:
 You can do what you ask in D by first passing it through a 'void*'
 cast:

    b = cast(B)cast(void*)a;








[snip]

 which will do the same thing as C++:

    b = static_cast<B*>(a);








[snip]

I mean, come on. That double cast thing above is just bloody ridiculous. 
Anyone new dipping in and reading that post from the language designer 
is going to have their confidence factor drop to zero. Or am I wrong? 
Please explain


Can we throw an itty-bitty template like the following into std somewhere? I'm
half tempted to suggest putting it in std.c.stddef just because it's so C-like.
Personally I don't think it'll get used much (Java gets along fine without one),
but who knows...

// compile-time cast to a class T
template c_cast(T : Object) {
T c_cast(void* x) { return cast(T)x; }
}

// example
class A {}
class B:A {}
class C:A {}

int main() {
B b = new B;
C c = c_cast!(C)(b); // point gun at foot...
return 0;
}
Mar 09 2005
prev sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <d0o6v7$mir$1 digitaldaemon.com>, Walter says...

I remember when static_cast came out, I had to read the spec several
times to figure out what it did. 'static' has no reliable meaning in C++.


Isn't 'static' the opposite of 'dynamic'? :-)


Suppose I propose:

    extern_cast<B*>(a);

for C++. What does it do?


The opposite of 'static'. :-)

Ciao
Mar 10 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
news:d0p053$1jav$1 digitaldaemon.com...

 In article <d0o6v7$mir$1 digitaldaemon.com>, Walter says...

I remember when static_cast came out, I had to read the spec several
times to figure out what it did. 'static' has no reliable meaning in C++.


 Isn't 'static' the opposite of 'dynamic'? :-)


Suppose I propose:

    extern_cast<B*>(a);

for C++. What does it do?


 The opposite of 'static'. :-)


Yup <g>. The point being that it's clear what it does only after carefully
reading the documentation.

The double cast way of doing static casts in D is an idiom. There are idioms
in D just like there are well-known idioms in C++. I suggest that the double
cast idiom will become one of those well recognized ones and it's meaning
will be clear because people will be used to seeing it and using it.
Mar 10 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d0q1vg$2m2t$1 digitaldaemon.com...

 "Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
 news:d0p053$1jav$1 digitaldaemon.com...

 In article <d0o6v7$mir$1 digitaldaemon.com>, Walter says...

I remember when static_cast came out, I had to read the spec several
times to figure out what it did. 'static' has no reliable meaning in 
C++.


 Isn't 'static' the opposite of 'dynamic'? :-)


Suppose I propose:

    extern_cast<B*>(a);

for C++. What does it do?


 The opposite of 'static'. :-)


 Yup <g>. The point being that it's clear what it does only after 
 carefully
 reading the documentation.

 The double cast way of doing static casts in D is an idiom. There are 
 idioms
 in D just like there are well-known idioms in C++. I suggest that the 
 double
 cast idiom will become one of those well recognized ones and it's 
 meaning
 will be clear because people will be used to seeing it and using it.


Sorry to get all unprofessional, but when I read you saying things like 
this I wonder whether the world is made of chocolate, and Homer's eaten 
out my brain.

That double cast is a freakish bit of code, that will be fantastic 
fodder for D-etractors. I'm just stunned that you think that it's 
reasonable, in a language with all the intentions D makes, to propose 
such hacks, instead of addressing real needs within the (pre-1.0) 
language itself.

Sure, maybe it's me. I could be cracked, but I really think not (at 
least in this case). I'll attempt some rationalisation:

D's design is predicated on the fact that pointers are dangerous, and, 
despite their acknowledged power (and facilitation of efficiency) cause 
problems for the (un)wary in C and C++. While D permits use of pointers, 
goto, etc. etc. for interfacing to C and such things - a good thing, and 
an advantage over nannying languaJes - it should be possible to avoid 
them and still be able to practice D in a powerful, full-featured 
sophisticated way. Now I may be editorialising somewhat, but I'm pretty 
sure I've read those arguments from your posts over the years, albeit in 
fragmented form perhaps. Please correct me if this misrepresents things.

Now we come to casting. There are all kinds of casting, whether they 
bear distinct names or have distinct language constructs or not. 
Integral truncation. Integral promotion. Type conversion (/subversion). 
OO hierarchy navigation.  etc. etc.

Users from other languages in which these issues have already been 
sensibly addressed will naturally seek to avoid the too-coarse-grained 
cast() operator. You've recognised that, and demonstrated a technique 
whereby they might do so. But what you're telling them is that, to do 
so, they must use pointers in a language that specifically eschews 
pointers.

This is inconsistent, and gives the impression that the language is 
hacked together. If I'm wrong to draw that conclusion, I'm very 
interested to have it explained to me.

Now, why do we have access to only a single too-coarse-grained cast()? 
Because you, personally, do not appreciate the purpose (or perhaps the 
implementation) of different cast operators. This may be because you (as 
I'm pretty sure you've admitted) tend not to use them. Or maybe you tend 
not to use them because you don't appreciate them. Chicken or egg. 
Impossible to tell. (Again, please correct me if I'm misrepresenting 
you.)

I have to say that I can draw no other conclusion than that:
    a. you do not like/appreciate cast richness, therefore
    b. you don't (much?) use these casts, therefore
    c. you do not think they should be in D, therefore
    d. you have come up with a farcical cast hack, using things that are 
expressively avoided/avoidable in 'normal' D. And you've called it an 
idiom!!

It's just bonkers.

I put it to everyone who's managed to get to stick with the rant to this 
point to select which of the following is more discoverable, 
maintainable, amenable to automated code searching tools, indicative of 
considered design, attractive, etc.:

    b = cast(B)cast(void*)a;

    b = type_cast(B)(a);

(Note: type_cast is just a name I conjured for the example. Naturally 
we'd go through a collegial process for coming up with good and sensible 
names for any/all specific cast operators.)
Mar 10 2005
next sibling parent reply Kris <Kris_member pathlink.com> writes:
I have to agree that the 'idiom' described did have me chuckling heartily, for
many of the reasons you describe. In particular, if this would be used often
enough to become an "idiom", then why the heck wouldn't the language clean up
the syntax?

Perhaps it should be called one of the following?


    b = castigate(B) a;

    b = castrate(B) a;


:-}

It does seem jolly silly for it to remain as "cast(B) cast(void*) a" instead.
Egad!




In article <d0qksf$9im$1 digitaldaemon.com>, Matthew says...

"Walter" <newshound digitalmars.com> wrote in message 
news:d0q1vg$2m2t$1 digitaldaemon.com...

 "Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
 news:d0p053$1jav$1 digitaldaemon.com...

 In article <d0o6v7$mir$1 digitaldaemon.com>, Walter says...

I remember when static_cast came out, I had to read the spec several
times to figure out what it did. 'static' has no reliable meaning in 
C++.


 Isn't 'static' the opposite of 'dynamic'? :-)


Suppose I propose:

    extern_cast<B*>(a);

for C++. What does it do?


 The opposite of 'static'. :-)


 Yup <g>. The point being that it's clear what it does only after 
 carefully
 reading the documentation.

 The double cast way of doing static casts in D is an idiom. There are 
 idioms
 in D just like there are well-known idioms in C++. I suggest that the 
 double
 cast idiom will become one of those well recognized ones and it's 
 meaning
 will be clear because people will be used to seeing it and using it.


Sorry to get all unprofessional, but when I read you saying things like 
this I wonder whether the world is made of chocolate, and Homer's eaten 
out my brain.

That double cast is a freakish bit of code, that will be fantastic 
fodder for D-etractors. I'm just stunned that you think that it's 
reasonable, in a language with all the intentions D makes, to propose 
such hacks, instead of addressing real needs within the (pre-1.0) 
language itself.

Sure, maybe it's me. I could be cracked, but I really think not (at 
least in this case). I'll attempt some rationalisation:

D's design is predicated on the fact that pointers are dangerous, and, 
despite their acknowledged power (and facilitation of efficiency) cause 
problems for the (un)wary in C and C++. While D permits use of pointers, 
goto, etc. etc. for interfacing to C and such things - a good thing, and 
an advantage over nannying languaJes - it should be possible to avoid 
them and still be able to practice D in a powerful, full-featured 
sophisticated way. Now I may be editorialising somewhat, but I'm pretty 
sure I've read those arguments from your posts over the years, albeit in 
fragmented form perhaps. Please correct me if this misrepresents things.

Now we come to casting. There are all kinds of casting, whether they 
bear distinct names or have distinct language constructs or not. 
Integral truncation. Integral promotion. Type conversion (/subversion). 
OO hierarchy navigation.  etc. etc.

Users from other languages in which these issues have already been 
sensibly addressed will naturally seek to avoid the too-coarse-grained 
cast() operator. You've recognised that, and demonstrated a technique 
whereby they might do so. But what you're telling them is that, to do 
so, they must use pointers in a language that specifically eschews 
pointers.

This is inconsistent, and gives the impression that the language is 
hacked together. If I'm wrong to draw that conclusion, I'm very 
interested to have it explained to me.

Now, why do we have access to only a single too-coarse-grained cast()? 
Because you, personally, do not appreciate the purpose (or perhaps the 
implementation) of different cast operators. This may be because you (as 
I'm pretty sure you've admitted) tend not to use them. Or maybe you tend 
not to use them because you don't appreciate them. Chicken or egg. 
Impossible to tell. (Again, please correct me if I'm misrepresenting 
you.)

I have to say that I can draw no other conclusion than that:
    a. you do not like/appreciate cast richness, therefore
    b. you don't (much?) use these casts, therefore
    c. you do not think they should be in D, therefore
    d. you have come up with a farcical cast hack, using things that are 
expressively avoided/avoidable in 'normal' D. And you've called it an 
idiom!!

It's just bonkers.

I put it to everyone who's managed to get to stick with the rant to this 
point to select which of the following is more discoverable, 
maintainable, amenable to automated code searching tools, indicative of 
considered design, attractive, etc.:

    b = cast(B)cast(void*)a;

    b = type_cast(B)(a);

(Note: type_cast is just a name I conjured for the example. Naturally 
we'd go through a collegial process for coming up with good and sensible 
names for any/all specific cast operators.)
Mar 10 2005
parent reply pragma <pragma_member pathlink.com> writes:
In article <d0qp27$e54$1 digitaldaemon.com>, Kris says...

It does seem jolly silly for it to remain as "cast(B) cast(void*) a" instead.
Egad!


Well, having rolled my own casting operator myself, I'd like to add my $0.02 to
the pot.  

I can easily forsee a templatized wrapper around the const-cast idiom:


 static_cast!(Foo)(bar);


Which is really the ghost of language past.  Let's not do this, please.  I for
one would rather see the typical kinds of casts enshrined in the language
itself:


 static_cast(Foo) bar;


Along with all of its friends:


 cast(Foo) bar;
 dynamic_cast(Foo) bar; // same as vanilla cast()
 static_cast(Foo) bar;
 const_cast(Foo) bar; // depending on the outcome of the 'const saga'.
 extern_cast(Foo) bar; // classname based cast rather than typeid based.



Now not having these in the language is no real loss, thanks to the (incomplete)
ABI.  However, use of such casts is frequent enough that adding them could only
help us write cleaner (varargs come to mind) code.  

Also, I'll add that the template system is inadequate to make a completely
water-tight cast operator, so something needs to be done one way or the other.

- EricAnderton at yahoo
Mar 10 2005
parent reply Ben Hinkle <Ben_member pathlink.com> writes:
In article <d0r40c$o40$1 digitaldaemon.com>, pragma says...

In article <d0qp27$e54$1 digitaldaemon.com>, Kris says...

It does seem jolly silly for it to remain as "cast(B) cast(void*) a" instead.
Egad!


Well, having rolled my own casting operator myself, I'd like to add my $0.02 to
the pot.  

I can easily forsee a templatized wrapper around the const-cast idiom:


 static_cast!(Foo)(bar);


Which is really the ghost of language past.  Let's not do this, please.  I for
one would rather see the typical kinds of casts enshrined in the language
itself:


 static_cast(Foo) bar;


Along with all of its friends:


 cast(Foo) bar;
 dynamic_cast(Foo) bar; // same as vanilla cast()
 static_cast(Foo) bar;
 const_cast(Foo) bar; // depending on the outcome of the 'const saga'.
 extern_cast(Foo) bar; // classname based cast rather than typeid based.



Now not having these in the language is no real loss, thanks to the (incomplete)
ABI.  However, use of such casts is frequent enough that adding them could only
help us write cleaner (varargs come to mind) code.  

Also, I'll add that the template system is inadequate to make a completely
water-tight cast operator, so something needs to be done one way or the other.

- EricAnderton at yahoo


ack - I really hope D doesn't end up with a bazillion (or even, say,
three)casting options. Casting is so rare and the performance hit of a dynamic
cast vs static cast hasn't ever been a problem in my Java coding experience that
it would be a pity to burden future D coder with all the esoteric casts. Why
bother? Casting is evil - so why obsess over it.

One benefit of the double cast is it makes it explicit what is actually
happening. Say I have an int x that I want to cast to an object reference. I
actually prefer cast(Object)cast(void*)x since it spells out the process of
turning an int into a reference - not that I encourage that sort of thing :-)
Mar 10 2005
parent reply kris <fu bar.org> writes:
Ben Hinkle wrote:
<snip>

 ack - I really hope D doesn't end up with a bazillion (or even, say,
 three)casting options. Casting is so rare and the performance hit of a dynamic
 cast vs static cast hasn't ever been a problem in my Java coding experience
that
 it would be a pity to burden future D coder with all the esoteric casts. Why
 bother? Casting is evil - so why obsess over it.



I don't think anyone is obsessing, Ben. There's only been a couple of 
posts on this particular angle, compared to what must be /hundreds/ over 
'$' :-)

I can't imagine anyone would claim that casting is the "right" way, but 
Walter did bring it up in terms of an 'idiom' ... for that, it needs to 
be applied to a certain degree (as opposed to never).



 One benefit of the double cast is it makes it explicit what is actually
 happening. Say I have an int x that I want to cast to an object reference. I
 actually prefer cast(Object)cast(void*)x since it spells out the process of
 turning an int into a reference - not that I encourage that sort of thing :-)



Again, I can't imagine you'd get an argument here. But this is not the 
case in question. What you're noting here is a gross violation ~ unless 
I misread you?

Just for the record: I encourage people to avoid casting, since it tends 
to hide issues that the compiler might otherwise catch, and it can make 
maintenance and/or refactoring that much more difficult. However, if 
Walter expects developers will use static-casts, then that usage should 
be explicitly supported ~ if nothing else, it will isolate those 
instances from the 'gross violation' cases you identified above.

I don't suppose anyone thought 'castigate' was an appropriate term? No? 
Oh well :-)
Mar 10 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 10 Mar 2005 21:48:56 -0800, kris wrote:


 Ben Hinkle wrote:
 <snip>

 ack - I really hope D doesn't end up with a bazillion (or even, say,
 three)casting options. Casting is so rare and the performance hit of a dynamic
 cast vs static cast hasn't ever been a problem in my Java coding experience
that
 it would be a pity to burden future D coder with all the esoteric casts. Why
 bother? Casting is evil - so why obsess over it.




But still necessary sometimes.

  void Foo(char[] x){};
  void Foo(wchar[] x){};

  Foo(cast(wchar[])"abcdef"); // Cast required else the compiles fails.


-- 
Derek Parnell
Melbourne, Australia
11/03/2005 11:06:16 PM
Mar 11 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:1l04rq800km3a.16v19z9iovqpy$.dlg 40tude.net...

 On Thu, 10 Mar 2005 21:48:56 -0800, kris wrote:


 Ben Hinkle wrote:
 <snip>

 ack - I really hope D doesn't end up with a bazillion (or even, say,
 three)casting options. Casting is so rare and the performance hit of a 
 dynamic
 cast vs static cast hasn't ever been a problem in my Java coding 
 experience that
 it would be a pity to burden future D coder with all the esoteric casts. 
 Why
 bother? Casting is evil - so why obsess over it.




 But still necessary sometimes.

  void Foo(char[] x){};
  void Foo(wchar[] x){};

  Foo(cast(wchar[])"abcdef"); // Cast required else the compiles fails.


Agreed. And I argue the existing D cast does just fine with 99.9% of cast 
situations. I actually am curious why Walter thinks the double-cast will 
become an idiom. The only "legit" one that comes to mind is wanting to do a 
static cast on object references instead of a dynamic cast for performance.
Mar 11 2005
parent reply pragma <pragma_member pathlink.com> writes:
In article <d0s3nj$1s5q$1 digitaldaemon.com>, Ben Hinkle says...

"Derek Parnell" <derek psych.ward> wrote in message 
news:1l04rq800km3a.16v19z9iovqpy$.dlg 40tude.net...

 On Thu, 10 Mar 2005 21:48:56 -0800, kris wrote:


 Ben Hinkle wrote:
 <snip>

 ack - I really hope D doesn't end up with a bazillion (or even, say,
 three)casting options. Casting is so rare and the performance hit of a 
 dynamic
 cast vs static cast hasn't ever been a problem in my Java coding 
 experience that
 it would be a pity to burden future D coder with all the esoteric casts. 
 Why
 bother? Casting is evil - so why obsess over it.




 But still necessary sometimes.

  void Foo(char[] x){};
  void Foo(wchar[] x){};

  Foo(cast(wchar[])"abcdef"); // Cast required else the compiles fails.


Agreed. And I argue the existing D cast does just fine with 99.9% of cast 
situations. I actually am curious why Walter thinks the double-cast will 
become an idiom. The only "legit" one that comes to mind is wanting to do a 
static cast on object references instead of a dynamic cast for performance. 


Well, working with varargs is rife with casting through "void**" to get the
actual argument's pointer.  The suggested template in the docs helps some, but
its still there, under the hood.


The only "legit" one that comes to mind is wanting to do a 
static cast on object references instead of a dynamic cast for performance. 


That's an interesting concept, but probably ill-adivsed in D (more so than in
C++).  It would work great class-to-class, but will fail if an interface is
involved in the cast.

- EricAnderton at yahoo
Mar 11 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
pragma wrote:


 Well, working with varargs is rife with casting through "void**" to get the
 actual argument's pointer.  The suggested template in the docs helps some, but
 its still there, under the hood.


The suggested template is the only way that works in GDC since _argptr
is not a "void*" everywhere, but a "va_list" type that *might* be one...

Hopefully the void*/cast section of the D specification can be removed,
in favor of std.stdarg, to stop people from writing non-portable code ?

http://www.digitalmars.com/d/function.html


Kinda like writing to D's string literals, which only works on Windows.

--anders
Mar 11 2005
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 11 Mar 2005 10:22:54 +1100, Matthew wrote:


 "Walter" <newshound digitalmars.com> wrote in message 
 news:d0q1vg$2m2t$1 digitaldaemon.com...

 "Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
 news:d0p053$1jav$1 digitaldaemon.com...

 In article <d0o6v7$mir$1 digitaldaemon.com>, Walter says...

I remember when static_cast came out, I had to read the spec several
times to figure out what it did. 'static' has no reliable meaning in 
C++.


 Isn't 'static' the opposite of 'dynamic'? :-)


Suppose I propose:

    extern_cast<B*>(a);

for C++. What does it do?


 The opposite of 'static'. :-)


 Yup <g>. The point being that it's clear what it does only after 
 carefully
 reading the documentation.

 The double cast way of doing static casts in D is an idiom. There are 
 idioms
 in D just like there are well-known idioms in C++. I suggest that the 
 double
 cast idiom will become one of those well recognized ones and it's 
 meaning
 will be clear because people will be used to seeing it and using it.


 
 Sorry to get all unprofessional, but when I read you saying things like 
 this I wonder whether the world is made of chocolate, and Homer's eaten 
 out my brain.
 
 That double cast is a freakish bit of code, that will be fantastic 
 fodder for D-etractors. I'm just stunned that you think that it's 
 reasonable, in a language with all the intentions D makes, to propose 
 such hacks, instead of addressing real needs within the (pre-1.0) 
 language itself.
 


[snip]


 It's just bonkers.
 
 I put it to everyone who's managed to get to stick with the rant to this 
 point to select which of the following is more discoverable, 
 maintainable, amenable to automated code searching tools, indicative of 
 considered design, attractive, etc.:
 
     b = cast(B)cast(void*)a;
 
     b = type_cast(B)(a);
 
 (Note: type_cast is just a name I conjured for the example. Naturally 
 we'd go through a collegial process for coming up with good and sensible 
 names for any/all specific cast operators.)



Matthew has a good point. The double cast idiom is just asking to be picked
on as a "stupid idea" when a much more expressive one could have be
implemented.


-- 
Derek Parnell
Melbourne, Australia
11/03/2005 10:57:51 PM
Mar 11 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d0qksf$9im$1 digitaldaemon.com...

 Users from other languages in which these issues have already been
 sensibly addressed will naturally seek to avoid the too-coarse-grained
 cast() operator. You've recognised that, and demonstrated a technique
 whereby they might do so. But what you're telling them is that, to do
 so, they must use pointers in a language that specifically eschews
 pointers.


The cast(B)a will work perfectly fine, and avoids pointer manipulation.
It'll do upcasting and downcasting for class objects in a safe manner. The
cast(B)cast(void*)a is a technique for people who want to *go around* the
typing rules because they "know" that 'a' can be downcast to a B without a
runtime check. As such, it qualifies as a technique for more advanced
programmers, and pointers are well supported in D expressly for use by more
advanced programmers who understand them.
Mar 11 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d0tobv$1999$1 digitaldaemon.com...

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d0qksf$9im$1 digitaldaemon.com...

 Users from other languages in which these issues have already been
 sensibly addressed will naturally seek to avoid the 
 too-coarse-grained
 cast() operator. You've recognised that, and demonstrated a technique
 whereby they might do so. But what you're telling them is that, to do
 so, they must use pointers in a language that specifically eschews
 pointers.


 The cast(B)a will work perfectly fine, and avoids pointer 
 manipulation.
 It'll do upcasting and downcasting for class objects in a safe manner. 
 The
 cast(B)cast(void*)a is a technique for people who want to *go around* 
 the
 typing rules because they "know" that 'a' can be downcast to a B 
 without a
 runtime check. As such, it qualifies as a technique for more advanced
 programmers, and pointers are well supported in D expressly for use by 
 more
 advanced programmers who understand them.


Well, I have to say I find that attitude quite depressing. I am quite 
sure that it will make D look like a hackers delight. You're equally 
sure it won't. Impasse. I can do nothing useful further, other than take 
the brick from my hand and not bash my head with it any further.

However, you have not addressed the far less equivocal point that

    cast(X)cast(void*)y

is manifestly less amenable to code analysis tools as

    static_cast(X)y
Mar 11 2005
parent "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d0tsll$1d22$1 digitaldaemon.com...

 However, you have not addressed the far less equivocal point that

     cast(X)cast(void*)y

 is manifestly less amenable to code analysis tools as

     static_cast(X)y


If grep is the extent of it, perhaps. I think cast(void*) is eminently
greppable; you'll get some false positives just like you will with grepping
for static_cast.

On the other hand, D is far more amenable to real code analysis tools
because D is parseable at several levels without requiring a full blown
compiler to do it. Even if you are using a code analysis tool that needs to
do semantic analysis, it's just a lot easier to do with D than with C++.
Once you have that, it isn't hard at all to look for a double cast on a
class reference.

If that still isn't enough, you can always write a template to do it, and
grep on the template name.
Mar 11 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d0gu9k$1n20$2 digitaldaemon.com...

 Walter wrote:

Like many others, I think that C++ is a more "complete" language.


 I don't really understand why. As a *language*, what does C++ have over




D?

 Implicit function template instantiation. It's hard to find much else.


 D has some "simplified" versions of C++ features, like inout instead of
 reference params,


A C++ reference parameter gives no clue whether it is in, out, or inout. The
situation is such that Microsoft went ahead and invented IDL (Interface
Description Language), the sole point of which is to add that missing bit of
information. IDL is irrelevant for D.

Looking at how references actually work in C++, they are loaded up with
special rules that make them behave as if they were storage classes rather
than types. D just goes ahead and makes them what they naturally want to be.
I don't see anything incomplete about it.


 simplified const handling (storage instead of type),


As has been debated here many times <g>, const as a type modifier in C++ is
so semantically weak it is fairly useless. (Many disagree.) C and C++ are
the only languages I've ever heard of that use const as a type modifier.

convinced the larger programmer community that const as a type modifier has
a place.


 etc, and I guess I'd have more examples if I had been using C++ more...
 And this makes C++ more "complete" in that you can do more things,
 but is also makes a lot harder and complex - at least at the start ?


I'd argue that C++ is less complete, since it relies so heavilly on STL to
do things that are built in to most languages. Doing a general purpose
foreach with C++ is fiendishly difficult. It's for free in D.


 I'll let the C++ experts fill in their own pet peeves about D 1.0.
 (as I've said before, my own experience is with C and with Java)
Mar 06 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:


 A C++ reference parameter gives no clue whether it is in, out, or inout. The
 situation is such that Microsoft went ahead and invented IDL (Interface
 Description Language), the sole point of which is to add that missing bit of
 information. IDL is irrelevant for D.


I prefer the "in/out" parameters. Reminds me of Ada or something...


 As has been debated here many times <g>, const as a type modifier in C++ is
 so semantically weak it is fairly useless. (Many disagree.) C and C++ are
 the only languages I've ever heard of that use const as a type modifier.

 convinced the larger programmer community that const as a type modifier has
 a place.


The only place for "const" seems to be protecting read-only attribute ?


 I'd argue that C++ is less complete, since it relies so heavilly on STL to
 do things that are built in to most languages. Doing a general purpose
 foreach with C++ is fiendishly difficult. It's for free in D.


I think I'll just let you fight that one out with Matthew ;-)
I never liked C++, so I went straight to Java. D changes that.

--anders
Mar 07 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d0hu4o$2orp$1 digitaldaemon.com...

 The only place for "const" seems to be protecting read-only attribute ?


I like "const" as meaning it really is constant. Read-only is a side effect
of that. C++ const stuff may be read only, but it isn't constant. Other
threads, and other references to the same data can change it at any time,
which is why the C++ const is overrated.
Mar 07 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:


The only place for "const" seems to be protecting read-only attribute ?


 
 I like "const" as meaning it really is constant. Read-only is a side effect
 of that. C++ const stuff may be read only, but it isn't constant. Other
 threads, and other references to the same data can change it at any time,
 which is why the C++ const is overrated.


This sounds a bit to me like how "typedef" and "alias" work, in D ?


Which means that if "const" ever surfaced in D, which seems to
be unlikely since it is so easy to cast away and be a Bad Boy,
it would probably be called "readonly" instead - to reflect use ?

Since "const" are reserved in D for things that are... well...
constant, and "typedef" are reserved for stuff that... errr...
actually define new types. Then "readonly" sounds approriate.

Or perhaps the write-once declaration of "final", that Java has.
(works a little like a CD-rom disc burner, doesn't it, where you
can write stuff to the disc only once - and then it's "constant")


I like D's const. Whether "readonly" is needed, remains to be seen...
(but it would probably have to be enforced with massive military force,
for instance like string literals on GCC that are placed in R/O memory?)

--anders
Mar 09 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d0mnlt$221c$1 digitaldaemon.com...

 Walter wrote:


The only place for "const" seems to be protecting read-only attribute 
?


 I like "const" as meaning it really is constant. Read-only is a side 
 effect
 of that. C++ const stuff may be read only, but it isn't constant. 
 Other
 threads, and other references to the same data can change it at any 
 time,
 which is why the C++ const is overrated.


 This sounds a bit to me like how "typedef" and "alias" work, in D ?


 Which means that if "const" ever surfaced in D, which seems to
 be unlikely since it is so easy to cast away and be a Bad Boy,
 it would probably be called "readonly" instead - to reflect use ?

 Since "const" are reserved in D for things that are... well...
 constant, and "typedef" are reserved for stuff that... errr...
 actually define new types. Then "readonly" sounds approriate.

 Or perhaps the write-once declaration of "final", that Java has.
 (works a little like a CD-rom disc burner, doesn't it, where you
 can write stuff to the disc only once - and then it's "constant")


 I like D's const. Whether "readonly" is needed, remains to be seen...
 (but it would probably have to be enforced with massive military 
 force,
 for instance like string literals on GCC that are placed in R/O 
 memory?)


I know that it's never going to surface with the scope of C++'s const, 
but I see no reason why we can't have readonly members, i.e. they must 
be explicitly initialised in all ctor bodies.

And Walter's been completely silent about this exact point, instead 
banging on about const subversion in C++, which has precisely nothing to 
do with the request.

Walter??
Mar 09 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d0nsvs$c1h$1 digitaldaemon.com...

 I know that it's never going to surface with the scope of C++'s const,
 but I see no reason why we can't have readonly members, i.e. they must
 be explicitly initialised in all ctor bodies.


A readonly property is completely orthogonal to a property requiring
explicit initialization. Both are orthogonal to having const as a type
modifiier. C++ mushes all these together into its notion of 'const'. I've
been trying to separate them out in these discussions.

My distaste for const is its use as a type modifier. Not its incidental use
for other purposes.


 And Walter's been completely silent about this exact point, instead
 banging on about const subversion in C++, which has precisely nothing to
 do with the request.


I believe I replied at length about exactly what Java did in this regard.
This is important, as there is a distinction between an explicit
initialization in a constructor, and explicit initialization at the member
declaration. Java does the latter, C++ the former. The two are very
different, and as your writings implied that Java had adopted the C++
notion, I wish for you to comment on which way you feel is the important
way, and why.
Mar 09 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:


 A readonly property is completely orthogonal to a property requiring
 explicit initialization. Both are orthogonal to having const as a type
 modifiier. C++ mushes all these together into its notion of 'const'. I've
 been trying to separate them out in these discussions.


I think I will call them "readonly" (const in C++), "final" (as in Java)
for the property requiring explicit initialization (a.k.a "blank final")
and "const" (like in D, meaning constant: instead of "#define PI 3.14",
free for the compiler to literally replace and "inline" with the value?)

And just like with typedef/alias, I think C picked the "wrong" keyword ?

--anders
Mar 09 2005
parent reply Ben Hinkle <Ben_member pathlink.com> writes:
In article <d0o2ge$hf5$2 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Walter wrote:


 A readonly property is completely orthogonal to a property requiring
 explicit initialization. Both are orthogonal to having const as a type
 modifiier. C++ mushes all these together into its notion of 'const'. I've
 been trying to separate them out in these discussions.


I think I will call them "readonly" (const in C++), "final" (as in Java)
for the property requiring explicit initialization (a.k.a "blank final")
and "const" (like in D, meaning constant: instead of "#define PI 3.14",
free for the compiler to literally replace and "inline" with the value?)


Not to put too fine a point on it but I'm not sure what you mean by "blank
final" here. Java's blank final is not the same as "final requiring explicit
initialization". In fact I think it's the opposite. In Java a blank final is
when a class field is declared "final" that is *not* given an initializer but is
provably assigned in every constructor.
See
Mar 09 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:


I think I will call them "readonly" (const in C++), "final" (as in Java)
for the property requiring explicit initialization (a.k.a "blank final")


 
 Not to put too fine a point on it but I'm not sure what you mean by "blank
 final" here. Java's blank final is not the same as "final requiring explicit
 initialization". In fact I think it's the opposite. In Java a blank final is
 when a class field is declared "final" that is *not* given an initializer but
is
 provably assigned in every constructor.


As usual, my code example was clear and my "explanation" sucked. Thanks.

(see Matthew's const/readonly thread)

--anders
Mar 09 2005
prev sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d0o1l2$hdo$1 digitaldaemon.com...

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d0nsvs$c1h$1 digitaldaemon.com...

 I know that it's never going to surface with the scope of C++'s 
 const,
 but I see no reason why we can't have readonly members, i.e. they 
 must
 be explicitly initialised in all ctor bodies.


 A readonly property is completely orthogonal to a property requiring
 explicit initialization. Both are orthogonal to having const as a type
 modifiier. C++ mushes all these together into its notion of 'const'. 
 I've
 been trying to separate them out in these discussions.


I completely agree with that


 My distaste for const is its use as a type modifier. Not its 
 incidental use
 for other purposes.


Great!


 And Walter's been completely silent about this exact point, instead
 banging on about const subversion in C++, which has precisely nothing 
 to
 do with the request.


 I believe I replied at length about exactly what Java did in this 
 regard.


True. I was wrong about that.


 This is important, as there is a distinction between an explicit
 initialization in a constructor, and explicit initialization at the 
 member
 declaration. Java does the latter, C++ the former. The two are very
 different, and as your writings implied that Java had adopted the C++
 notion, I wish for you to comment on which way you feel is the 
 important
 way, and why.


I already acknowledged that I'd misspoke regarding Java's final a couple 
of days ago.
Mar 09 2005
prev sibling next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
 simplified const handling (storage instead of type),


 As has been debated here many times <g>, const as a type modifier in C++ is
 so semantically weak it is fairly useless. (Many disagree.)


This is hugely disingenuous. _You_ don't think const has any use. But then
_you_ don't use const. Maybe they're related?

I find const *enormously* useful, both for its intended uses and for the
unforeseen tricks one can put it to. The
absence of such is the largest common failing in other languages that I use,
including C, Java, .NET *and* D, and a
significant part of the reason why I don't tend to use those languages for
serious development.


C and C++ are
 the only languages I've ever heard of that use const as a type modifier.

 convinced the larger programmer community that const as a type modifier has
 a place.


How can you conclude that? One might just as well surmise that the
implementation complexity is what deters these other
'communities'. After all, these other languages - Java, .NET, D - are all far
more allied to specific vendors, and are
therefore far more likely to be swayed by what's good for the vendor rather
than what's good for the programmer.

That you don't recognise/acknowledge this shows that either you're trying to
hoodwink us, or that you've succeeded too
well in hoodwinking yourself.


 I'd argue that C++ is less complete, since it relies so heavilly on STL to
 do things that are built in to most languages. Doing a general purpose
 foreach with C++ is fiendishly difficult. It's for free in D.


As a general point, I must observe that you are far too prone these days to
counter criticisms of D's feature X by
saying feature Y is great. This is just stupid.

Yes, D has many marvellous features. This is a big part of why I am excited
about D, and why I've stuck with it these
last 2.5 years.

But D also has some serious flaws, omissions, and howling stinkers.

The absence of some/all of const in D is a flaw. Period! The only debate is
where the some/all point is drawn. To
counter
by saying that Java and .NET haven't followed C++ is (i) not true, and (ii)
disingenuous. IIRC, Java does use final on
members, so one of the *fabulous powers of const in C++* has been aped. That D
has not followed this particular facet
is a manifest flaw, and cannot be explained away by 'the complexity of
using/implementing const'. It's nothing more than
an extension of your personal uninformed (since you don't use const) prejudices.

So, Walter, I say stop telling us about the great things in D. We all know and
love them. No other language I know of
can do slices, and the combination of slices, GC and auto is unparalleled.
(FGI: Walter and I are doing an article on
this "Not Your Father's Resource Management" for DDJ just as soon as I get my
fingers out of all the other pies and do
my half of it. The article shows how D is an optimal mix of C++'s and
Java/.NET's resource management paradigms, and is
superior to them all.)

What's going to stop D prospering is not
failure-to-recognise-its-many-significant-virtues, but
all-too-ready-recognition-of-its-many-significant-flaws.

Sheesh! If I went to a psychologist to get help in sorting out my many
personality flaws, I wouldn't waste her time and
my money in long and fatuous discussions about my many admirable traits!!!
Mar 07 2005
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d0idln$97o$1 digitaldaemon.com...

 simplified const handling (storage instead of type),


 As has been debated here many times <g>, const as a type modifier in C++




is

 so semantically weak it is fairly useless. (Many disagree.)


 This is hugely disingenuous. _You_ don't think const has any use.


Right - many disagree - and I was thinking specifically of you!


 But then _you_ don't use const. Maybe they're related?


I used to use const as a type modifier. I gave it up after becoming
disenchanted with it. I use const as a storage class all the time. (The two
uses are very different,  although they look the same in C++. I wish to
emphasize the difference, as sometimes in these threads they incorrectly get
referred to interchangeably.)


 That you don't recognise/acknowledge this shows that either you're trying


to hoodwink us, or that you've succeeded too

 well in hoodwinking yourself.


I understand that you made a convincing argument. I respectfully suggest,
however, that doesn't necessarilly mean I was convinced and am therefore
trying to argue things I secretly believe to be false.

I know exactly how to implement const as a type modifier. If I believed it
was the right thing to do, I'd do it. Microsoft and Sun both have inhouse
C++ compilers under active development, and they know how to do it, too.

no idea exactly how the decision came about not to use const as a type
modifier (as distinct from const as a storage class), but you can bet your
last dollar that if they felt it had high value, it'd be implemented. This
is one reason why I don't think I am way out of step in my opinion on const
as a type modifier.


 I'd argue that C++ is less complete, since it relies so heavilly on STL




to

 do things that are built in to most languages. Doing a general purpose
 foreach with C++ is fiendishly difficult. It's for free in D.


 As a general point, I must observe that you are far too prone these days


to counter criticisms of D's feature X by

 saying feature Y is great. This is just stupid.


The thread is about whether C++ and D are "complete" languages or not, and I
wrote that comment should in that context.


 The absence of some/all of const in D is a flaw. Period! The only debate


is where the some/all point is drawn. To

 counter
 by saying that Java and .NET haven't followed C++ is (i) not true, and


(ii) disingenuous. IIRC, Java does use final on

 members, so one of the *fabulous powers of const in C++* has been aped.


That D has not followed this particular facet

 is a manifest flaw, and cannot be explained away by 'the complexity of


using/implementing const'.

Java's 'final' is a storage class, not a type modifier. Its use on a field
does not require the constructor to have an initializer for it. In fact, it
is illegal to set 'final' fields inside a constructor. The initializer for
the 'final' field must appear immediately after the declaration of the
field, outside of any constructor. Therefore, constructor parameters cannot
influence the setting of 'final' fields. Also, if one has multiple
constructors in Java, and one 'forgets' to initialize one of the fields, no
diagnostic is issued. The field gets default initialized. I'd argue it is a
fairly different beast in Java than in C++, since it is not aping the C++
feature of getting diagnostics from the constructor about uninitialized
const fields.

What Java's 'final' does share with C++ const fields is that the compiler
will diagnose attempts to modify the field after it is set. Java did it
right, though, as Java doesn't allow casting away of constness, or non-const
references to the same field modifying it out from under you. 'final' fields
in Java are solid enough that the compiler can optimize based on it, and
they have meaning in multithreaded apps, which is not the case in C++.

I have no issue with const and final as a storage class, I believe they are
valuable and useful, and const is implemented as a storage class in D (its
use could probably be profitably extended to more contexts). I don't agree
with its value as a type modifier, for oft stated reasons that I will
summarize as being that in legal, standard conforming C++ code the value of
the presumably 'const' data can change at any moment. Const things ought to
be, dagnamit, constant.
Mar 07 2005
next sibling parent reply Kris <Kris_member pathlink.com> writes:
In article <d0iiqi$emd$1 digitaldaemon.com>, Walter says...

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d0idln$97o$1 digitaldaemon.com...

 simplified const handling (storage instead of type),


 As has been debated here many times <g>, const as a type modifier in C++




is

 so semantically weak it is fairly useless. (Many disagree.)


 This is hugely disingenuous. _You_ don't think const has any use.


Right - many disagree - and I was thinking specifically of you!


 But then _you_ don't use const. Maybe they're related?


I used to use const as a type modifier. I gave it up after becoming
disenchanted with it. I use const as a storage class all the time. (The two
uses are very different,  although they look the same in C++. I wish to
emphasize the difference, as sometimes in these threads they incorrectly get
referred to interchangeably.)


 That you don't recognise/acknowledge this shows that either you're trying


to hoodwink us, or that you've succeeded too

 well in hoodwinking yourself.


I understand that you made a convincing argument. I respectfully suggest,
however, that doesn't necessarilly mean I was convinced and am therefore
trying to argue things I secretly believe to be false.

I know exactly how to implement const as a type modifier. If I believed it
was the right thing to do, I'd do it. Microsoft and Sun both have inhouse
C++ compilers under active development, and they know how to do it, too.

no idea exactly how the decision came about not to use const as a type
modifier (as distinct from const as a storage class), but you can bet your
last dollar that if they felt it had high value, it'd be implemented. This
is one reason why I don't think I am way out of step in my opinion on const
as a type modifier.


 I'd argue that C++ is less complete, since it relies so heavilly on STL




to

 do things that are built in to most languages. Doing a general purpose
 foreach with C++ is fiendishly difficult. It's for free in D.


 As a general point, I must observe that you are far too prone these days


to counter criticisms of D's feature X by

 saying feature Y is great. This is just stupid.


The thread is about whether C++ and D are "complete" languages or not, and I
wrote that comment should in that context.


 The absence of some/all of const in D is a flaw. Period! The only debate


is where the some/all point is drawn. To

 counter
 by saying that Java and .NET haven't followed C++ is (i) not true, and


(ii) disingenuous. IIRC, Java does use final on

 members, so one of the *fabulous powers of const in C++* has been aped.


That D has not followed this particular facet

 is a manifest flaw, and cannot be explained away by 'the complexity of


using/implementing const'.

Java's 'final' is a storage class, not a type modifier. Its use on a field
does not require the constructor to have an initializer for it. In fact, it
is illegal to set 'final' fields inside a constructor. The initializer for
the 'final' field must appear immediately after the declaration of the
field, outside of any constructor. Therefore, constructor parameters cannot
influence the setting of 'final' fields. Also, if one has multiple
constructors in Java, and one 'forgets' to initialize one of the fields, no
diagnostic is issued. The field gets default initialized. I'd argue it is a
fairly different beast in Java than in C++, since it is not aping the C++
feature of getting diagnostics from the constructor about uninitialized
const fields.

What Java's 'final' does share with C++ const fields is that the compiler
will diagnose attempts to modify the field after it is set. Java did it
right, though, as Java doesn't allow casting away of constness, or non-const
references to the same field modifying it out from under you. 'final' fields
in Java are solid enough that the compiler can optimize based on it, and
they have meaning in multithreaded apps, which is not the case in C++.

I have no issue with const and final as a storage class, I believe they are
valuable and useful, and const is implemented as a storage class in D (its
use could probably be profitably extended to more contexts). I don't agree
with its value as a type modifier, for oft stated reasons that I will
summarize as being that in legal, standard conforming C++ code the value of
the presumably 'const' data can change at any moment. Const things ought to
be, dagnamit, constant.



Very glad to hear you opinion on this. I, for one, agree 100%. 

If you could provide a D mechanism for making scalar and vector data "appear" to
be fully constant (as in the storage class) to third-parties (think return
values), then we'd have the read-only enforcement so many of us are crying out
for. That could easily become a major advantage for D over other languages.

In addition, the utility of a true storage-constant attribute (one that is also
supported via call-by-reference ~ inout obviously does not work) then that would
open up additional avenues for D.
Mar 07 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Kris" <Kris_member pathlink.com> wrote in message
news:d0ilcf$hbt$1 digitaldaemon.com...

 In article <d0iiqi$emd$1 digitaldaemon.com>, Walter says...

What Java's 'final' does share with C++ const fields is that the compiler
will diagnose attempts to modify the field after it is set. Java did it
right, though, as Java doesn't allow casting away of constness, or




non-const

references to the same field modifying it out from under you. 'final'




fields

in Java are solid enough that the compiler can optimize based on it, and
they have meaning in multithreaded apps, which is not the case in C++.

I have no issue with const and final as a storage class, I believe they




are

valuable and useful, and const is implemented as a storage class in D




(its

use could probably be profitably extended to more contexts). I don't




agree

with its value as a type modifier, for oft stated reasons that I will
summarize as being that in legal, standard conforming C++ code the value




of

the presumably 'const' data can change at any moment. Const things ought




to

be, dagnamit, constant.



 Very glad to hear you opinion on this. I, for one, agree 100%.


Good. To put it another way, anything labeled as 'const' could be burned
into ROM without changing the meaning of the program. (This is also implies
that const data must have initializers that can be evaluated at compile
time.)


 If you could provide a D mechanism for making scalar and vector data


"appear" to

 be fully constant (as in the storage class) to third-parties (think return
 values), then we'd have the read-only enforcement so many of us are crying


out

 for. That could easily become a major advantage for D over other


languages.

 In addition, the utility of a true storage-constant attribute (one that is


also

 supported via call-by-reference ~ inout obviously does not work) then that


would

 open up additional avenues for D.


Fundamentally connected with this is the problem of aliased function
parameters. Get it wrong, as C and C++ do, and you cannot build an optimizer
that is competitive with FORTRAN optimizers.
Mar 07 2005
parent reply Kris <Kris_member pathlink.com> writes:
In article <d0ip9t$lmv$1 digitaldaemon.com>, Walter says...


Good. To put it another way, anything labeled as 'const' could be burned
into ROM without changing the meaning of the program. (This is also implies
that const data must have initializers that can be evaluated at compile
time.)


 If you could provide a D mechanism for making scalar and vector data


"appear" to

 be fully constant (as in the storage class) to third-parties (think return
 values), then we'd have the read-only enforcement so many of us are crying


out

 for. That could easily become a major advantage for D over other


languages.

 In addition, the utility of a true storage-constant attribute (one that is


also

 supported via call-by-reference ~ inout obviously does not work) then that


would

 open up additional avenues for D.


Fundamentally connected with this is the problem of aliased function
parameters. Get it wrong, as C and C++ do, and you cannot build an optimizer
that is competitive with FORTRAN optimizers.



Also agreed, 100%. It's just that we want that 'right' functionality,and
preferably sooner rather than later :~)
Mar 07 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Kris" <Kris_member pathlink.com> wrote in message
news:d0ir8c$nlr$1 digitaldaemon.com...

Fundamentally connected with this is the problem of aliased function
parameters. Get it wrong, as C and C++ do, and you cannot build an




optimizer

that is competitive with FORTRAN optimizers.



 Also agreed, 100%. It's just that we want that 'right' functionality,and
 preferably sooner rather than later :~)


Realistically, it's a 2.0 issue. I've promised Norbert I'd go through the
array semantics with him for that.
Mar 07 2005
parent kris <fu bar.org> writes:
OK. Appreciate you being up-front and candid about it.


Walter wrote:

 "Kris" <Kris_member pathlink.com> wrote in message
 news:d0ir8c$nlr$1 digitaldaemon.com...
 

Fundamentally connected with this is the problem of aliased function
parameters. Get it wrong, as C and C++ do, and you cannot build an




 
 optimizer
 

that is competitive with FORTRAN optimizers.



Also agreed, 100%. It's just that we want that 'right' functionality,and
preferably sooner rather than later :~)


 
 
 Realistically, it's a 2.0 issue. I've promised Norbert I'd go through the
 array semantics with him for that.
Mar 08 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 7 Mar 2005 13:44:43 -0800, Walter wrote:


 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:d0idln$97o$1 digitaldaemon.com...

 simplified const handling (storage instead of type),


 As has been debated here many times <g>, const as a type modifier in C++




 is

 so semantically weak it is fairly useless. (Many disagree.)


 This is hugely disingenuous. _You_ don't think const has any use.


 
 Right - many disagree - and I was thinking specifically of you!
 

 But then _you_ don't use const. Maybe they're related?


 
 I used to use const as a type modifier. I gave it up after becoming
 disenchanted with it. I use const as a storage class all the time. (The two
 uses are very different,  although they look the same in C++. I wish to
 emphasize the difference, as sometimes in these threads they incorrectly get
 referred to interchangeably.)
 

 That you don't recognise/acknowledge this shows that either you're trying


 to hoodwink us, or that you've succeeded too

 well in hoodwinking yourself.


 
 I understand that you made a convincing argument. I respectfully suggest,
 however, that doesn't necessarilly mean I was convinced and am therefore
 trying to argue things I secretly believe to be false.
 
 I know exactly how to implement const as a type modifier. If I believed it
 was the right thing to do, I'd do it. Microsoft and Sun both have inhouse
 C++ compilers under active development, and they know how to do it, too.

 no idea exactly how the decision came about not to use const as a type
 modifier (as distinct from const as a storage class), but you can bet your
 last dollar that if they felt it had high value, it'd be implemented. This
 is one reason why I don't think I am way out of step in my opinion on const
 as a type modifier.
 

 I'd argue that C++ is less complete, since it relies so heavilly on STL




 to

 do things that are built in to most languages. Doing a general purpose
 foreach with C++ is fiendishly difficult. It's for free in D.


 As a general point, I must observe that you are far too prone these days


 to counter criticisms of D's feature X by

 saying feature Y is great. This is just stupid.


 
 The thread is about whether C++ and D are "complete" languages or not, and I
 wrote that comment should in that context.
 

 The absence of some/all of const in D is a flaw. Period! The only debate


 is where the some/all point is drawn. To

 counter
 by saying that Java and .NET haven't followed C++ is (i) not true, and


 (ii) disingenuous. IIRC, Java does use final on

 members, so one of the *fabulous powers of const in C++* has been aped.


 That D has not followed this particular facet

 is a manifest flaw, and cannot be explained away by 'the complexity of


 using/implementing const'.
 
 Java's 'final' is a storage class, not a type modifier. Its use on a field
 does not require the constructor to have an initializer for it. In fact, it
 is illegal to set 'final' fields inside a constructor. The initializer for
 the 'final' field must appear immediately after the declaration of the
 field, outside of any constructor. Therefore, constructor parameters cannot
 influence the setting of 'final' fields. Also, if one has multiple
 constructors in Java, and one 'forgets' to initialize one of the fields, no
 diagnostic is issued. The field gets default initialized. I'd argue it is a
 fairly different beast in Java than in C++, since it is not aping the C++
 feature of getting diagnostics from the constructor about uninitialized
 const fields.
 
 What Java's 'final' does share with C++ const fields is that the compiler
 will diagnose attempts to modify the field after it is set. Java did it
 right, though, as Java doesn't allow casting away of constness, or non-const
 references to the same field modifying it out from under you. 'final' fields
 in Java are solid enough that the compiler can optimize based on it, and
 they have meaning in multithreaded apps, which is not the case in C++.
 
 I have no issue with const and final as a storage class, I believe they are
 valuable and useful, and const is implemented as a storage class in D (its
 use could probably be profitably extended to more contexts). I don't agree
 with its value as a type modifier, for oft stated reasons that I will
 summarize as being that in legal, standard conforming C++ code the value of
 the presumably 'const' data can change at any moment. Const things ought to
 be, dagnamit, constant.


I'm getting too confused with all this 'storage class' and 'type modifier'
talk. Sorry but I'm not a C++ nor a Java coder, so these terms are a bit
cloudy. This is what I can understand so far from these discussions ...

const "storage class":
 The data is defined at compile time and RAM is reserved for the
information. No part of the application is allowed to modify the data
during run time.

const "type modifer":
 The data is stored by one part of the application but is not allowed to be
modified by another part of the application.

I can see a really good use for what I've called 'type modifier'. Passing
something by reference to a routine, but not allowing that routine to
modify the data passed to it. Currently, the only obvious way to do that in
D is to pass a copy of the data and throw it away once the routine has
returned.

  void Bar(char[] x)
  {
     x[4] = 'b';
  }

  void Foo(char[] X)
  {
     X[0] = 'a';
     Bar(x);
  }

  . . .
  char[] Y = "derek";
  Foo(Y.dup);  // Ignore any changes that 'Foo' might make to Y.


But a nicer, more obvious, more explicit in declaring coding intentions,
would be do something like ...

  void Foo(PRESERVE char[] X)
  {
     X[0] = 'a';  // Compiler would flag this as an error.
     Bar(x);  // Compiler might have to pass a copy of x.
  }

  . . .
  char[] Y = "derek";
  Foo(Y); 

I don't know how to implement this efficiently, but that is not the issue.
The issue is that as a coder/designer, I must have the data in the passed
argument to by unchanged after calling the routine.

-- 
Derek
Melbourne, Australia
8/03/2005 9:59:25 AM
Mar 07 2005
parent brad domain.invalid writes:
 const "storage class":
  The data is defined at compile time and RAM is reserved for the
 information. No part of the application is allowed to modify the data
 during run time.
 


 From an embedded systems point of view, const data can also live in ROM 
(well, it should be able to) - many small systems do use this trick to 
save RAM usage.  ROM also physically prevents you from modifying the 
variable, as such you shouldn't try to do dirty tricks to modify a const 
variable.  I bring this up because I do embedded stuff for a living, and 
I don't see anything in D which precludes it from being used in small 
systems.

Brad
Mar 07 2005
prev sibling parent reply Kris <Kris_member pathlink.com> writes:
Amen. 

It's exactly this kind of thing that has so often worn me down to the bone [and
why my sometimes inappropriate commentary joins the party; for which I do
apologize] 

I believe we should understand that D belongs to all of us. Everyone who has
contributed in one form or another (through adopted ideas, through NG posts,
through being a D evangelist, through writing supporting libraries, through
examples, tutorials, and wiki's, through providing supporting web-services such
as dsource.org and this NG, etc. etc.) *own* a piece of D. I don't think Walter
could, or would, claim that D is his own thing at this time (in fact, our
combined little bits of ownership probably amount to something rather
significant). 

As such, we kinda' owe it to ourselves to ensure the development of "our"
language is 'managed' more effectively. After all, D requires a grass-roots
approach to language adoption (in contrast to the marketing and financial clout
of a .NET approach); it's people like us who will ultimately push for adoption
of D within our own spheres of influence.


I'm noting this for three reasons: 

1) you should realize that D is /your/ language ~ not someone else's. It will
become mainstream not when D matures per se, but when each and all of us urge
our development groups to consider adopting it. Walter has never spelt this out,
but he's fully dependent upon each of us for the success of D (unless it's
perhaps just a jolly wheeze instead). 

When I see people talking about "Walter's language" it suggests either "Walter
is a shallow and hollow individual" or "I can't personally accept the
responsibility for making this better". There's probably plenty of room between,
but you get the drift? We, each of us, is expected to do the hard work of local
adoption. So we should get used to the ownership idea.

2) we deserve, and should expect more in terms of a transparent development
process. Right now, it's almost completely opaque (save for the rare and
occasional glimmer of a proactive request, such as the recent "$ or length?"
topic initiated by Walter himself). I mean, at this point, a rational and
constructive discourse over how to improve D in specific areas is the exception,
rather than the norm. Instead, what's attached below typifies the reaction. This
is surely a bad sign, and it is something that (IMO) Walter should reflect
heavily upon. 

3) Historically, there's been a lot of talk with very little action. For
example, people have often lamented over the weaknesses of the D libraries.
However, how many of you are willing to do something about changing that? We've
got to take some responsibility ourselves to change things; be a bit more
constructive and a lot more cooperative. Talk is cheap. There are perhaps one or
two dozen people who are /really/ trying to contribute to D in this particular
manner ... they can always use a bit of help! If you want good libraries for D,
write them yourselves, or better, get some momentum going with others via the
Ares project (over at dsource).

Something to think about.

- Kris


(p.s. please forgive me for hijacking your post, Matthew; but for a moment there
you sounded just like me)



In article <d0idln$97o$1 digitaldaemon.com>, Matthew says...

 simplified const handling (storage instead of type),


 As has been debated here many times <g>, const as a type modifier in C++ is
 so semantically weak it is fairly useless. (Many disagree.)


This is hugely disingenuous. _You_ don't think const has any use. But then
_you_ don't use const. Maybe they're related?

I find const *enormously* useful, both for its intended uses and for the
unforeseen tricks one can put it to. The
absence of such is the largest common failing in other languages that I use,
including C, Java, .NET *and* D, and a
significant part of the reason why I don't tend to use those languages for
serious development.


C and C++ are
 the only languages I've ever heard of that use const as a type modifier.

 convinced the larger programmer community that const as a type modifier has
 a place.


How can you conclude that? One might just as well surmise that the
implementation complexity is what deters these other
'communities'. After all, these other languages - Java, .NET, D - are all far
more allied to specific vendors, and are
therefore far more likely to be swayed by what's good for the vendor rather
than what's good for the programmer.

That you don't recognise/acknowledge this shows that either you're trying to
hoodwink us, or that you've succeeded too
well in hoodwinking yourself.


 I'd argue that C++ is less complete, since it relies so heavilly on STL to
 do things that are built in to most languages. Doing a general purpose
 foreach with C++ is fiendishly difficult. It's for free in D.


As a general point, I must observe that you are far too prone these days to
counter criticisms of D's feature X by
saying feature Y is great. This is just stupid.

Yes, D has many marvellous features. This is a big part of why I am excited
about D, and why I've stuck with it these
last 2.5 years.

But D also has some serious flaws, omissions, and howling stinkers.

The absence of some/all of const in D is a flaw. Period! The only debate is
where the some/all point is drawn. To
counter
by saying that Java and .NET haven't followed C++ is (i) not true, and (ii)
disingenuous. IIRC, Java does use final on
members, so one of the *fabulous powers of const in C++* has been aped. That D
has not followed this particular facet
is a manifest flaw, and cannot be explained away by 'the complexity of
using/implementing const'. It's nothing more than
an extension of your personal uninformed (since you don't use const) prejudices.

So, Walter, I say stop telling us about the great things in D. We all know and
love them. No other language I know of
can do slices, and the combination of slices, GC and auto is unparalleled.
(FGI: Walter and I are doing an article on
this "Not Your Father's Resource Management" for DDJ just as soon as I get my
fingers out of all the other pies and do
my half of it. The article shows how D is an optimal mix of C++'s and
Java/.NET's resource management paradigms, and is
superior to them all.)

What's going to stop D prospering is not
failure-to-recognise-its-many-significant-virtues, but
all-too-ready-recognition-of-its-many-significant-flaws.

Sheesh! If I went to a psychologist to get help in sorting out my many
personality flaws, I wouldn't waste her time and
my money in long and fatuous discussions about my many admirable traits!!!
Mar 07 2005
parent John Reimer <brk_6502 yahoo.com> writes:
Agreed, Kris.

A good, thought-provoking post.  Everybody should be considering these 
things.

Thanks,

- JJR

Kris wrote:

 Amen. 
 
 It's exactly this kind of thing that has so often worn me down to the bone [and
 why my sometimes inappropriate commentary joins the party; for which I do
 apologize] 
 
 I believe we should understand that D belongs to all of us. Everyone who has
 contributed in one form or another (through adopted ideas, through NG posts,
 through being a D evangelist, through writing supporting libraries, through
 examples, tutorials, and wiki's, through providing supporting web-services such
 as dsource.org and this NG, etc. etc.) *own* a piece of D. I don't think Walter
 could, or would, claim that D is his own thing at this time (in fact, our
 combined little bits of ownership probably amount to something rather
 significant). 
 
 As such, we kinda' owe it to ourselves to ensure the development of "our"
 language is 'managed' more effectively. After all, D requires a grass-roots
 approach to language adoption (in contrast to the marketing and financial clout
 of a .NET approach); it's people like us who will ultimately push for adoption
 of D within our own spheres of influence.
 
 
 I'm noting this for three reasons: 
 
 1) you should realize that D is /your/ language ~ not someone else's. It will
 become mainstream not when D matures per se, but when each and all of us urge
 our development groups to consider adopting it. Walter has never spelt this
out,
 but he's fully dependent upon each of us for the success of D (unless it's
 perhaps just a jolly wheeze instead). 
 
 When I see people talking about "Walter's language" it suggests either "Walter
 is a shallow and hollow individual" or "I can't personally accept the
 responsibility for making this better". There's probably plenty of room
between,
 but you get the drift? We, each of us, is expected to do the hard work of local
 adoption. So we should get used to the ownership idea.
 
 2) we deserve, and should expect more in terms of a transparent development
 process. Right now, it's almost completely opaque (save for the rare and
 occasional glimmer of a proactive request, such as the recent "$ or length?"
 topic initiated by Walter himself). I mean, at this point, a rational and
 constructive discourse over how to improve D in specific areas is the
exception,
 rather than the norm. Instead, what's attached below typifies the reaction.
This
 is surely a bad sign, and it is something that (IMO) Walter should reflect
 heavily upon. 
 
 3) Historically, there's been a lot of talk with very little action. For
 example, people have often lamented over the weaknesses of the D libraries.
 However, how many of you are willing to do something about changing that? We've
 got to take some responsibility ourselves to change things; be a bit more
 constructive and a lot more cooperative. Talk is cheap. There are perhaps one
or
 two dozen people who are /really/ trying to contribute to D in this particular
 manner ... they can always use a bit of help! If you want good libraries for D,
 write them yourselves, or better, get some momentum going with others via the
 Ares project (over at dsource).
 
 Something to think about.
 
 - Kris
 
 
 (p.s. please forgive me for hijacking your post, Matthew; but for a moment
there
 you sounded just like me)
Mar 08 2005
prev sibling next sibling parent reply "Rob Grainger" <nospam nospam.com> writes:
Walter,

Actually, I think you'll find that DCE invented IDL, and Microsoft just 
ported it. Actually IDL originally targetted C, so I guess
the reference issue had no impact on its design. If you look at earliest 
implementations of IUnknown, you'll notice that QueryInterface
(along with a lot of similar interfaces) uses a REFIID, which in C++ is 
defined as an IID&, in C and IID*, so the issues really predate
COM even - blame DCE RPC for these ones.

Furthermore, IDL as originally conceived was designed to allow writing 
proxy/stub implementations for Remote Procedure Calls, and
allows much more flexibility that are glossed over there - such as 
implementing custom-marshalled types, etc.

Just to clear things up.

Again, with const I absolutely disagree - placing a const on a parameter 
tells the compiler that the function called cannot modify the parameter, so 
its free to make all sort of optimisations not otherwise possible 
(especially with pointer parameters). Also, it can catch
many programmer errors at compile times (saving much more tedious runtime 
error-hunting later). Finally, I believe it makes the contract
that much more explicit. In C++, the main undermining factor comes from 
compatibility with pre-existing code (the desire for most correct C code to 
be correct C++ code) - often a severe problem in C++. In particular, many 
libraries/API's do not declare there parameters correctly, hence the need 
for const_cast, these issues shouldn't really apply to D, where they can be 
encapsulated at the interface, so I cannot see a good reason not to include 
it.

As for the for_each problem, <algorithm> provides a nice solution called, 
wait for it, for_each. Given a container..

    vector<int> v;

    // ...

    for_each(v.begin(); v.end(), functor);

Doesn't look all that complex to me...

Rob
Mar 08 2005
parent reply "Walter" <newshound digitalmars.com> writes:
Note: in the following, I am referring to const as a type modifier, as
distinct from const as a storage class. I find const as a storage class to
be useful and desirable.


"Rob Grainger" <nospam nospam.com> wrote in message
news:d0le44$m64$1 digitaldaemon.com...

 Actually, I think you'll find that DCE invented IDL, and Microsoft just
 ported it. Actually IDL originally targetted C, so I guess
 the reference issue had no impact on its design.


But the issue of what's in, out, and inout did impact, and it's still why
people need to use it.


 If you look at earliest
 implementations of IUnknown, you'll notice that QueryInterface
 (along with a lot of similar interfaces) uses a REFIID, which in C++ is
 defined as an IID&, in C and IID*, so the issues really predate
 COM even - blame DCE RPC for these ones.

 Furthermore, IDL as originally conceived was designed to allow writing
 proxy/stub implementations for Remote Procedure Calls, and
 allows much more flexibility that are glossed over there - such as
 implementing custom-marshalled types, etc.

 Just to clear things up.


Thanks.


 Again, with const I absolutely disagree - placing a const on a parameter
 tells the compiler that the function called cannot modify the parameter,


so

 its free to make all sort of optimisations not otherwise possible
 (especially with pointer parameters).


No, it can't. The optimizer can't make any use of const, because legal,
standard conforming C++ code can modify const values. Similarly,
multithreaded code cannot assume that const references remain constant. Does
this happen in practice? It sure does, as I found out when adjusting the
optimizer to take advantage of const. Lots of code breaks.


 Also, it can catch
 many programmer errors at compile times (saving much more tedious runtime
 error-hunting later).


That's the idea, but do such errors happen very often? Not in my experience,
using it for years never found an actual bug (though it found a lot of
const-correctness issues, none of them were actual bugs). The additional
failure of const to provide any useful optimization opportunities kinda
sealed its fate. Note that Matthew strongly disagrees with me on these
points.


 Finally, I believe it makes the contract
 that much more explicit. In C++, the main undermining factor comes from
 compatibility with pre-existing code (the desire for most correct C code


to

 be correct C++ code) - often a severe problem in C++. In particular, many
 libraries/API's do not declare there parameters correctly, hence the need
 for const_cast, these issues shouldn't really apply to D, where they can


be

 encapsulated at the interface, so I cannot see a good reason not to


include

 it.


I've seen a lot of C++ code, and when the author of it has made the effort
to make it const-correct, it's pretty loaded up with const keywords. I
believe it adds a lot of visual complexity, without commensurate benefits.
If const came with guarantees that the data would not be modified (unlike
C++), then it might have value.


 As for the for_each problem, <algorithm> provides a nice solution called,
 wait for it, for_each. Given a container..

     vector<int> v;

     // ...

     for_each(v.begin(); v.end(), functor);

 Doesn't look all that complex to me...


Try the following D code with C++'s std::for_each:

    foreach (int value; collection)
    {
        if (value == 6)
            return 3;
    }

Eric Niebler has gotten much further with for_each in C++ using complex
macros, but I haven't studied his work.
Mar 08 2005
parent reply "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"Walter" <newshound digitalmars.com> skrev i en meddelelse 
news:d0lha7$p50$1 digitaldaemon.com...

 I've seen a lot of C++ code, and when the author of it has made the effort
 to make it const-correct, it's pretty loaded up with const keywords. I
 believe it adds a lot of visual complexity, without commensurate benefits.
 If const came with guarantees that the data would not be modified (unlike
 C++), then it might have value.


I'm also in the camp missing the 'const'. I easily see your point about it 
having no value to the compiler/optimizer, but that is not the only point. 
In this article:

    http://www.developerdotstar.com/mag/articles/reeves_design_main.html

the author argues that the code is the design, and coding is a design 
activity. He also argues that:

    "What we really need is more expressive programming languages.
    This is what led to my statement about C++ being a major advance
    in software design art. C++ is a more expressive programming
    language, which makes it a better software design tool."

'const' is one of those features that makes it a more expressive language 
and a better software design tool. Your point about it being useless to the 
compiler doesn't really matter in this respect.

Regards,
Martin



 As for the for_each problem, <algorithm> provides a nice solution called,
 wait for it, for_each. Given a container..

     vector<int> v;

     // ...

     for_each(v.begin(); v.end(), functor);

 Doesn't look all that complex to me...


 Try the following D code with C++'s std::for_each:

    foreach (int value; collection)
    {
        if (value == 6)
            return 3;
    }

 Eric Niebler has gotten much further with for_each in C++ using complex
 macros, but I haven't studied his work.
Mar 08 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Martin M. Pedersen" <martin moeller-pedersen.dk> wrote in message
news:d0lj8v$quo$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> skrev i en meddelelse
 news:d0lha7$p50$1 digitaldaemon.com...

 I've seen a lot of C++ code, and when the author of it has made the




effort

 to make it const-correct, it's pretty loaded up with const keywords. I
 believe it adds a lot of visual complexity, without commensurate




benefits.

 If const came with guarantees that the data would not be modified




(unlike

 C++), then it might have value.


 I'm also in the camp missing the 'const'. I easily see your point about it
 having no value to the compiler/optimizer, but that is not the only point.
 In this article:

     http://www.developerdotstar.com/mag/articles/reeves_design_main.html

 the author argues that the code is the design, and coding is a design
 activity. He also argues that:

     "What we really need is more expressive programming languages.
     This is what led to my statement about C++ being a major advance
     in software design art. C++ is a more expressive programming
     language, which makes it a better software design tool."


In general, I agree with the author that the code is the design. I also
agree that C++ is very expressive, and a big advance in programming.


 'const' is one of those features that makes it a more expressive language
 and a better software design tool. Your point about it being useless to


the

 compiler doesn't really matter in this respect.


True, it does add some semantic information, and as such, it can be used to
improve design. But if its semantic value is useless to the compiler, then
you are relying on it having semantic value based on a convention of usage,
and are assuming that the author is following the convention and has applied
it correctly. It's value is more than adding a comment /*const*/, but not
much more.

For comparison, C++ doesn't have in, out or inout for function parameters.
This is a serious deficiency in the expressivity of a function's interface,
leading to such commenting conventions as /*[in]*/, /*[out]*/, /*[out][in]*/
for parameters. I think these being part of D are far more valuable in
expressing a function's interface than const, especially since they can be
relied upon. Some have argued here that 'in' parameters in D should be not
modifiable. It's a perfectly reasonable convention, and if one adopts it,
doesn't that provide what you're looking for?

I have a couple other beefs with C++ const. The first is that it's
misleading, and lures even experienced programmers into thinking that the
values actually are constant. The second is that pretty much nobody knows
how it works. I regularly receive emails the gist of which reads like "I'm
having a problem using const. Compilers from X, Y, Z all behave differently.
I don't know which is right." These emails aren't coming from C++ newbies -
they come from acknowledged experts in the field, people who have used C++
for over a decade, people who are published C++ authors. The behavior is so
murky that they can't figure out what the Standard says, and instead pick
compiler Brand X as the arbiter of "how it's supposed to work." If a decade
of language lawyers can't clearly express how it works, I suspect it may not
be the best way to express a design. (Granted, the examples giving grief
tend to be less common usages, and convoluted to boot, but they should be
understandable by applying simple, standard rules, and they're not.)
Mar 09 2005
parent reply "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"Walter" <newshound digitalmars.com> skrev i en meddelelse 
news:d0n7pu$2kf2$1 digitaldaemon.com...

 True, it does add some semantic information, and as such, it can be used 
 to
 improve design. But if its semantic value is useless to the compiler, then
 you are relying on it having semantic value based on a convention of 
 usage,
 and are assuming that the author is following the convention and has 
 applied
 it correctly. It's value is more than adding a comment /*const*/, but not
 much more.


How much more can always be discussed, and our experiences will vary. I see 
it as a tool for expressing design, and having the compiler help me 
enforcing it. Even if the compiler cannot give me any guarentees, it can 
help me in the right direction. To me, that is much more value than a 
comment.

I will not argue that C++ has got the const-stuff right. But is has got 
quite a few mechanisms that all help express a design:

    1. References that are really pinned pointers; ie. the pointer itself is 
'const'.
    2. 'const' arguments
    3. 'const' methods
    4. 'const' member variables

Why references syntaxtically are different beast than pointers, beats me. 
The reason may be found in the C inheritage. D does not have that inheritage 
and combined the concepts, which is a good thing.

We can easily agree that 'const' is overly misused and misleading.

'const' arguments as found in C++ really does mean read-only as you and 
others have pointed out. But even though not perfect, it does help express 
design.

Then we have 'const' methods, which have nothing const about them either. A 
better term would be "non-mutable" or even "pure" which is stronger because 
it says something about side-effects too. Still, I can use 'const' in the 
sense of "non-mutable" to help express and enforce design.

In C++, I do not see 'const' member variables as important simply because a 
good interface does not expose them. I see them more as a necessity for 
having non-mutable methods. A wierd thing is "mutable" that introduces 
"faked non-mutable" as a language concept in its own right :-( Please 
promise never to add that kind of thing to D. In D the situation is 
different, though, because the concept of properties better allow them to be 
exposed. Perhaps "final" as you have proposed is the way to go - I don't 
know, but I do think its needs consideration.


 For comparison, C++ doesn't have in, out or inout for function parameters.
 This is a serious deficiency in the expressivity of a function's 
 interface,
 leading to such commenting conventions as /*[in]*/, /*[out]*/, 
 /*[out][in]*/
 for parameters. I think these being part of D are far more valuable in
 expressing a function's interface than const, especially since they can be
 relied upon. Some have argued here that 'in' parameters in D should be not
 modifiable. It's a perfectly reasonable convention, and if one adopts it,
 doesn't that provide what you're looking for?


I agree that "in", "out", and "inout" are good, but I can't see how they can 
replace the C++ mechanisms.

If 'in' arguments were read-only by convention only, it would have no more 
value than adding the /* const */ comment. Having it enforced by the 
compiler would bring me a bit further, but not as long as I can come with 
C++. In C++ I can specify if it is the pointer and/or the referenced object 
that is read-only. The pointer is specify as read-only by using a reference 
instead. The referenced object is specified read-only by applying 'const'. 
Then there is the situation where the 'in' reference is stored in a member 
variable. C++ can help me enforce (even if it cannot make any guarantee) my 
design in this situation.

'out' and 'inout' does not have any counterparts in C++. As such, they 
provide a valuable addition.

Another valuable addition in D compared to C++ is interfaces. Explicit 
interfaces are very good compared to C++ where a class can be an interface 
as a consequence of something you don't write.


 The second is that pretty much nobody knows
 how it works. I regularly receive emails the gist of which reads like "I'm
 having a problem using const.


I'm have made a habit of using 'const' all the time. I do that by intuition, 
and are not very conscious about it anymore. I simply do not write code that 
is not const-correct, and I haven't experienced such problems. But perhaps 
I'm not experienced enough to get myself into those situations you mention, 
and stick to simpler code.

I suspect part of the problem is the obscure declarators of C that is even 
worse in C++. Is that correct? It that is so, D has the oppertunity to 
rectify the situation, and I believe D had already largely done that. 15 
years ago, I moved from Turbo Pascal to C and C++. One of the major 
obstacles I experienced was the declarators. They still puzzles me, and yet, 
they do not provide anything that I could not do in Pascal.

Regards,
Martin
Mar 09 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Martin M. Pedersen" <martin moeller-pedersen.dk> wrote in message
news:d0nj0k$bi$1 digitaldaemon.com...

 I'm have made a habit of using 'const' all the time. I do that by


intuition,

 and are not very conscious about it anymore. I simply do not write code


that

 is not const-correct, and I haven't experienced such problems. But perhaps
 I'm not experienced enough to get myself into those situations you


mention,

 and stick to simpler code.


Oddly, I took the opposite approach. I dropped all use of 'const' that
wasn't for declaration of constants. Instead, I treat all function
parameters as read only unless documented otherwise. And in fact, rarely do
functions need to change their parameters. It works, I simply have never had
a problem with it.


 I suspect part of the problem is the obscure declarators of C that is even
 worse in C++. Is that correct? It that is so, D has the oppertunity to
 rectify the situation, and I believe D had already largely done that. 15
 years ago, I moved from Turbo Pascal to C and C++. One of the major
 obstacles I experienced was the declarators. They still puzzles me, and


yet,

 they do not provide anything that I could not do in Pascal.


The problem roots from const having an influence over the overloading and
partial template specialization matching algorithms. Sometimes const makes
one match 'better' than another, sometimes it doesn't, depending on an
arcane list of rules. (This is one big reason why, in D, overload resolution
explicitly ignores things like in, out, inout, and only looks at the types.)
Mar 09 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:


 Oddly, I took the opposite approach. I dropped all use of 'const' that
 wasn't for declaration of constants. Instead, I treat all function
 parameters as read only unless documented otherwise. And in fact, rarely do
 functions need to change their parameters. It works, I simply have never had
 a problem with it.


And that shows in D, too : http://www.digitalmars.com/d/interface.html


 There are no const or volatile type modifiers in D.
 To declare a C function that uses those type modifiers,
 just drop those keywords from the declaration.


Copy-on-Write also implies that the arguments are readonly by default ?


But I can't think of any uses of "readonly" KW except for with char[],
so maybe it can be turned into some kind of array property instead ?

The last thing we want is an extra keyword to all regular parameters...
So maybe it would be better to have it in the array/slice information:

{ size_t length; void* data; byte flags; } // or something, pseudo

With one flag for "readonly", and one flag for "zero terminated" ?
(for optimizing toStringz, and similar functions that need to know)


Or something similarly different ?

--anders
Mar 09 2005
prev sibling parent Ben Hinkle <Ben_member pathlink.com> writes:
In article <d0o2qq$iif$1 digitaldaemon.com>, Walter says...

"Martin M. Pedersen" <martin moeller-pedersen.dk> wrote in message
news:d0nj0k$bi$1 digitaldaemon.com...

 I'm have made a habit of using 'const' all the time. I do that by


intuition,

 and are not very conscious about it anymore. I simply do not write code


that

 is not const-correct, and I haven't experienced such problems. But perhaps
 I'm not experienced enough to get myself into those situations you


mention,

 and stick to simpler code.


Oddly, I took the opposite approach. I dropped all use of 'const' that
wasn't for declaration of constants. Instead, I treat all function
parameters as read only unless documented otherwise. And in fact, rarely do
functions need to change their parameters. It works, I simply have never had
a problem with it.


Interesting. That's basically the Fortran approach. In Fortran, for those who
don't know, things are passed by reference and it is implicit you don't mess
with the inputs.

When I code C++ I use const every now and just to get that little satisfaction
of actually using it :-) But I don't do enough C++ to really depend on const or
have it catch anything for me.
Mar 09 2005
prev sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
 simplified const handling (storage instead of type),


As has been debated here many times <g>, const as a type modifier in C++ is
so semantically weak it is fairly useless. (Many disagree.) C and C++ are
the only languages I've ever heard of that use const as a type modifier.

convinced the larger programmer community that const as a type modifier has
a place.


Most languages don't have destructors. So the C++ community has not convinced
the larger programmer community that destructores have a place. But are
destructors bad just because of that?
I know you don't think so, otherwise D wouldn't have auto classes.


 etc, and I guess I'd have more examples if I had been using C++ more...
 And this makes C++ more "complete" in that you can do more things,
 but is also makes a lot harder and complex - at least at the start ?


I'd argue that C++ is less complete, since it relies so heavilly on STL to
do things that are built in to most languages.


I know a lot of languages that have built in linked lists (Lisp, SML, O'Caml,
Haskell, Clean, ... to name just a few popular languages). D does not. Why?


Doing a general purpose
foreach with C++ is fiendishly difficult. It's for free in D.


OK, C++ is still not perfect. But imagine C++ with Lisp-like macros. You could
do a foreach easily, without having it built in. Or imagine C++ with a
Sather-like iteration model. You wouldn't need a foreach loop any more.

A foreach loop isn't realy a killer-feature that no other language knows about.
Mar 10 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthias Becker" <Matthias_member pathlink.com> wrote in message
news:d0psuo$2gc6$1 digitaldaemon.com...

 simplified const handling (storage instead of type),


As has been debated here many times <g>, const as a type modifier in C++




is

so semantically weak it is fairly useless. (Many disagree.) C and C++ are
the only languages I've ever heard of that use const as a type modifier.

convinced the larger programmer community that const as a type modifier




has

a place.


 Most languages don't have destructors. So the C++ community has not


convinced

 the larger programmer community that destructores have a place. But are
 destructors bad just because of that?
 I know you don't think so, otherwise D wouldn't have auto classes.


Of course. It should be of strong interest to any language designer what

features did they pick, what did they leave out, and most importantly, why?
I believe many of the choices they made are excellent, and many are
mistakes. It's important that I be able to justify the decisions for D, and
if it diverges from what other C++ based language designers chose, I think
the bar is at least a little higher for justifying it.


 etc, and I guess I'd have more examples if I had been using C++ more...
 And this makes C++ more "complete" in that you can do more things,
 but is also makes a lot harder and complex - at least at the start ?


I'd argue that C++ is less complete, since it relies so heavilly on STL




to

do things that are built in to most languages.


 I know a lot of languages that have built in linked lists (Lisp, SML,


O'Caml,

 Haskell, Clean, ... to name just a few popular languages). D does not.


Why?

Because the UDT facilities in D are good enough that it's trivial to do a
linked list.


Doing a general purpose
foreach with C++ is fiendishly difficult. It's for free in D.


 OK, C++ is still not perfect. But imagine C++ with Lisp-like macros. You


could

 do a foreach easily, without having it built in. Or imagine C++ with a
 Sather-like iteration model. You wouldn't need a foreach loop any more.
 A foreach loop isn't realy a killer-feature that no other language knows


about.

I agree that foreach is hardly unique to D. It's not a killer feature,
either. It's not, by itself, a reason for people to switch from C++ to D.
Mar 10 2005
parent Matthias Becker <Matthias_member pathlink.com> writes:
 simplified const handling (storage instead of type),


As has been debated here many times <g>, const as a type modifier in C++




is

so semantically weak it is fairly useless. (Many disagree.) C and C++ are
the only languages I've ever heard of that use const as a type modifier.

convinced the larger programmer community that const as a type modifier




has

a place.


 Most languages don't have destructors. So the C++ community has not


convinced

 the larger programmer community that destructores have a place. But are
 destructors bad just because of that?
 I know you don't think so, otherwise D wouldn't have auto classes.


Of course. It should be of strong interest to any language designer what

features did they pick, what did they leave out, and most importantly, why?
I believe many of the choices they made are excellent, and many are
mistakes. It's important that I be able to justify the decisions for D, and
if it diverges from what other C++ based language designers chose, I think
the bar is at least a little higher for justifying it.


I see.


 etc, and I guess I'd have more examples if I had been using C++ more...
 And this makes C++ more "complete" in that you can do more things,
 but is also makes a lot harder and complex - at least at the start ?


I'd argue that C++ is less complete, since it relies so heavilly on STL




to

do things that are built in to most languages.


 I know a lot of languages that have built in linked lists (Lisp, SML,


O'Caml,

 Haskell, Clean, ... to name just a few popular languages). D does not.


Why?

Because the UDT facilities in D are good enough that it's trivial to do a
linked list.


In SML a user defined type that represents a linkd list would look like this:


The type MyList parameterised with 't is eigther an EmptyList or a ListNode,
which consists of an object of type 't and another list of type MyList
parameterisd with 't.
I think you can't beat this shortness and expressiveness in D, but SML still has
a built in list type.

But you are right. D isn't 'functional' enough for a built in list-type.


Anyway, C++ dosn't have built-in quques, stacks, 'dictoranrys', ... but using
them is almost as simple as the built-in counter-parts of other languages that
have such structures built in.







Could it be easier?
Mar 11 2005
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Björklund wrote:

 One aspect of D that is nice (or at least flexible ?)
 is that you can write programs in ancient C style...
 
 Without using objects, and without using exceptions,
 garbage collection and other such modern facilities :-)
 
 
 All you need to do is provide hooks for a few required
 aspects of Phobos, such as GC and assert / OutOfMemory.


I think it is absolutely necessary to have this feature
as standard issue!

We don't certainly _want_ folks to en masse start doing
non-gc programming or ancient C style. But there are
some things even I (as an example of a long time D guy)
would feel uncomfortable doing with gc and stuff. (May
the fears be warranted or not.)

And, to the one guy at the office who fervently opposes
D, one could always say you don't _have_ to use GC.

This sould be documented, too. (Heh, _after_ the hairy
sections in the paper manual, so women and children do
not find it.)
Mar 05 2005
parent "Walter" <newshound digitalmars.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:4229ED47.1050405 nospam.org...

 And, to the one guy at the office who fervently opposes
 D, one could always say you don't _have_ to use GC.


That's right. You can do all the allocation with C's malloc/free. In fact,
the D version of Empire is pretty much a line by line transliteration from
C. The two are nearly identical.
Mar 06 2005