www.digitalmars.com         C & C++   DMDScript  

D - curiosity (OOC)

reply "Carlos" <carlos8294 msn.com> writes:
First of all... sorry Juan Carlos if I'm violating your privacy anyhow, but
I'm just too curious.
But... I want to know how close to this:
http://www.jcabs-rumblings.com/JCAB.html, people in this newsgroup are. Do
you guys think that's a lot? Have you done more? (I know Walter has)
I mean, I'm just a 20 years old student who knows Basic (QB, VB), most
C/C++, some Delphi, Java and HTML, and starting to deal with D, and that's
it. I thought that was a lot, but when I read all that, I was stunned.
Well, should I say congratulations? I mean, if I wanted to (I don't want to,
don't ask) put an objective in my life, and that was knowing, doing, etc.,
what Juan Carlos does... God, I would have a long way to go! (add the fact
that Spain is far more advanced in computers than any country in Latin
America, where I live).
Don't flame me for posting this... it's just that I'm too impressed.
Aug 21 2002
next sibling parent Mac Reiter <Mac_member pathlink.com> writes:
In article <ak21ck$2vse$1 digitaldaemon.com>, Carlos says...
First of all... sorry Juan Carlos if I'm violating your privacy anyhow, but
I'm just too curious.
But... I want to know how close to this:
http://www.jcabs-rumblings.com/JCAB.html, people in this newsgroup are. Do
you guys think that's a lot? Have you done more? (I know Walter has)

About the same, though in different directions. Sounds like JCAB's projects were more fun (at least at the start and at the end of each -- I read enough Game Developer Magazine post-mortems to know what kind of hell game developers go through for most of their lives...), or at least more exciting, than mine. I think if you are really interested in learning, you should look for a full time job in a company small enough to pile the work on you and large enough to have interesting things to do. You'll learn stuff so fast you won't even realize what's happening. If you can maintain programming as a hobby as well (I share that with JCAB), you can learn even faster, because things that you discover at work can have bigger impact at home, and vice versa. For what it is worth, I am 31, and currently somewhat out of the actual programming loop at work. They pushed me up into some more architectural and design stuff (because I appear to have a knack for it), so I find myself spending more time at home working out the mental kinks... But I know that I learned more in the first year and a half that I was in my company than in all of my official schooling combined. Academics have some good ideas, but they rarely know how to do anything realistic with them. I think that is why I appreciate the pragmatic nature of D so much. Keep an open mind, always look for challenges, and you'll surprise yourself with how much you can learn. Mac
Aug 22 2002
prev sibling next sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
I'm currently one of the lead programmers at Treyarch, recently shipped Tony
Hawk 2x for the Xbox game console.  I've been around for a long time as
well, and have known JCAB for years (online only unfortunately haven't had
the pleasure of finding him at E3).  JCAB's much more prolific than I am
though.  We started up the OpenAL project together if I remember correctly.

The cool thing about D is that the language itself seems really easy to
learn;  very suitable for a beginner.  Should be far easier to learn than
C++, and now that operator overloading and templates are on the way should
be almost as powerful.  The D community is still small relative to C++ but
growing.  I'm surprised how many people are disillusioned with C++.  When I
first started C++ I was overwhelmed by the complexity but enthralled by the
power.  Now I just want something better.  D seems better to me in nearly
all respects.

Sean


"Carlos" <carlos8294 msn.com> wrote in message
news:ak21ck$2vse$1 digitaldaemon.com...
 First of all... sorry Juan Carlos if I'm violating your privacy anyhow,

 I'm just too curious.
 But... I want to know how close to this:
 http://www.jcabs-rumblings.com/JCAB.html, people in this newsgroup are. Do
 you guys think that's a lot? Have you done more? (I know Walter has)
 I mean, I'm just a 20 years old student who knows Basic (QB, VB), most
 C/C++, some Delphi, Java and HTML, and starting to deal with D, and that's
 it. I thought that was a lot, but when I read all that, I was stunned.
 Well, should I say congratulations? I mean, if I wanted to (I don't want

 don't ask) put an objective in my life, and that was knowing, doing, etc.,
 what Juan Carlos does... God, I would have a long way to go! (add the fact
 that Spain is far more advanced in computers than any country in Latin
 America, where I live).
 Don't flame me for posting this... it's just that I'm too impressed.

Aug 22 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ak35qt$22qt$1 digitaldaemon.com...
 The cool thing about D is that the language itself seems really easy to
 learn;  very suitable for a beginner.  Should be far easier to learn than
 C++, and now that operator overloading and templates are on the way should
 be almost as powerful.  The D community is still small relative to C++ but
 growing.  I'm surprised how many people are disillusioned with C++.  When

 first started C++ I was overwhelmed by the complexity but enthralled by

 power.  Now I just want something better.  D seems better to me in nearly
 all respects.

Anything people can do to promote D will be beneficial to us all, as it will convince smart people that D is popular enough to make it worth investing time and effort in. Some examples: 1) Write a web page about D (many of you have already done this, thanks!). The more independent web pages on D there are, the more prominent D will be in Google searches. 2) When you see language wars going on in a forum between C, C++, Java, C#, etc., point out how D is a superior solution. 3) Mention D expertise on your resume's. 4) Do a followup posting on Slashdot (D was slashdotted in Aug 2001, but the compiler didn't exist then).
Aug 22 2002
next sibling parent Pavel Minayev <evilone omen.ru> writes:
5) Write an article about D for some journal. =)

