The D Programming Language
in [C++]
|
From: Francis Glassborow on 12 Dec 2006 21:38 In article <1165829515.431959.82460(a)j72g2000cwa.googlegroups.com>, PeteK <pete_k_1955(a)yahoo.co.uk> writes >Actually I'm surprised that Francis prefers if(p), given that he >teaches C/C++. if (p != NULL) is much clearer for a novice (and >especially for someone who's used to a non-C-stype language). That is just because your own experience has biased you. Properly presented if(p) is fine and I have yet to have a student have a problem with it. -- Francis Glassborow ACCU Author of 'You Can Do It!' and "You Can Program in C++" see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mirek Fidler on 13 Dec 2006 08:20 PeteK wrote: > Nope. I use intrusive reference counting, so the only delete is in the > root base class. > > I did a quick check of the number of deletes in a fairly large project > that I've been working on. There were four deletes. My experience is the same. In U++ widget library (about 70 widget classes, 25000 lines), there are 2 delete statements somewhere deep in implementation (only as optimization measure). And 0 smart pointers. Mirek -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Ivan Vecerina on 13 Dec 2006 08:19 charset="iso-8859-1" X-Original-Date: Wed, 13 Dec 2006 06:37:40 +0100 X-Submission-Address: c++-submit(a)netlab.cs.rpi.edu { extraneous line breaks removed. -mod } "Vidar Hasfjord" <vattilah-groups(a)yahoo.co.uk> wrote in message news:1165886265.324861.242170(a)f1g2000cwa.googlegroups.com... : peter koch larsen wrote: : : > Worse is the negations: : > I "never" write [if (!t)] when t is not bool. : : The irony is that the latter "false" case is safer than the "true" : case, because you can explicitly control the conversion to bool via : operator overloading for the type involved (hence avoid unwanted : implicit conversions). This leads to the strange {if (!!t)} idiom to : test the "true" case. I admit that if( !!p ) took me minutes to parse, on first encounter. Yet once you think of !! as a "cast-to-bool" operator, it just feels very natural. And then you do away with the operator bool() vs operator void*() vs operator ObscureMemberFunctionPointer(), by having a single operator !() member to enter into the bool world. Weighing in readability, risk of error (=0 vs ==0), the 0 vs NULL debate, I have settled for the " strage cast-to-bool !! idiom ", and seen a number of other programmers happily convert to it. I do wish it were taught by some C++ authors... -- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 13 Dec 2006 08:33 PeteK wrote: > James Kanze wrote: > > PeteK wrote: > > > James Kanze wrote: > > > > PeteK wrote: > > > > My experience is that almost no classes have a logical owner. > > > > Most classes which have a deterministic lifetime manage that > > > > lifetime themselves. When I'm using garbage collection in C++, > > > > I'd guess that about 90% of the deletes are "delete this". > > > Which is where our experience differs. For me, most classes are either > > > on the stack, in a collection or embedded in another class. > > In terms of number of classes, you're probably right. In terms > > of number of objects, however, it's less sure. Things like the > > characters in a string, for example, can't be on the stack, > > since they have variable size. > No, but they *are* in a collection. A string is just an ordered > collection of some character type. (and with small string optimisation > they often *can* be on the stack). You seem to have missed the point. Whether they're in a collection or not, they have to be managed. Either deep copied, at extra expense, or with some sort of reference counting, at extra complexity. With garbage collection, the simple memory array IS the collection. > > > Only a small number of classes require the use of smart > > > pointers and in the end even these are bound to the lifetime > > > of a single class created to run the application. The word > > > "delete" usually only turns up in comments. > > Or in a few special classes, such as smart pointers? > Nope. I use intrusive reference counting, so the only delete is in the > root base class. I use intrusive reference counting too, when I don't have garbage collection. It's a lot of extra logic, and it doesn't work well in a multithreaded environment (where you want smart pointers for other reasons). And of course, there are a lot of cases where it doesn't work, due to cycles. And in at least one application, where performance considerations required removing it from a large number of pointers in the transaction. (In fact, it's been my experience that reference counting doesn't work very well with transaction management. Once the object has been inserted into the transaction, the transaction has to manage it, not some abstract smart pointer.) Anyhow I don't see what this changes. What's the difference if the delete is in the smart pointer, or in the required base class? > [snip] > > > In C++ something is logically dead when it's destructor is > > > called. The fact that you've got live pointers to it doesn't > > > mean it's alive, it means you've probably got an error in your > > > program. > > By definition, at the language level. C++ requires us to create > > a deterministic lifetime for all objects, even if the design > > doesn't require it. That's what I'm arguing against. > But the logical lifetime of an object is not necessarily dependent on > the language you use. For example, you talked about using dispose in > Java. When you call dispose the object is logically dead, regardless > of whether of not you have other references to the object. If you > simply forgot to call dispose the object would still be logically dead > at the point, you just wouldn't have formally killed it off. Certainly. Anytime you have to do something explicitly, there is a possibility of error. Neither garbage collection nor smart pointers can help here. The difference, of course, is that garbage collection means that for most objects---all those without an explicit lifetime---you don't have something explicit to do. > > > [...] > > > > True, but in practice, you don't have to worry about objects > > > > which aren't logically dead, but which are inaccessible, because > > > > the program doesn't need them any more. > > > Unless these objects contain precious resources. > > Which in practice they don't (except memory). How can a value > > contain a resource? > How can a value be an object? An object can have a value, but I don't > see how a value can have an object. A value must be stored somewhere. It's not an object in the OO sense, but it's an object in the C++ sense, i.e. it occupies memory. -- James Kanze (GABI Software) email:james.kanze(a)gmail.com Conseils en informatique orientie objet/ Beratung in objektorientierter Datenverarbeitung 9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34 -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: PeteK on 13 Dec 2006 09:20
Francis Glassborow wrote: > In article <1165829515.431959.82460(a)j72g2000cwa.googlegroups.com>, PeteK > <pete_k_1955(a)yahoo.co.uk> writes > >Actually I'm surprised that Francis prefers if(p), given that he > >teaches C/C++. if (p != NULL) is much clearer for a novice (and > >especially for someone who's used to a non-C-stype language). > > > That is just because your own experience has biased you. Properly > presented if(p) is fine and I have yet to have a student have a problem > with it. > Biased, maybe. But I don't think experience has much to do with it. I've been exposed to if(p) since a 286 was the biggest thing since sliced bread. I even tried using it for a while. But I still don't like it. OTOH I was appalled when I first saw returns everywhere (plus break and continue in loops) and would have been firmly in James's side in any SESE debate. However experience has told me that C++ is not really designed for SESE programming and now I'm definitely in Andrei's camp. (This isn't an invitation for the two of them to start another war :-) -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |