C++

[Lars Ivar Igesund]

kris wrote:

> Sean Kelly wrote:
>> Walter Bright wrote:
>> 
>>>
>>> Another problem happens when people try to transliterate C++ code into
>>> D. That doesn't work very well - you have to rethink things a bit.
>> 
>> 
>> In my experience, transliterating C++ to D allows for a lot of code to
>> simply be tossed out.  It's issues like this that aren't obvious from
>> simply reading a spec.
>> 
>>> Nevertheless, I still regard D as a better C++. Not in terms of being
>>> a true superset, but in terms of being a better solution to the same
>>> types of problems that C++ is targetted at. Note that C++ isn't a true
>>> superset of C, either, although it is billed as a "better C".
>> 
>> 
>> I've yet to do the same level of work in D that I do in C++, but so far
>> I'd have to agree.  And I'm looking forward to some more ambitious
>> projects once the framework is sorted out sufficiently.
>> 
>> That said, I do think D's lack of any sort of const checking may be an
>> issue for large projects (I haven't done this level of development in
>> Java so I don't have a good non-C++ basis for comparison here).  I know
>> the issue has been beaten to death in the past, but perhaps we could do
>> with a constructive discussion before 1.0 appears on the horizon?  I've
>> become convinced that the "default everything to const" method seems
>> ideal, but this seems like something that should really be done before
>> 1.0 if it's going to happen?
>> 
>> 
>> Sean
> 
> As someone with a substantial body of D code, I'd be happy to retrofit
> the whole darned thing to get const. I'd say "go for it" (as long as it
> supports returning an array as a const, without .dup being involved)

As someone without a substantial body of D code, I'd be happy to retrofit
other's code if necessary. In all other respects (on this particular
matter), I just agree with Kris :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi