April 09, 2012
On 2012-04-09 02:21, Andrej Mitrovic wrote:
> On 4/9/12, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
>> and pass-by-alias
>
> Speaking of alias, one killer feature would be to enable using alias
> for expressions. E.g.:
>
> struct Window { struct Point { int x, y; } Point point; }
> void test() {
>      Window window;
>      alias window.point.x x;
>      // use 'x' here which is really window.point.x
> }
>
> It makes it simpler to manipulate nested structs and their fields by
> reference without involving pointers or using with statements. AFAIK
> C++ can use references for this purpose (ala&int x =
> window.point.x;), but I guess this isn't very efficient unless the
> compiler can optimize it.
>
> Besides myself I've also seen other people request it (I think Nick S.
> wanted the feature).

I want this feature as well. I also want it to be possible to document.

-- 
/Jacob Carlborg
April 09, 2012
On 2012-04-09 02:24, Alex Rønne Petersen wrote:

> Google likes to invent random useless languages. See: Dart. Both
> languages are solutions looking for problems. ;)

Actually I like the idea behind Dart, to replace JavaScript. But that's basically the only think I like about it.

-- 
/Jacob Carlborg
April 09, 2012
On 04/09/12 02:21, Andrej Mitrovic wrote:
> On 4/9/12, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> and pass-by-alias
> 
> Speaking of alias, one killer feature would be to enable using alias for expressions. E.g.:
> 
> struct Window { struct Point { int x, y; } Point point; }
> void test() {
>     Window window;
>     alias window.point.x x;
>     // use 'x' here which is really window.point.x
> }
> 
> It makes it simpler to manipulate nested structs and their fields by reference without involving pointers or using with statements. AFAIK C++ can use references for this purpose (ala &int x = window.point.x;), but I guess this isn't very efficient unless the compiler can optimize it.

struct Window { struct Point { int x, y; } Point point; }
void test() {
    Window window;
    @property ref x() { return window.point.x; }
    // use 'x' here which is really window.point.x
}

And, yes, the compiler can and does optimize it away.

artur
April 09, 2012
On Sat, 07 Apr 2012 12:45:44 -0400, Rainer Schuetze <r.sagitario@gmx.de> wrote:

>
>
> On 4/6/2012 6:20 PM, deadalnix wrote:
>> Le 06/04/2012 18:07, Andrei Alexandrescu a écrit :
>>> A few more samples of people's perception of the two languages:
>>>
>>> http://news.ycombinator.com/item?id=3805302
>>>
>>>
>>> Andrei
>>
>> I did some measurement on that point for D lately :
>> http://www.deadalnix.me/2012/03/05/impact-of-64bits-vs-32bits-when-using-non-precise-gc/
>>
>
> I studied the GC a bit more and noticed a possible issue:
>
> - memory allocations are aligned up to a power of 2 <= page size
> - the memory area beyond the actually requested size is left untouched when allocating

No, it's zeroed if the block is requested without the NO_SCAN bit set.

see: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gcx.d#L479

Note to Sean, it's not in the no-sync part (makes sense, why hold the lock while you are memsetting).

-Steve
April 09, 2012
Le 09/04/2012 02:24, Alex Rønne Petersen a écrit :
> On 09-04-2012 02:18, Manu wrote:
>> On 9 April 2012 02:24, Walter Bright <newshound2@digitalmars.com
>> <mailto:newshound2@digitalmars.com>> wrote:
>>
>> On 4/8/2012 3:57 PM, Manu wrote:
>>
>> What do you base that statistic on? I'm not arguing that fact,
>> just that I
>> haven't seen any evidence one way or the other. What causes Go
>> to create
>> significantly more garbage than D? Are there benchmarks or test
>> cases I should
>> be aware of on the topic?
>>
>>
>> The first ycombinator reference is a person who didn't run out of
>> memory using D. That implies far less pressure on the gc.
>>
>> My understanding of Go is that when it does structural conformance,
>> it builds some of the necessary data at runtime on the gc heap.
>>
>> Anyhow, D has a lot of facilities for putting things on the stack
>> rather than the heap, immutable data doesn't need to get copied, and
>> slices allow lots of reuse of existing objects.
>>
>>
>> "optimized D was slightly faster than Go at almost anything and consumed
>> up to 70% less memory"
>> Interesting... I don't know enough about Go to reason that finding, I
>> guess I assumed it has most of the same possibilities available to D.
>> (no immutable data? no stack structs? no references/pointers/slices?
>> crazy...)
>>
>> The only D program I have significant experience with is VisualD, and it
>> hogs 1-2gb of ram for me under general usage, and eventually crashes,
>> after paging heavily and bringing my computer to a crawl. Not a good
>> sign from the first and only productive D app I've run yet ;)
>> This seems a lot like his experience with Go... but comparisons aside, D
>> still clearly isn't there yet when it comes to the GC either, and I'm
>> amazed Google thing Go is production ready if that guys findings are
>> true!
>
> Google likes to invent random useless languages. See: Dart. Both
> languages are solutions looking for problems. ;)
>
> And yes, precise GC is more essential than most people think.
>

I posted some an article about that. 64bits pretty much solve the false positive problem.

Still, precise GC is nice, but alternative like precise on heap and imprecise on stack are very valid alternatives.
April 09, 2012
On Monday, 9 April 2012 at 00:18:22 UTC, Manu wrote:
> On 9 April 2012 02:24, Walter Bright <newshound2@digitalmars.com> wrote:
>
> still clearly isn't there yet when it comes to the GC either, and I'm
> amazed Google thing Go is production ready if that guys findings are true!

They use it on 64 bits servers with tons of RAM. But they can't target Android powered mobile devices with that language, and D may have similar issues.
On what kind of server does the web forum run ?
1 2 3 4 5 6
Next ›   Last »