D - more or less power than C++?

[Walter Bright]

"Andrew Fedoniouk" <news at terrainformatica.com> wrote in message 
news:dubfs7$95p$1 at digitaldaemon.com...
> I am not exactly sure what this means: assign-at-compile-time, 
> assign-once.
> Could you provide some examples?

const int a = 3;        // compile time
const int b;            // assign only in constructor

> I mean something like
>
> struct cow_string {
>   ref_counted_buffer data;
>   void opAssign(cow_string s)
>   {
>       release(data);
>       data = s.data;
>       addref(data);
>   }
> }
>
> GC as a memory managment is only one from others
> possible management technics. refcounting has it own
> pluses (as minuses).
>
> To be able to combine both is just good thing -
> key to effective technically correct solutions.

You can do refcounting in D - just not by overloading =. To assign, you'd 
call a function rather than using =. Sure, that isn't as slick as 
overloading =, but with gc being available, I doubt there's much use for ref 
counting. Syntactic sugar is a good idea for things that are used a lot, 
it's not as good an idea for things that are rarely used.


>> You can do so by only allowing private functions access to the underlying 
>> data. There is no notion of "const-correctness" or const as a type 
>> modifier in any of those languages.
>
> True. This is why they are so uneffective.
> String s = somestring.substring(1,4);
> will allocate new String object.
>
> You can implement the same approach in D of course
> but you will give up ranges ( s[2..$] ) in almost all cases.

How so? Why does overloading opSlice not work?


> To return substring from immutable string you will
> always allocate new object.

I don't see why:

struct String
{
    private char[] data;

    ...overload operators here...
}

>>> Postulate: D must include all features C++ has now.
>> Are you suggesting D must have a preprocessor, too?
> Don't understand this. Strictly speaking preprocessor
> is not a part of C++.

I could argue the point, but instead I'll toss out trigraphs. Should D 
support trigraphs?


>>> D inner classes for example - strange halfly implemented Java feature.
>>
>> How so?
>
> This is again about problems
>
> And last time I've checked: I couldn't reference explicitly members
> of outer class like in java:
>
> Outer.this.member = ...;
>
> and there is no restriction on final's in outer function (Java is not 
> allocating
> function frames, D does the same but not safe)

I must have overlooked this, can you point me to a test case?


>>> Scope guards are generally good
>>> but without clear and strict definition of execution model - almost 
>>> useless - syntactic noise.
>>
>> I strongly disagree there. I thought I had answered your questions about 
>> that in the scope guard thread.
>
> Key-point is "without clear and strict definition of execution model".
>
> 1) Again, what will happen if on_scope_success will throw?

I believe I answered that. Throwing in on_scope is like throwing in a 
destructor or in a finally block. It's a very bad idea, and will probably 
produce a double fault exception. The same issue exists with C++.


> 2) As I said before, implementation of on_scope_success
> seems like artificial  to D. In syntax and in implementation.

If by that you mean it is unique to D, then yes, it is. But it is based on 
work done by experts in the field who have attempted to bash C++ into doing 
it, and those experts have reviewed on_scope. They've helped me understand 
what the issues are, and what the solution should look like, and I've 
implemented that solution. So I have a lot of confidence that it is the 
right solution.

I know that it's unfamiliar, and it took me a while to get it.