I might try...
Aug 22 2002
prev sibling next sibling parent Toyotomi <io219 attbi.com> writes:
On Thu, 22 Aug 2002 11:23:58 -0700, "Walter" <walter digitalmars.com>
wrote:

1) Write a web page about D (many of you have already done this, thanks!).
The more independent web pages on D there are, the more prominent D will be
in Google searches.

2) When you see language wars going on in a forum between C, C++, Java, C#,
etc., point out how D is a superior solution.

3) Mention D expertise on your resume's.

4) Do a followup posting on Slashdot (D was slashdotted in Aug 2001, but the
compiler didn't exist then).

5) Start comp.lang.d and have your usenet providers add it as well 6) Get D indexed at the topic branching portals
Aug 22 2002
prev sibling parent reply Jonathan Andrew <jon ece.arizona.edu> writes:
 4) Do a followup posting on Slashdot (D was slashdotted in Aug 2001, but the
 compiler didn't exist then).

I think a lot of the complaints people had concerning the language have also been addressed since then, i.e. operator overloading and templates. I think a lot of people who didn't like it then might give it a second chance after they see all the great new features D has. -Jon
Aug 22 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
I for one had almost given up on D due to the lack of exactly those two
features.  It seemed at the time that Walter was dead set against them.  Now
that operator overloading is in and templates are going in soon, I'm
definitely going to have to take another crack at it.  Good debugger support
would help immensely; that's probably the next big thing on my list.

Note that mostly I'm a game programmer, so without an optimizing compiler I
can't get very far using D.  In fact, to use it for actual production games
I'd need a D compiler for PS2, Xbox, and Gamecube.  That said, even in debug
builds games can run pretty fast these days.  And if the GCC frontend for D
ever goes live I'll have all the backend support I'd need.

Sean

"Jonathan Andrew" <jon ece.arizona.edu> wrote in message
news:3D653F23.7DB066C5 ece.arizona.edu...
 4) Do a followup posting on Slashdot (D was slashdotted in Aug 2001, but


 compiler didn't exist then).

I think a lot of the complaints people had concerning the language have

 been
 addressed since then, i.e. operator overloading and templates. I think a

 people
 who didn't like it then might give it a second chance after they see all

 great new
 features D has.

 -Jon

Aug 23 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ak5oq2$1vqe$1 digitaldaemon.com...
 I for one had almost given up on D due to the lack of exactly those two
 features.  It seemed at the time that Walter was dead set against them.

 that operator overloading is in and templates are going in soon, I'm
 definitely going to have to take another crack at it.  Good debugger

 would help immensely; that's probably the next big thing on my list.

The only significant language thing now is the deterministic object destruction.
Aug 23 2002
next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
On Fri, 23 Aug 2002 10:12:23 -0700 "Walter" <walter digitalmars.com> wrote:

 The only significant language thing now is the deterministic object
 destruction.

Also, templates now have to be actually _implemented_. =) I would also mention safe varargs as one quite important feature. Propety gettors & settors - but these are mostly decorative.
Aug 23 2002
next sibling parent reply Mac Reiter <Mac_member pathlink.com> writes:
In article <CFN374919407791782 news.digitalmars.com>, Pavel Minayev says...
On Fri, 23 Aug 2002 10:12:23 -0700 "Walter" <walter digitalmars.com> wrote:

 The only significant language thing now is the deterministic object
 destruction.

