Ben Phillips wrote:

> In article <dubfs7$95p$1@digitaldaemon.com>, Andrew Fedoniouk says...
>>
>>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);
>>   }
>>}
>>
> 
> Since D uses references for all classes, providing opAssign is just way to dangerous to be worth the effort.

My suggestion is not to provide opAssign for classes. It is providing opAssign for structs.

/Oskar

Derek Parnell wrote:
> On Sun, 05 Mar 2006 00:25:16 +1100, Ben Phillips <Ben_member@pathlink.com> wrote:
> 
>> In article <dubfs7$95p$1@digitaldaemon.com>, Andrew Fedoniouk says...
>>>
>>> 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);
>>>   }
>>> }
>>>
>>
>> Since D uses references for all classes, providing opAssign is just way to
>> dangerous to be worth the effort. Lets say you have a class like follows:
>>
>> class Array
>> {
>> private int[] array;
>> public this()
>> {
>> array = new int[10];
>> }
>> void opAssign(Array a)
>> {
>> for (int i = 0; i < a.length; i++)
>> array[i] = a[i];
>> }
>> }
>>
>> and lets say I write something like this:
>> Array a = new Array();
>> Array b = new Array();
>> a = b;
>>
>> I expect a to refer to the same object as b, but no. The author of the Array
>> class copies the data in the overloaded operator, so my code doesn't work for
>> seemingly unknown reasons. This is a problem which would require more than just
>> a "don't do it" warning.
>>
>> Imho, we just need a standardized "clone" method (like .dup) that can be used
>> for assigning.
> 
> YES! And a syntax to support opDup().  The "=" means assign, so why not have another operator to mean copy-the-data-not-just-the-reference? ":=" has been suggested but there could be other great ideas.
> 
> 
> --Derek Parnell
> Melbourne, Australia

Hum, yes!, ideally we could two pairs of operators, each for setting/testing the reference/instance_data

=	Assign the reference to an object (currently: = )
==	Test for identity, aka same reference (currently: is )
:=	Copy the object. (nothing similar)
:==	Test for equality, aka same instance data ( currently: == )

This is just the structural idea, the name/symbols of these operators could be something other and better (and I think this choice would be a very important aspect of this feature).


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Derek Parnell wrote:
>> 2. as far as I know no way of inporting somthing in a parent directory (as C++ #include "../myheader.hpp")
> 
> You can, only its not coded in the source file. Instead you do this via the compiler's "-I" switch.
> 

Yes it can bee worked around but it's frustrating to have to add a lot of -I by hand to the compiler. It realy complicates keeping a simple makefile.

An example.

foo/bar/ff.d
foo/gg.d
rr.d

gg.d imports ff.d with the command import bar.ff;
rr.d imports gg.d using import foo.d; but now you cant just compile rr.d because the compiler does not find ff.d.

I realise that my orgina formulation was not so clear. actualy it is not specificaly import from parent dir I want but import relative to the source files dir instead of the dir where the compiler is invoked.

consider the diference of thees c++ includes

#include "foo.h" // includes relative to the sourcefiles dir and if that fails in the current path

#include <foo.h> //includes from path

and D's import

import foo; // imports from the search path with the compiler flag -I. added

wath I want is somthing like the first c++ statement ie an include relative to the sourcefiles location.

Lars Ivar Igesund wrote:

>> 3. read only sematics that work as a strong reminder that one is not
>> suposed to modify somthing (but can bee subverted by a cast)
> 
> Walter has answered on this very many times earlier, and he thinks const
> ain't the correct solution. Whether he'll find some other is still an open
> question.

I know that and try to influence him. :)

>> 4. overlodable assignment and copy constructors.
> 
> Also discussed very many times in the past, Walter's opinion is that they're
> bad for you ;)

:)

>> 5. library and other minor issues
> 
> Library is IMHO a community issue, nothing to do with the language, which
> was the question here.

yers that's why it is a minor issue.

>>>> 4. library
>>>> ...
>>> I don't find the STL compelling, either, and that's the only library
>>> thing standard C++ has over libc. Furthermore, large chunks of STL are
>>> simply irrelevant in D because D has core arrays, strings, and
>>> associative arrays.
>> I agree on this one. So wath is your plan for the D standard library?
> 
> I do agree that phobos is not the most compelling std library out there,
> which is why I encourage helping out with Ares.

actualy I was asking for Walters plans I think it would bee nice to the comunity if he let us know wath to expect from his side.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:duab09$1arn$1@digitaldaemon.com...
>I started a new thread for this:
>
> "Mike Capp" <mike.capp@gmail.com> wrote in message news:dua67i$12cr$1@digitaldaemon.com...
>> 7. D has all (well, most of) the power of C++
>
> I see this often and am a bit perplexed by it. What power do you feel is missing?
>
> And what about the missing power in C++ - inline assembler, nested functions, contract programming, unit testing, automatic documentation generation, static if, delegates, dynamic closures, inner classes, modules, garbage collection, scope guard?
>
> What does D have to do to have more power than C++?

- stack allocation for auto classes
- ITI for function templates
- implicit ctors for fundamental types, e.g.: int* i = new int(10);
- ctors for structs to get rid of having to use static opCall().
- Fix this issue:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/6036

The last 2 are for cases like:

template mypow(F) {
    F mypow(F x, int i) {
        if(i < 1) return F(1); // here
        if(i & 1) if(i == 1) return x; else return x * mypow(x,i-1);
        return sqr!(F)(mypow(x,i/2));
    }
}

- Dave

Kevin Bealer escribió:
> ...
> 2. constructors / destructors for struct.

There was some sort of agreement a while ago where Walter asked if the community wanted struct constructors so badly to have them without having destructors. The general position was yes. It hasn't come to life, but that was the agreement then. I don't remember Walter's rationale behind not having struct destructors.

> ...
> Kevin
> 
> 


-- 
Carlos Santander Bernal

In article <duaj45$1pni$1@digitaldaemon.com>, Mike Capp says...
>
>In article <duab09$1arn$1@digitaldaemon.com>, Walter Bright says...
>>
>>I started a new thread for this:
>>
>>"Mike Capp" <mike.capp@gmail.com> wrote in message news:dua67i$12cr$1@digitaldaemon.com...
>>> 7. D has all (well, most of) the power of C++
>>
>>I see this often and am a bit perplexed by it. What power do you feel is missing?
>
>Clean, composable, deterministic resource management. I know C++ is a horrific Frankenstein's monster of a language, but it allows you to encapsulate resource management better than anything I've ever seen. I find this frustrating, because it's not as if D is far off. It might be that auto class members are all that's needed. But I've ranted this rant many times before on this NG, and nobody else seems particularly interested, so I won't repeat it here.
>

I'm not sure what you mean by 'auto class members', but if you meant 'classes instantiated on the stack for which the dtor is automatically called when they go out of scope', then I agree.

>far as it goes. (The current GC is severely suboptimal, and making it better will break other stuff. And I still get very annoyed by the claim that GC is 'optional' in D.)

I agree that the current GC has performance issues (compared to the mature GC's of most Java implementations and .NET), but I don't agree that it can't be improved w/o breaking things. For example, you can have non-moving generational GC's. Just making the change to some form of partial collection scheme would make D's GC competitive for most things, I think. And stack-allocated classes and struct ctors for D would take care of the rest.

>But that's not really the point. If you're trying to convince someone with a substantial investment in C++ to switch to D, one of the most important questions you want them to be asking is "What do I have to lose?". The conclusion you want them to come to is "Nothing". If instead the immediate and vehement answer is "Well, THIS!", you've suddenly lost a lot of momentum. That's all I was getting at.

They will always have years of (painful) C++ experience to lose ;) So IMHO D needs to be exceptional in all areas, most importantly great all-around performance (and this includes the v1.0 reference compiler). As others have stated (paraphrasing), "the primary reason C++ is still used for so many projects is because of it's exceptional OOP performance."

I think D is about 95% to the tipping point though.

- Dave

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:dubfs7$95p$1@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.

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:dubi73$fgh$1@digitaldaemon.com...
> Any real advices?

You can use an auto class, and use a function named "assign()" to do assignments.

>>
>> D will GPF on something like this I guess.
>
> In my book, this is a Feature of D.

Are you saying in your book that:
"D will GPF" is a Feature of D?

It is not for book then - it is something to be graffited on the wall I guess.