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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,15edb893ef79e231 X-Google-Attributes: gidfac41,public X-Google-Thread: f4fd2,23202754c9ce78dd X-Google-Attributes: gidf4fd2,public X-Google-Thread: 103376,15edb893ef79e231 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,15edb893ef79e231 X-Google-Attributes: gid114809,public X-Google-ArrivalTime: 2002-02-13 15:12:19 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: tshawke@qwest.com (Tom Hawker) Newsgroups: comp.lang.lisp,comp.lang.ada,comp.lang.eiffel,comp.lang.smalltalk Subject: Re: True faiths ( was Re: The true faith ) Date: 13 Feb 2002 15:12:18 -0800 Organization: http://groups.google.com/ Message-ID: <43d7620c.0202131512.98d9592@posting.google.com> References: <4idg3u40ermnp682n6igc5gudp7hajkea9@4ax.com> <76be8851.0201101909.9db0718@posting.google.com> <9jtu3u8cq92b05j47uat3412tok6hqu1ki@4ax.com> <3C3F8689.377A9F0F@brising.com> <3219936759616091@naggum.net> NNTP-Posting-Host: 207.225.133.18 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1013641938 25523 127.0.0.1 (13 Feb 2002 23:12:18 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 13 Feb 2002 23:12:18 GMT Xref: archiver1.google.com comp.lang.lisp:26466 comp.lang.ada:19981 comp.lang.eiffel:5675 comp.lang.smalltalk:19584 Date: 2002-02-13T23:12:18+00:00 List-Id: Immanuel Litzroth wrote in message news:... > > In this respect the articles... > > Immanuel I read through both of these articles. I have also read through all of the responses to this subthread. I am not a C++ expert, but I have a background in computer languages. I would not have gotten a "perfect" solution, but the problems associated with "owning" pointers were obvious, and really should be so to anyone with a basic OO background, which I guess eliminates most of the C++ programmers. ;-) My solution did not include transactions (the try/catch stuff), because I would have assumed a failure to be catastrophic (an oversight of the stated problem requirements). Unwise, perhaps... But all that aside, I am surprised that everyone seems to have missed an underlying concept. Most of this thread goes into all the funny semantics of assigning, copying, and garbage collection behavior, while overlooking the simplest fact of all: the hassles come about because you're dealing with a strongly typed language! (Ada's limited private types only make the contract cleaner to visualize, they don't overcome the associated problems. And don't get me started on the supposed advantages of strong vs. weak/dynamic typing.) GCed languages usually eliminate the problem of "assignment" because there is no such feature: they do dynamic typing/dynamic binding, replacing references (virtual pointers) to objects rather than the contents. You have to write special methods to implement assignment, and I have found only a handful of cases where that is desirable, let alone necessary, and after years of thought I'm not certain about those. In such cases I've used "copy_from", where the argument is the source whose state is copied into the receiver. (Destructors for releasing system resources are usually invoked manually or can be through GC finalization mechanisms, which automate the necessary cleanup even in cases that would otherwise be memory leaks.) Now, all of the things said about "owned" versus "aliased" references must be taken into account. In my experience a dynamically typed language will never have a slicing problem. But ownership of contained objects must still be managed. Where the language doesn't support assignment per se, then implicitly this means "owned" objects must be copied (that is, cloned) in the usual way for the language when assignment is implemented, which is what you'd expect. Which leads to the discussion of copy semantics. Either the language or the type must define the semantics of what "copy" means. It certainly is easier when the language specifies a default interpretation. But there are valid reasons for having shared_copy (which does NOT do ownership copies), shallow_copy (which copies or clears contained objects not meant to be shared, such as a dictionary cache), and deep_copy, which copies everything and its brother, sister, cousin, and aunt. Some data structures cannot wisely implement deep copies without some smarts to prevent infinite replication, such as duplicating graph structures. I guess my point to all of this is that I will contend that the problem is in the language and not the individual. Yes, an unfortunate number of our colleagues may not really understand the complexities of languages they use. (Let's leave personal indolence and insolence out of it, shall we?) Yes, management usually feels it needs to exert its authority on issues for which it is not competent to evaluate the options. (Let's skip the ego thing, too.) But *why* do I need to propagate such insanities where there are better ways? Stroustrop et al and his philosophy notwithstanding, with a background in languages and a frequent, practical user of compiler technology, my opinion professionally is that C++ as a language absolutely sucks. It is a pain to use simply because all of the issues noted in this thread are counter-intuitive. It doesn't matter in the least whether they are useful to have. There is simply no reason whatsoever that the normal, introductory, or just plain naive programmer should ever feel like disemboweling him/herself trying to get something to work when the trouble is related to obscure language semantics. (I'm sorry, this is one of the reasons I dislike Ada: coming up with the Posix bindings was almost an exercise in futility because of all the restrictions on packages and types.) In that regard, Objective-C is much cleaner as a strongly typed language, since it is a real albeit hybrid OO language, where the OO-ness has been neatly layered onto the original language. And so that leads to objections about changes to the [base] language. I must disagree: changes are inevitable. We always find better ways to do things, or eventually discover that the original way was not as extensible (read that, "OO") as one would like, or even that some way we depend on is flatly wrong, and so we "improve" it. I've had to port system implementations across 8 versions of a single language, and it is never easy when you've made system (base code) extensions or changes. (One particularly nasty variant was a rewrite of the graphics system!) Having a language "protected" by a "standard" still doesn't prevent gratuitous changes. The best one can do is adapt programming practices that help to minimize the effects of such rudeness. But don't whine about it, because the language we favor most today may very well either be changed or obsolete tomorrow... -- Tom