Why not just be able to mark something as reference counted, then any compiler created references will manipulate the reference count.

Built-in language-supported reference counting is something I could *really* like.  Especially if we had to ask for it and by default got garbage collection.

Sean

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D0759AF.7C8580F3@deming-os.org...
> I really like the idea of doing this at the class level rather than the
usage
> level!  However, there are some questions to address:
> 1) How to enforce that the user doesn't keep extra references to a
deterministic
> object type?  That is, if you pass a reference to a deterministic object
to
> another function, how do you enforce that it doesn't save the reference?
I'm
> not really comfortable with "caveat emptor".  Somebody suggested that
maybe you
> shouldn't be able to pass these types of references to other
functions...but
> then how do you pass an open file handle to another function?
> 2) If you include a reference to this type of object in another class,
does the
> other class have to become deterministic, too, or not?

Can you expand on what you mean by this?  Do you mean the reference counting as a replacement to the garbage collector, or a supplement to it?  As a suplement, it might be exactly what we need.

Russ

"Sean L. Palmer" wrote:

> Why not just be able to mark something as reference counted, then any compiler created references will manipulate the reference count.
>
> Built-in language-supported reference counting is something I could *really* like.  Especially if we had to ask for it and by default got garbage collection.
>
> Sean
>
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D0759AF.7C8580F3@deming-os.org...
> > I really like the idea of doing this at the class level rather than the
> usage
> > level!  However, there are some questions to address:
> > 1) How to enforce that the user doesn't keep extra references to a
> deterministic
> > object type?  That is, if you pass a reference to a deterministic object
> to
> > another function, how do you enforce that it doesn't save the reference?
> I'm
> > not really comfortable with "caveat emptor".  Somebody suggested that
> maybe you
> > shouldn't be able to pass these types of references to other
> functions...but
> > then how do you pass an open file handle to another function?
> > 2) If you include a reference to this type of object in another class,
> does the
> > other class have to become deterministic, too, or not?

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:ae7i8l$8cd$1@digitaldaemon.com...

> Please, please no Undefined Behaviour in language specs.
> If you delete an object all references to it should magically became null.
> Or invalid. Or get a GPF, or ... format the hard disk in a documented
> manner.

Now, how would it be implemented in a more or less effective way (other than holding a list of pointers for each object)?

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D078261.D25F03FA@deming-os.org...

> Can you expand on what you mean by this?  Do you mean the reference
counting as
> a replacement to the garbage collector, or a supplement to it?  As a
suplement,
> it might be exactly what we need.

Indeed, it was meant to be a supplement. And I like the idea. Both GC and
refcounting
have their advantages and disadvantages, and having 'em both would be really
great!

Strongly AGREE! Please no undefined behaviour. That way leads to ...

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:ae7i8l$8cd$1@digitaldaemon.com...
>
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D064768.A1C560DA@deming-os.org...
> > Juan Carlos Arevalo Baeza wrote:
> >
> > >    The problem is in the semantics and potential hidden bugs in the
> program.
> > > I'm not sure what D specifies will happen if you explicitly "delete"
an
> > > object (you _could_ explicitly delete an object, couldn't you?) and
then
> try
> > > to use it (for example, if "whatever()" leaves copies of the reference
> lying
> > > around). Still, I believe Walter's express desire is that such a
> dangerous
> > > "delete" shouldn't happen behind the programmer's back. Dangerous
> statements
> > > like that one are necessary to enhance the programmer's arsenal, but
> they
> > > are indeed problematic when they happen without the programmer's
> awareness
> > > of it.
> >
> > Walter has said that you can use "delete" against something with
> references
> > remaining...but it's undefined behavior.  As I understand it, calling
> "delete"
> > forces immediate cleanup of the object...including running its
> destructors.
>
> Please, please no Undefined Behaviour in language specs.
> If you delete an object all references to it should magically became null.
> Or invalid. Or get a GPF, or ... format the hard disk in a documented
> manner.
> Anything but the UB.
>
> Sandor
>
>
>

Guys

Please berate be if I'm being dumb (it's a bit early here), but why is the following not a reasonable solution to this whole issue:

All instances of one type of class (let's say as denoted by the "class"
keyword) are created on the heap. These types have a destructor.
All instances of another type of class (let's say as denoted by the "struct"
keyword) are created on the stack. These types also have a destructor.

The heap instances are manipulated through references.
The references are implemented as struct types (whose implementation is
hidden in the implementation). All reference arguments are call-by-value
(which is ok, since they are totally lightweight - usually having a
reference count integral, and the referent pointer), so taking copies
(whether as members, discrete variables or function arguments) manipulated
the reference count consistently.

When a reference goes out of scope its destructor (which is called deterministically at the exit of its defining scope), causes the reference count of its referent to be decremented.

When the class type class (sic.) has its reference count drop to zero, its destructor is called, and then its memory is put into the garbage collector. This way, we get deterministic destruction (yeeaaahhh!) whilst still having a garbage collector for better memory performance.

The problems of unwinding of complex class types is simplified, since all that has to be unwound is the references themselves, in releasing their referent (though of course destruction of the referents would have to be effected at that time if rc == 0).

I've implemented a junior version of this a few times previously, with great success (in C++ of course).