Also, templates now have to be actually _implemented_. =) I would also mention safe varargs as one quite important feature. Propety gettors & settors - but these are mostly decorative.

Just looked at the "Classes" topic in the documentation, where I found the following description. It looks like property gettors/settors to me, but there may be a finer distinction of which I am unaware. I also have not done much D programming, so it may be that the following has been described but not yet implemented... Mac (remainder of posting is quoted from the docs) " All this is quite a bit of typing, and it tends to make code unreadable by filling it with getProperty() and setProperty() calls. In D, get'ers and set'ers take advantage of the idea that an lvalue is a set'er, and an rvalue is a get'er: class Abc { int myprop; void property(int newproperty) { myprop = newproperty; } // set'er int property() { return myprop; } // get'er } which is used as: Abc a; a.property = 3; // equivalent to a.property(3) int x = a.property; // equivalent to int x = a.property() Thus, in D you can treat a property like it was a simple field name. A property can start out actually being a simple field name, but if later if becomes necessary to make getting and setting it function calls, no code needs to be modified other than the class definition."
Aug 23 2002
parent Pavel Minayev <evilone omen.ru> writes:
On Fri, 23 Aug 2002 19:02:44 +0000 (UTC) Mac Reiter <Mac_member pathlink.com> 
wrote:

 programming, so it may be that the following has been described but not yet
 implemented...

Exactly. It is just not yet implemented...
Aug 24 2002
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374919407791782 news.digitalmars.com...
 On Fri, 23 Aug 2002 10:12:23 -0700 "Walter" <walter digitalmars.com>

 The only significant language thing now is the deterministic object
 destruction.


Ah, boring implementation details <g>.
 I would also mention safe varargs as one quite important feature.

While they would be nice, I'd have to disagree as to their importance. Varargs isn't used much outside of printf, whereas some people wrap their whole program design around d.o.d.
 Propety
 gettors &
 settors - but these are mostly decorative.

Yes.
Aug 23 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
I for one don't care about varargs, and could completely do without printf
if need be.  All I need is a ToString() method that works on every type and
string concatenation.

Sean

"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374919407791782 news.digitalmars.com...
 On Fri, 23 Aug 2002 10:12:23 -0700 "Walter" <walter digitalmars.com>

 The only significant language thing now is the deterministic object
 destruction.

Also, templates now have to be actually _implemented_. =) I would also mention safe varargs as one quite important feature. Propety gettors & settors - but these are mostly decorative.

Aug 24 2002
parent Pavel Minayev <evilone omen.ru> writes:
On Sat, 24 Aug 2002 11:44:01 -0700 "Sean L. Palmer" <seanpalmer earthlink.net> 
wrote:

 I for one don't care about varargs, and could completely do without printf
 if need be.  All I need is a ToString() method that works on every type and
 string concatenation.

Heh, feels almost like "back to Algol-60 days". =)
Aug 24 2002
prev sibling next sibling parent reply Patrick Down <pat codemoon.com> writes:
"Walter" <walter digitalmars.com> wrote in news:ak5qb3$21dc$2
 digitaldaemon.com:

 
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:ak5oq2$1vqe$1 digitaldaemon.com...
 I for one had almost given up on D due to the lack of exactly those two
 features.  It seemed at the time that Walter was dead set against them.

 that operator overloading is in and templates are going in soon, I'm
 definitely going to have to take another crack at it.  Good debugger

 would help immensely; that's probably the next big thing on my list.

The only significant language thing now is the deterministic object destruction.

Walter if you did put in a language level reference counting mechanism for deterministic object destruction you would be a mega super hero. Reflection comes in second on the list for me.
Aug 23 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns9273A36B24E83patcodemooncom 63.105.9.61...
 Walter if you did put in a language level reference counting
 mechanism for deterministic object destruction you would be a
 mega super hero.

