- Available C++ Libraries FAQ - 1 Update
- RAII design question - 3 Updates
- Why is the memory allocated on the heap NOT freed? - 1 Update
| Nikki Locke <nikki@trumphurst.com>: Jun 14 10:19PM Available C++ Libraries FAQ URL: http://www.trumphurst.com/cpplibs/ This is a searchable list of libraries and utilities (both free and commercial) available to C++ programmers. If you know of a library which is not in the list, why not fill in the form at http://www.trumphurst.com/cpplibs/cppsub.php Maintainer: Nikki Locke - if you wish to contact me, please use the form on the website. |
| Gareth Owen <gwowen@gmail.com>: Jun 14 07:38PM +0100 > I'm pretty sure my description of LSP agrees with how it was > defined in the Liskov and Wing paper. Yeah, but what do they know? It doesn't agree with my own hazy idea of what the LSP is... > The thing about LSP is that it is quite stringent: subtypes can > provide stronger guarantees, but never weaker guarantees. Yeah. I think what I got what a kind of abstraction leak - as a disposable class I never formalised the guarantees, and my choice of implementation gave me a much stronger guarantee than I intended (because the reference could not be reseated, and the base destructor could not be side-stepped.) In effect my implementation of Timer had baked in far more behaviour than my mental model of the class. The CancellableTimer was (in the Liskov sense) a Timer-as-imagined, but not a Timer-as-implemented. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 14 09:10PM +0200 On 14-Jun-17 5:15 PM, Tim Rentsch trolled: > I don't understand You do. - Alf |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 14 09:58PM +0200 On 14-Jun-17 3:32 PM, Tim Rentsch wrote: > I'm pretty sure my description of LSP agrees with how it was > defined in the Liskov and Wing paper. Your view is as I see it not incompatible, but as I recall Liskov & Wing did not consider constructors and destructors (object lifetimes), which is what your interpretation is about. They, or at least Liskov, still as I recall, did consider generalization (e.g. of number types) versus specialization (e.g. of animal classes), which means that ideally one should be really careful about using the term "subtype" in a sense that implies it is their meaning: one would have to check the details of the various papers to be sure that was proper. For possibly their use of the term evolved. I'm not sure. However, we, now, have to use practical terminology. > class object would. The point of using a CancellableTimer is to > change some aspect of a Timer's behavior (ie, so as not to update > the referenced data), which violates what LSP requires. Let's consider how that (in your interpretation) LSP violation could manifest. For this to happen there must be some code where 1) The code is unaware that the object's dynamic type is CancellableTimer instead of the statically known Timer type. 2) The CancellableTimer::cancel method is invoked. 3) The object is destroyed. For example, in this code: void foo( Timer& t ) { // Whatever. } there is no LSP violation, because the object isn't destroyed. In this code: void bar() { Time total; CancellableTimer timer( total ); // ... if( something ) { timer.cancel(); } // ... } there is still no LSP violation, because the statically known type is not Timer: there is no case of not knowing the object's contracts. Getting the violation to manifest appears to require completely unreasonable, contrived code like this: // 3rd party library code: namespace g{ CancellableTimer* pLastTimer; } auto newTimer( Time& total ) -> Timer { g::pLastTimer = new CancellableTimer( total ); return g::pLastTimer; } void destroy( Timer* p ) { if( p = g::pLastTimer ) { pLastTimer = nullptr; } delete p; } void doUngoodThings( Timer* p ) { if( p == g::pLastTimer ) { g::pLastTimer->cancel(); } } // Client code: void xyzzy() { Time total; auto pTimer = newTimer( total ); // Whatever doUngoodThings( pTimer ); // Whatever destroy( pTimer ); // Oooh oh! `total` has not been set, as this code expected! } Maybe there is some simpler code where the violation manifests, but I think this shows that the (your interpretation) LSP violation is contingent on pretty special cases, unreasonable client code. I'm not entirely sure but it seems like prohibiting dynamic allocation would be enough to remove all possible manifestions of the (in your interpretation) LSP violation, and thereby, the violation itself. - Alf |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jun 14 04:36PM > bothers. Seems that ref counting is more popular right now than GC and > so some would ref count even with GC and so since C++ is no-one's > property it is up to fans of GC. ;-) Well, GC would be nice, but it is antipod for RAII. -- press any key to continue or any other to quit... |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment