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,


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 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


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.


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.


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.


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




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 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.


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.


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>


wrote:

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


 Also, templates now have to be actually _implemented_. =)


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>


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 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.


 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.


 
 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.


 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.


 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>


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.


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;



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,


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.


   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


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.


   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