I did suddenly realize that d.o.d. naturally falls out of reference counting, but reference counting does not fall out of d.o.d., which is why it is so clumsy and error prone to do reference counting in C++.
Aug 23 2002
next sibling parent reply Patrick Down <pat codemoon.com> writes:
"Walter" <walter digitalmars.com> wrote in
news:ak6f6p$2oan$1 digitaldaemon.com: 

 
 "Patrick Down" <pat codemoon.com> wrote in message
 news:Xns9273A36B24E83patcodemooncom 63.105.9.61...
 Walter if you did put in a language level reference counting
 mechanism for deterministic object destruction you would be a
 mega super hero.

I did suddenly realize that d.o.d. naturally falls out of reference counting, but reference counting does not fall out of d.o.d., which is why it is so clumsy and error prone to do reference counting in C++.

Yes but I think you should call it d.o.f. Deterministic Object Finalization. Here's why. What I think would be a good idea is not to call the objects destuctor (~A) when the refCount==0 but to call a different function. Perhaps unref(). If a user want's the full memory cleanup they can call "delete this". The reason is you can use it to implement other memory management schmes on top of the mark and sweep. If I am allocating and deallocating a lot of small objects quickly I might want to do object pooling. class Foo : Counted { static Foo head; static Foo alloc() { Foo temp; if(head) { temp = head; head = temp.next; } else temp = new Foo(); } void unref() { this.next = head; head = this; } private next; } { Foo a = Foo.alloc() } // a's unref returns it to the free pool
Aug 24 2002
next sibling parent "Walter" <walter digitalmars.com> writes:
Yes, it should wind up calling the finalizer.

"Patrick Down" <pat codemoon.com> wrote in message
news:Xns9274526F5BFB6patcodemooncom 63.105.9.61...
 "Walter" <walter digitalmars.com> wrote in
 news:ak6f6p$2oan$1 digitaldaemon.com:

 "Patrick Down" <pat codemoon.com> wrote in message
 news:Xns9273A36B24E83patcodemooncom 63.105.9.61...
 Walter if you did put in a language level reference counting
 mechanism for deterministic object destruction you would be a
 mega super hero.

I did suddenly realize that d.o.d. naturally falls out of reference counting, but reference counting does not fall out of d.o.d., which is why it is so clumsy and error prone to do reference counting in C++.

Yes but I think you should call it d.o.f. Deterministic Object Finalization. Here's why. What I think would be a good idea is not to call the objects destuctor (~A) when the refCount==0 but to call a different function. Perhaps unref(). If a user want's the full memory cleanup they can call "delete this". The reason is you can use it to implement other memory management schmes on top of the mark and sweep. If I am allocating and deallocating a lot of small objects quickly I might want to do object pooling. class Foo : Counted { static Foo head; static Foo alloc() { Foo temp; if(head) { temp = head; head = temp.next; } else temp = new Foo(); } void unref() { this.next = head; head = this; } private next; } { Foo a = Foo.alloc() } // a's unref returns it to the free pool

Aug 24 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
So just put the finalization code into the destructor.  I wouldn't want
these things to be forced to come from the heap.  And why have two subtly
different finalization methods?

Instead of "delete this" they can call "gc.dealloc(this)" or some such, in
your scenario.

Sean

"Patrick Down" <pat codemoon.com> wrote in message
news:Xns9274526F5BFB6patcodemooncom 63.105.9.61...
 "Walter" <walter digitalmars.com> wrote in
 news:ak6f6p$2oan$1 digitaldaemon.com:

 "Patrick Down" <pat codemoon.com> wrote in message
 news:Xns9273A36B24E83patcodemooncom 63.105.9.61...
 Walter if you did put in a language level reference counting
 mechanism for deterministic object destruction you would be a
 mega super hero.

I did suddenly realize that d.o.d. naturally falls out of reference counting, but reference counting does not fall out of d.o.d., which is why it is so clumsy and error prone to do reference counting in C++.