The only issue I can think of (I'm sure you'll hit me with more) is how one passes an instance of the struct type. Since they cannot be allocated dynamically there is no possibility of a leak. Passing them to functions can be done as const and non-const reference (the C++ meaning, rather than a "reference" type") and they are returned by value (using shallow-copy in abscence of explicit copy-ctor)

Give me your best criticism ...

Matthew

"anderson" <anderson@firestar.com.au> wrote in message news:ad7a38$1r7f$1@digitaldaemon.com...
> Oh, I really liked the copy constructor. I suppose I can create one
manually
> using a method called copy, but that's not standarised like the copy and conversion constructors.
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:ad5kl4$24tc$1@digitaldaemon.com...
> > "anderson" <anderson@firestar.com.au> wrote in message news:ad5d48$1kdd$1@digitaldaemon.com...
> >
> > > Does D support automatic copy constuctors that traverse the object
tree
> > > (ptrs and stuff)?  Because if it does, I'd have-it-a-guess that copy
and
> > del
> > > would be quite simular operations (not in function but in general
> design).
> > > But correct me if I'm wrong.
> >
> > D doesn't have copy constructors at all because you never work with objects, but always with references. So "A = B" means "let A point to the same object as B". No copy occures.
> >
>
> I used the copy constuctor for pointers in C++ like,
> class A = new class(B);
>
> And I do no that D defaults all objects to pointers.
>
>

For those turned off by circular reference problems, I've been using RefCounting almost exclusively for the past few years and I love it.  Sure I wish it was builtin instead of a user defined class, but really it works well in day-to-day work.  Cycles rarely happen to me and when it happens, usually I can rearrange things a bit and remove the cycles.  For instance if parent and child have ref pointers to each other, that's a cycle.  But I just make the parent own a ref to the child and the child just have a raw pointer to the parent (no ref) and presto no cycle.

The things I like about refcounts:

They're deterministic
They don't use voodoo magic

But really I'd probably be happy with GC so long as GC wasn't the *only* way things got collected... I'd want the compiler to do data flow analysis and explicitly clean up objects it can prove are no longer referenced when a block exits.  Those kinds of objects can be allocated on the stack too to avoid malloc overhead.  Everything else can get GC'd later or I can explicitly call delete if I need it cleaned up right now.

Sean

"Pavel Minayev" <evilone@omen.ru> wrote in message news:ae8fd6$1blb$1@digitaldaemon.com...
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D078261.D25F03FA@deming-os.org...
>
> > Can you expand on what you mean by this?  Do you mean the reference
> counting as
> > a replacement to the garbage collector, or a supplement to it?  As a
> suplement,
> > it might be exactly what we need.
>
> Indeed, it was meant to be a supplement. And I like the idea. Both GC and
> refcounting
> have their advantages and disadvantages, and having 'em both would be
really
> great!

"Sean L. Palmer" wrote:

> For those turned off by circular reference problems, I've been using RefCounting almost exclusively for the past few years and I love it.  Sure I wish it was builtin instead of a user defined class, but really it works well in day-to-day work.  Cycles rarely happen to me and when it happens, usually I can rearrange things a bit and remove the cycles.  For instance if parent and child have ref pointers to each other, that's a cycle.  But I just make the parent own a ref to the child and the child just have a raw pointer to the parent (no ref) and presto no cycle.

(Seriously,) I can't believe I didn't think of that before...don't refcount the last reference in the cycle...hence no cycle.  Of course, it only lets you root the cycle in one place (otherwise you lose a few elements in the cycle), but still...a very elegant solution :)

(cheering)

I think that (optional) refcounts in D, IMHO, just moved from a good idea to a
Good Idea.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Agreed. Also am a big and bug-free ref-counter.

I reckon the language, if references are built-in, can work out the circular ref-stuff for us.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ae9l0o$2lur$1@digitaldaemon.com...
> For those turned off by circular reference problems, I've been using RefCounting almost exclusively for the past few years and I love it.  Sure
I
> wish it was builtin instead of a user defined class, but really it works well in day-to-day work.  Cycles rarely happen to me and when it happens, usually I can rearrange things a bit and remove the cycles.  For instance
if
> parent and child have ref pointers to each other, that's a cycle.  But I just make the parent own a ref to the child and the child just have a raw pointer to the parent (no ref) and presto no cycle.
>
> The things I like about refcounts:
>
> They're deterministic
> They don't use voodoo magic
>
> But really I'd probably be happy with GC so long as GC wasn't the *only*
way
> things got collected... I'd want the compiler to do data flow analysis and explicitly clean up objects it can prove are no longer referenced when a block exits.  Those kinds of objects can be allocated on the stack too to avoid malloc overhead.  Everything else can get GC'd later or I can explicitly call delete if I need it cleaned up right now.
>
> Sean
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:ae8fd6$1blb$1@digitaldaemon.com...
> > "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D078261.D25F03FA@deming-os.org...
> >
> > > Can you expand on what you mean by this?  Do you mean the reference
> > counting as
> > > a replacement to the garbage collector, or a supplement to it?  As a
> > suplement,
> > > it might be exactly what we need.
> >
> > Indeed, it was meant to be a supplement. And I like the idea. Both GC
and
> > refcounting
> > have their advantages and disadvantages, and having 'em both would be
> really
> > great!
>
>
>

Yes it probably could.  If they can build a garbage collector which is based on reference counting they can do damn near anything.

Sean


"Matthew Wilson" <matthew@thedjournal.com> wrote in message news:aeb9nb$1cda$1@digitaldaemon.com...
> Agreed. Also am a big and bug-free ref-counter.
>
> I reckon the language, if references are built-in, can work out the
circular
> ref-stuff for us.