D - more or less power than C++?

[Andrew Fedoniouk]

"Walter Bright" <newshound at digitalmars.com> wrote in message 
news:dub64a$2n07$1 at digitaldaemon.com...
>
> "Andrew Fedoniouk" <news at terrainformatica.com> wrote in message 
> news:dub0rk$2eje$1 at digitaldaemon.com...
>> There is no way currently in D to implement "guarded variable":
>>
>> something s = ....;
>>
>> I cannot write code which will allow to catch
>> assignment to the variable (concrete memory region if you wish).
>> Just nothing for that in D at all - variables are naked.
>
> There are assign-at-compile-time and assign-once variables. What major 
> niche does a guarded variable serve?

I am not exactly sure what this means: assign-at-compile-time, assign-once.
Could you provide some examples?

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.

C++ gives ref counting and stack allocations (with ctors/dtors),
D gives only GC and stack allocations are not currently implemented there.

Ideal system should have all three. In this case requirement
to effectiveness of GC could be lowered.

>
>>> I don't really understand this, as many languages have serious libraries 
>>> without const - such as Java, Python, C#, etc.
>> 1) All these have builtin immutability. For example strings there
>> are immutable objects. D has no strings so it must have
>> some features in the language allowing to implement such
>> objects as a library.
>
> 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.
To return substring from immutable string you will
always allocate new object. So what is a big reason in D then?
Go for C# - it has faster GC so this joy-of-GC will not be so critical.

>
>
>> If you can do something in C/C++ you must
>> be able to do it in D. This is it.
>>
>> 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++.  This way D has also preprocessor - build.exe

>
>
>>> Try doing nested functions elegantly in C++ <g>.
>> Agree, they are useful. But if used with care.
>> As soon as you can get address of such inner function
>> then you are in trouble - result of later call of such function
>> is non-deterministic.
>
> True, one can get into trouble doing that wrong, but it isn't conceptually 
> any different from the following C++ code:
>
>    int *p;
>    void foo()
>    {    int i;
>        p = &i;
>    }
>
>    void test()
>    {
>        ... = *p;
>    }
>
> So I would not argue that it is a defect *in comparison to C++*.

I am not speaking about defects or something like this here.
I just want to mention that D is a low level language and cannot
be compared with Java or the like.
D - fast but flammable.
Java - fireproof but slow.

Completely different roles and use cases.

>
>
>> 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)


>
>> 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?

If it is not safe in principle and there is complex handling required then
you will end up with following:

on_scope_success try { ... } catch(object er) {...}

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

IMO, it makes real sense to provide facilities to
do things like on_scope_*** by others.

D as a language shall just provide generic mechanisms to do this:
There are mixins already. So why not to extend them?

mixin can mix code in at point of definition. Add another
optional "parameter" to denote where to mix it and
allow anonymous mixins.

mixin atexit { .... }
mixin atfailure { .... }

But I would think more in this direction.


>
>> "auto zoo" there too.  Over-qualified 'static' All that private/protected 
>> stuff
>> is just not finished yet - I was fighting with it in Harmonia - never 
>> win.
>
> The private/protected stuff works like it does in C++.

Negative. D has concept of packages and there are problems there.

As far as I recall classes sitting in inner folders of some package have
very strange rules of accessibility to package objects. Classes and their 
members
in particular.

>
>> OT: I was proposing readonly ranges and pointers as a simple alternative 
>> / palliative
>> of problem #1. At least they allow to have lightweight and fast strings 
>> as in Java/C#/Python.
>
> Java/C#/Python do not have lightweight and fast strings. There are some 
> layers of complexity there that are hidden, but are there.

Sorry  not "fast as" but "faster than".

Andrew.