Yes but I think you should call it d.o.f. Deterministic Object Finalization. Here's why. What I think would be a good idea is not to call the objects destuctor (~A) when the refCount==0 but to call a different function. Perhaps unref(). If a user want's the full memory cleanup they can call "delete this". The reason is you can use it to implement other memory management schmes on top of the mark and sweep. If I am allocating and deallocating a lot of small objects quickly I might want to do object pooling. class Foo : Counted { static Foo head; static Foo alloc() { Foo temp; if(head) { temp = head; head = temp.next; } else temp = new Foo(); } void unref() { this.next = head; head = this; } private next; } { Foo a = Foo.alloc() } // a's unref returns it to the free pool

Aug 24 2002
parent Patrick Down <pat codemoon.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in
news:ak8k3k$2d8g$1 digitaldaemon.com: 

 So just put the finalization code into the destructor.  I wouldn't
 want these things to be forced to come from the heap.  And why have
 two subtly different finalization methods?
 
 Instead of "delete this" they can call "gc.dealloc(this)" or some
 such, in your scenario.
 
 Sean
 

That's fine too. I just don't want the memory explicitly collected after ~A is called.
Aug 24 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
Yes but the refcounting overhead can many times be optimized away.

In any case I have never ever seen refcounting overhead show up in a
performance profiler.  It could cost you some valuable memory though, but in
most cases I think it's worth it.  You wouldn't want to refcount, say, a
point or rectangle.  But anything bigger than a matrix would be a good
candidate.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:ak6f6p$2oan$1 digitaldaemon.com...
 "Patrick Down" <pat codemoon.com> wrote in message
 news:Xns9273A36B24E83patcodemooncom 63.105.9.61...
 Walter if you did put in a language level reference counting
 mechanism for deterministic object destruction you would be a
 mega super hero.

I did suddenly realize that d.o.d. naturally falls out of reference counting, but reference counting does not fall out of d.o.d., which is why it is so clumsy and error prone to do reference counting in C++.

Aug 24 2002
parent Mac Reiter <Mac_member pathlink.com> writes:
In any case I have never ever seen refcounting overhead show up in a
performance profiler.  It could cost you some valuable memory though, but in
most cases I think it's worth it.  You wouldn't want to refcount, say, a
point or rectangle.  But anything bigger than a matrix would be a good
candidate.

Sean

Most performance profilers (VTune, AMD Code Analyst, MSVC profiler, and even gprof, I think) are sampling profilers -- they kick in every so many milliseconds and see where the program counter is aimed. Reference counting is one of those insidious performance problems where each individual reference counting operation takes a very small amount of time (although it is usually considerably longer than the amount of time a non-refcounted thing would take), so the chances of the sampling profiler catching it are almost zero. One of the larger concerns about refcounting involves multithreading. Every reference counting operation must be threadsafe, which involves a mutex lock/unlock for every increment/decrement. OK, on an x86 you can use the "interlocked increment/decrement" instructions to do this much more efficiently, but not all architectures have these. In the presence of SMP architectures, having to force all CPUs to agree on a value can introduce significant synchronization overhead. If your profiler takes samples every 10ms, I could burn 9ms out of every 10 and never show up in its report. I have seen this happen. Another cost, similar to refcounting for difficulty pinning down, is array bounds checking. I have run many programs through a profiler and never seen the bounds checking code show up as a meaningful percentage of execution time (maybe 1-2% in the report). But if I remove it, suddenly my program runs between 50-100% faster. The other profiling option is to instrument the code. Usually only function entry/exit is instrumented (reported out to the external profiler). Very small functions then consume an inordinate amount of time, because it takes two moderate sized logging functions for every call to the small function. This tends to corrupt the report accuracy. I know that TrueTime from NuMega used to claim that they could subtract out this logging time and give you a real report. The problem I always had was that it was hopelessly tied into particular sub-versions of MSVC, and just applying a service pack could cause your profiler to stop working... The only real way to know where your program is spending all of its time, unfortunately, is an ICE and a super fast, mega memory logic analyzer. Not really worthwhile for most development. But any profiler that is sharing space on the same computer as the profiled code will have certain kinds of performance problems that it simply cannot see, or cannot accurately report. Profilers are good things. But it is always important to remember exactly what your meter is really showing you, and that what you are shown is rarely a complete picture. Also, reference counting is a good thing in the right place. I'm the one who suggested 'counted', so obviously I would like to see reference counting supported. But it is also important to remember that, on the whole, garbage collection will manage memory for a much lower overall overhead than reference counting. Reference counting is useful for deterministic finalization, but it comes at an additional price. (OK, refcounting is also useful for distributing the cost of memory management thinly over your whole application run. If it is better to have 20% memory overhead consistently than it is to have 10% memory overhead all bunched together in a half-second interval, then you want refcounting. This is the kind of decision that real-time and game programmers have to make.) Mac
Aug 25 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
I would very much like that but it's not something that would prevent me
from using D.  I can always manually delete things.  But performance wise
it's much better if the compiler knows when things are going out of scope
and just deletes them immediately, or even better knows this and allocates
them on the stack instead.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:ak5qb3$21dc$2 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:ak5oq2$1vqe$1 digitaldaemon.com...
 I for one had almost given up on D due to the lack of exactly those two
 features.  It seemed at the time that Walter was dead set against them.

 that operator overloading is in and templates are going in soon, I'm
 definitely going to have to take another crack at it.  Good debugger

 would help immensely; that's probably the next big thing on my list.

