From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: Darren New Subject: Re: Why C++ is successful Date: 1998/08/10 Message-ID: <35CF37B5.C775FB9D@fv.com>#1/1 X-Deja-AN: 379777718 Content-Transfer-Encoding: 7bit References: <6qg3on$kjq$2@reader1.reader.news.ozemail.net> Content-Type: text/plain; charset=us-ascii Organization: First Virtual Holdings Inc Mime-Version: 1.0 Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-08-10T00:00:00+00:00 List-Id: > Perhaps you are thinking of languages like C++ that have pointers and > manual memory management and hence offer eminent chances for incorrect > programs to corrupt their pointer structure with dangling references > and memory leaks. If so, you are right; 100% safe garbage collection > for C++ is indeed impossible. Not so for other languages. Firstly, this has pretty much drifted off the Ada/Eiffel/Object newsgroups. Please fix followups, which I'd do if I read any of those groups. Secondly, it's possible to write C++ code that can be GCed reliably. All it requires is that the compiler not use machine addresses as the only information in a pointer. int a[12]; int * b; b = &a[5]; b += 10; // This is invalid Here, b would be represented as the tuple (with 12 and 5 scaled appropriately for the size of integers, perhaps). If I remember, the language standard says that the fourth line there is illegal, as it points b more than one past the end of the array. The GC could easily collect such pointers, but the efficiency of the manipulations would be low enough to be painful. When I used Pascal, there was an option you could turn on that would catch new(p); q = p; dispose(p); q^ = 7; new(p); q^ = 5; even if the second allocation landed in the same place as the first allocation in memory. Each memory block had a counter and a pointer. The counter said how many "new" calls had happened before this block was allocated, and the pointer pointed to the next allocated block. Each pointer had a counter as well. Each pointer reference could check that the counters matched, and that the block pointed to by the pointer was in the linked list of allocated blocks. *Lots* of overhead, but it was helpful for the students who were using it. (And of course you could turn it all off.) The point being that if you break out of the mindset that C++ is high-level assembler, all kinds of things are "possible" if inefficient. The fact that most C++ programmers would shun such overhead merely goes to show that either (a) machine time isn't as cheap as people think in applications where C++ is used, or (b) C++ programmers are less worried about correctness than efficiency. I'll let you choose which. -- Darren New / Senior Software Architect / First Virtual Holdings Inc http://www.fv.com or info@fv.com -=|=- PGP Key: ftp://ftp.fv.com/pub/fv Fingerprint: 61 7D AF 9E 00 CC C2 ED / D8 4C D7 AA E4 C2 A0 73