April 10, 2012
Sorry, but a small issue.

the line: auto card = cards.popBack();

throws the errors:

error: variable xxx.card voids have no value
error: expression popBack(this.cards) is void and has no value

I tried reserving the space, I even tried cards = new Card[no_cards];
April 10, 2012
On Tue, 10 Apr 2012 13:58:44 +0200, CrudOMatic <crudomatic@gmail.com> wrote:

> Sorry, but a small issue.
>
> the line: auto card = cards.popBack();
>
> throws the errors:
>
> error: variable xxx.card voids have no value
> error: expression popBack(this.cards) is void and has no value
>
> I tried reserving the space, I even tried cards = new Card[no_cards];

Sorry, popBack returns void. You have to get the back of the array before calling popBack(). Here's an example:

import std.array;
class Card {}
void main() {
    Card[] cards;
    cards.reserve(1024);
    assert(cards.capacity >= 1024);
    assert(cards.length == 0); // still 0

    cards ~= new Card(); // add a Card
    assert(cards.length == 1);

    auto card = cards.back; // get last element
    cards.popBack(); // remove last element
    assert(card); // non-null
    assert(cards.length == 0); // "empty" again
    assumeSafeAppend(cards); // allow us to append to it without reallocating

    auto oldptr = cards.ptr;
    cards ~= new Card();
    assert(cards.length == 1);
    assert(card); // card still alive and kicking
    assert(cards.ptr == oldptr); // and no reallocation
}
April 10, 2012
Thanks, works fine now.
April 10, 2012
> class Deck {
>   Card popBack() {
>     auto card = cards.popBack(); // get last card. cards.length

Note that popBack() is void:
http://dlang.org/phobos/std_array.html#popBack

use

auto card = cards.back();
cards.popBack();
April 10, 2012
Am Tue, 10 Apr 2012 07:35:31 -0400
schrieb "Steven Schveighoffer" <schveiguy@yahoo.com>:

> Destructors are strictly for cleaning up resources that *AREN'T* allocated by the GC.  For example anything created with C's malloc, or an open file descriptor, etc.

This I think is a very good advice to beginners. Short and precise. It is much more fun to use a new language when you can also free your mind from some archaic concepts now and then :)

-- 
Marco

April 11, 2012
On Tuesday, 10 April 2012 at 18:28:39 UTC, Marco Leise wrote:
> Am Tue, 10 Apr 2012 07:35:31 -0400
> schrieb "Steven Schveighoffer" <schveiguy@yahoo.com>:
>
>> Destructors are strictly for cleaning up resources that *AREN'T* allocated  by the GC.  For example anything created with C's malloc, or an open file  descriptor, etc.
>
> This I think is a very good advice to beginners. Short and precise. It is much more fun to use a new language when you can also free your mind from some archaic concepts now and then :)

That's good to know. Just looking over more of the docs.

April 11, 2012
Am Tue, 10 Apr 2012 20:28:28 +0200
schrieb Marco Leise <Marco.Leise@gmx.de>:

> Am Tue, 10 Apr 2012 07:35:31 -0400
> schrieb "Steven Schveighoffer" <schveiguy@yahoo.com>:
> 
> > Destructors are strictly for cleaning up resources that *AREN'T* allocated by the GC.  For example anything created with C's malloc, or an open file descriptor, etc.
> 
> This I think is a very good advice to beginners. Short and precise. It is much more fun to use a new language when you can also free your mind from some archaic concepts now and then :)
> 

That's a dangerous advice though: You can create lots of file descriptors without allocating much memory. So in the worst case you run out of file-descriptors long before the GC calls your destructor.
April 11, 2012
On Wed, Apr 11, 2012 at 07:07:54PM +0200, Johannes Pfau wrote:
> Am Tue, 10 Apr 2012 20:28:28 +0200
> schrieb Marco Leise <Marco.Leise@gmx.de>:
> 
> > Am Tue, 10 Apr 2012 07:35:31 -0400
> > schrieb "Steven Schveighoffer" <schveiguy@yahoo.com>:
> > 
> > > Destructors are strictly for cleaning up resources that *AREN'T* allocated by the GC.  For example anything created with C's malloc, or an open file descriptor, etc.
> > 
> > This I think is a very good advice to beginners. Short and precise. It is much more fun to use a new language when you can also free your mind from some archaic concepts now and then :)
> > 
> 
> That's a dangerous advice though: You can create lots of file descriptors without allocating much memory. So in the worst case you run out of file-descriptors long before the GC calls your destructor.

Yeah, one should not rely on the GC to destroy objects at a given time, since it can be arbitrarily distant in the future. For releasing resources, what really should be used are scope statements:

	auto myResource = acquireResource;
	scope(exit) myResource.release();


T

-- 
Windows 95 was a joke, and Windows 98 was the punchline.
April 11, 2012
On Wed, 11 Apr 2012 13:07:54 -0400, Johannes Pfau <nospam@example.com> wrote:

> Am Tue, 10 Apr 2012 20:28:28 +0200
> schrieb Marco Leise <Marco.Leise@gmx.de>:
>
>> Am Tue, 10 Apr 2012 07:35:31 -0400
>> schrieb "Steven Schveighoffer" <schveiguy@yahoo.com>:
>>
>> > Destructors are strictly for cleaning up resources that *AREN'T*
>> > allocated by the GC.  For example anything created with C's malloc,
>> > or an open file descriptor, etc.
>>
>> This I think is a very good advice to beginners. Short and precise.
>> It is much more fun to use a new language when you can also free your
>> mind from some archaic concepts now and then :)
>>
>
> That's a dangerous advice though: You can create lots of file
> descriptors without allocating much memory. So in the worst case you
> run out of file-descriptors long before the GC calls your destructor.

This is not "dangerous" advice.  Freeing resources you own that are not yet freed is perfectly acceptable, and IMO, good practice.  If you own a resource, and it's not closed manually, you have an obligation to free it.  If you create a class that owns a file descriptor, and don't close it in the destructor, then it leaves the possibility that you have destroyed all references to the file descriptor, but left it open, thereby leaking it.

Yes, it is advisable that when you are creating unlimited numbers of file-descriptor owning classes, that you manually close them.  But the destructor is a perfectly good place to do that.

I once wrote an application that relied on the GC to close file descriptors, and it never ran out of file descriptors.

-Steve
1 2
Next ›   Last »