The only significant language thing now is the deterministic object destruction.

Aug 24 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ak8jib$2ci8$1 digitaldaemon.com...
 I would very much like that but it's not something that would prevent me
 from using D.  I can always manually delete things.  But performance wise
 it's much better if the compiler knows when things are going out of scope
 and just deletes them immediately, or even better knows this and allocates
 them on the stack instead.

I've been thinking about a root "ref counting class" hanging off of Object. This will work in most cases, but it fails if an instance is implicitly cast to an Object reference, and then that reference isn't counted.
Aug 24 2002
parent reply Pavel Minayev <evilone omen.ru> writes:
On Sat, 24 Aug 2002 13:34:35 -0700 "Walter" <walter digitalmars.com> wrote:

 I've been thinking about a root "ref counting class" hanging off of Object.
 This will work in most cases, but it fails if an instance is implicitly cast
 to an Object reference, and then that reference isn't counted.

Then maybe create a separate hierarchy tree? So that Object would be root for all GC-collected classes, and that other class - not derived from Object - root to all refcounted classes.
Aug 24 2002
next sibling parent "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374931061655671 news.digitalmars.com...
 On Sat, 24 Aug 2002 13:34:35 -0700 "Walter" <walter digitalmars.com>

 I've been thinking about a root "ref counting class" hanging off of


 This will work in most cases, but it fails if an instance is implicitly


 to an Object reference, and then that reference isn't counted.


 all GC-collected
 classes, and that other class - not derived from Object - root to all
 refcounted classes.

I did think of that, but I think it adds too much end-user complexity. There's got to be a better way...
Aug 24 2002
prev sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Pavel Minayev wrote:

 On Sat, 24 Aug 2002 13:34:35 -0700 "Walter" <walter digitalmars.com>
  wrote:


 I've been thinking about a root "ref counting class" hanging off
 of Object. This will work in most cases, but it fails if an
 instance is implicitly cast to an Object reference, and then that
  reference isn't counted.

Then maybe create a separate hierarchy tree? So that Object would be root for all GC-collected classes, and that other class - not derived from Object - root to all refcounted classes.

Refcounting is viral, so the hierarchy would have confusing intermingling, and migrate to everyone being refcounted. I don't want to get into this debate, as the only result will be that refcounting's a bloody huge problem that needs more investigation. It's straightforward for interpreted languages and not so for native code. Unprecedented to my knowledge, which is far from broad, due to things like: counted class foo { int y; } foo h = new foo; int *z = &h.y; h = null; I'm not pointing this out as an impossible problem; I'm pointing it out as an unobvious one with big consequences, and there are many others, certainly ones I have no knowledge of. Refcounting requires an in-depth review of its effects to find out what the damage really will be, what language changes will be needed, or if it's simply not possible to have both it and what's recognisably D.
Aug 24 2002
next sibling parent "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:3D6822B5.6020409 users.sourceforge.net...
 I'm not pointing this out as an impossible problem; I'm pointing it out
 as an unobvious one with big consequences, and there are many others,
 certainly ones I have no knowledge of.  Refcounting requires an in-depth
 review of its effects to find out what the damage really will be, what
 language changes will be needed, or if it's simply not possible to have
 both it and what's recognisably D.

You're quite possibly right.
Aug 24 2002
prev sibling next sibling parent Pavel Minayev <evilone omen.ru> writes:
On Sat, 24 Aug 2002 17:20:05 -0700 Burton Radons <loth users.sourceforge.net> 
wrote:

 I don't want to get into this debate, as the only result will be that
 refcounting's a bloody huge problem that needs more investigation.  It's 
 straightforward for interpreted languages and not so for native code. 
 Unprecedented to my knowledge, which is far from broad, due to things like:
 
     counted class foo { int y; }
 
     foo h = new foo;
     int *z = &h.y;
     h = null;

Well, D isn't sandbox C#. You can do weird things even now, for example return a pointer to a local variable. Not much different - and, in fact, happens quite often, compared to your example... pointers are dangerous by themselves, and as long as one avoids them (which _is_ possible in high-level D - dynamic arrays and references really help), there shouldn't be any problem with refcounting.
Aug 25 2002
prev sibling next sibling parent reply Mac Reiter <Mac_member pathlink.com> writes:
I don't want to get into this debate, 

Too late! (sorry...)
as the only result will be that
refcounting's a bloody huge problem that needs more investigation.  It's 
straightforward for interpreted languages and not so for native code. 
Unprecedented to my knowledge, which is far from broad, due to things like:

    counted class foo { int y; }

    foo h = new foo;
    int *z = &h.y;
    h = null;

Let me first state that I understand the problem of trying to come up with a short, clear example on the spur of the moment. My comments may be focusing too much on the particular example than on the root problem. I have attempted to think about and address the issue in a wider scope, but I have also not been awake for very long... If, when reading the following comments, you think of a real example piece of code that exhibits the root problem without having the bad design problems that I will discuss below, I would be very interested in seeing your code. Most garbage collectors will also hork on this problem (in the general case). The Boehm GC will consider h to be garbage after the NULL assignment, unless you specifically turn on support for tracking pointers to partial objects. (In this particular instance, the address of h.y is probably the same as the address of h, so it would happen to work even in a 'whole object only' GC. But let us assume a more general case where y is not the first member of foo.) If you do try to handle pointers to members, the cost for _any_ automatic memory management scheme increases by several hundred percent. For the Boehm collector, I believe the _additional_ penalty multiplier is roughly equivalent to the average size of your GC'ed objects. Boehm has no type information, and thus cannot perform faster operations to locate object starts -- it must scan through nearby memory. I may be misremembering this, so I would suggest reading the documentation for the Boehm GC rather than taking my word for it. I feel I should also point out that the above code deserves to explode violently. It is logically equivalent to returning a pointer or reference to an automatic local variable from a function in C or C++. By the time the pointer/reference is used, it is invalid. First, in most cases you shouldn't make pointers that point to members. Just make a foo* and aim it at h, then pull the member out normally. In C/C++, pointers to members would be used as an optimization in a loop (saves the indirect field access for each loop -- a good optimizer should have done it automatically, but we won't go there. Also, in D, you can use the 'with' keyword for the same effect). However, you would never point at a piece of an object, delete the object, and then start a loop that worked with a member. There are times, though they occur relatively infrequently, when a pointer/reference to a member is needed rather than just "convenient". But if you don't hold a pointer/reference to the full object somewhere else, the results are going to be undefined. This is not a problem specific to GC or refcounting. Imagine doing the same thing in C++. At the end of the code sequence above, you would have leaked a foo. Since you no longer have the address of the actual object, you can't delete it. As a side note: If you *REALLY* have to do this, it is possible to cast 0 to the class type, ask for the address of the member to which you have a pointer (this will give you the offset of that member inside that class), and then subtract this offset from your member pointer to get the original object address. Any time you find yourself writing code that is that horked up, you should seriously consider if your architecture has been designed properly... Mac
Aug 25 2002
parent "Walter" <walter digitalmars.com> writes:
Your design points are correct, but I wish to point out that the D gc will
correctly handle pointers into the middle of an object.
Aug 25 2002
prev sibling parent reply Mac Reiter <Mac_member pathlink.com> writes:
I'm not pointing this out as an impossible problem; I'm pointing it out 
as an unobvious one with big consequences, and there are many others, 
certainly ones I have no knowledge of.  Refcounting requires an in-depth 
review of its effects to find out what the damage really will be, what 
language changes will be needed, or if it's simply not possible to have 
both it and what's recognisably D.

Something that has been bothering me a bit more is the interaction of GC and RC (refcounting). The GC must not simply ignore RCed objects, assuming that the RC system will properly dispose of them. If it does, cyclic references amongst RC'ed objects would leak. I think that if the GC treats RCed objects just like every other object, everything will be fine. The GC should never delete an object that is still validly in use, because the user should be visible to D and thus to the GC. The only issue I can see is if you tried to work with RCed objects that were being manipulated by external non-D libraries, but you have similar problems with the GC. The safest bet all around is to make a D reference to the object and keep it valid while the external library is using it. I can't think of any problems with the GC behind RC method (that wouldn't exist individually for each of GC and RC anyway). Am I overlooking something? Mac
Aug 25 2002
parent reply Patrick Down <pat codemoon.com> writes:
Mac Reiter <Mac_member pathlink.com> wrote in
news:akaovp$1l7g$1 digitaldaemon.com: 
 
 Something that has been bothering me a bit more is the interaction of
 GC and RC (refcounting).  The GC must not simply ignore RCed objects,
 assuming that the RC system will properly dispose of them.  If it
 does, cyclic references amongst RC'ed objects would leak.

I think that reference counting should not activly reclaim memory when refcount == 0. Instead leave it mainly as a method of deterministice finalization. If the programmer truly desires that the memory be reclamed now he can explicitly suggest it to to the gc in the finializer. Otherwise just let the gc reclain it in its next mark and sweep pass.
Aug 25 2002
parent "Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> writes:
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns9275760177718patcodemooncom 63.105.9.61...

 I think that reference counting should not activly reclaim memory
 when refcount == 0.  Instead leave it mainly as a method of
 deterministice finalization.

Of course. Once I'm done with a piece of memory, all I want is for it to behave as if it's been freed, wether that's the case or not. As a general precept, I would never care what the program does behind my back (caching, reorganizing my data, etc...), as long as it behaves predictably the way it's intended to behave. Salutaciones, JCAB
Aug 25 2002
prev sibling next sibling parent "Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> writes:
"Carlos" <carlos8294 msn.com> wrote in message
news:ak21ck$2vse$1 digitaldaemon.com...

 First of all... sorry Juan Carlos if I'm violating your privacy anyhow,

 I'm just too curious. But... I want to know how close to this:
 http://www.jcabs-rumblings.com/JCAB.html, people in this newsgroup are.

He he... So now I'm famous or something? No problem. The page is linked by Google already, and it's publicly accessible, not private.
 Do you guys think that's a lot?

It's quite a bit, I'll admit. Something I'm proud of. Still... I don't think it's exceptionally much.
 Have you done more? (I know Walter has)
 I mean, I'm just a 20 years old student who knows Basic (QB, VB), most
 C/C++, some Delphi, Java and HTML, and starting to deal with D, and that's
 it. I thought that was a lot, but when I read all that, I was stunned.

And you think you've done too little? Jeez! 20 years old? I'm 33, myself. How much do you think you'll have learned and accomplished in 13 years?
 Well, should I say congratulations? I mean, if I wanted to (I don't want

 don't ask) put an objective in my life, and that was knowing, doing, etc.,
 what Juan Carlos does... God, I would have a long way to go! (add the fact
 that Spain is far more advanced in computers than any country in Latin
 America, where I live).
 Don't flame me for posting this... it's just that I'm too impressed.

I wouldn't dream of flaming such a flattering post. In any case, I'd recommend that you do what you enjoy doing and what you do best, rather than looking at someone else's accomplishments and trying to somehow emulate them (not that you would, but you could try and that would be bad, IMHO). You'll live happier that way. Salutaciones, JCAB
Aug 22 2002
prev sibling parent Burton Radons <loth users.sourceforge.net> writes:
For the other end of the spectrum: Nonprofessional, uneducated (both as 
a programmer and in the dropout sense), and 23, but with amateur 
experience all over the fool place.
Aug 22 2002