- Simulating halt deciders refute the halting theorem - 2 Updates
- Virtual functions: To const, or not to const? - 7 Updates
- how to specify an 8 byte bool ? - 1 Update
- attempt to dereference a singular iterator - 2 Updates
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Oct 10 09:31AM -0700 > Usenet without going anywhere, it's likely the funding would be > swiftly cut off. > It's not a probelm of money. The problem here is you, responding to this idiot instead of just ignoring him like all sensible people do. And cross-posting only makes it worse. |
| olcott <polcott2@gmail.com>: Oct 10 12:05PM -0500 On 10/9/2022 3:43 PM, Kaz Kylheku wrote: > Usenet without going anywhere, it's likely the funding would be > swiftly cut off. > It's not a probelm of money. Once one accepts the notion of a simulating halt decider that continues to correctly simulate its input until it correctly determines that this simulated input would never stop running then the conventional halting problem proofs are refuted because their "impossible" input becomes correctly construed as specifying recursive simulation (same idea as infinite recursion). An extended conversation with the former editor in chief of the Communications of the ACM: Moshe Y. Vardi indicated that I must be able to apply my work to the diagonal argument so I just did that. *Rebutting the Sipser Halting Problem Proof* https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Juha Nieminen <nospam@thanks.invalid>: Oct 10 06:20AM > A virtual function is an interface, not implementation detail. It > doesn't make sense to me to have a virtual function that is logically > const in a base class, but logically non-const in a derived class. There are situations where the base class function is *so* abstract that it doesn't even express if the derived class implementations should be mutable or const. Some derived classes might want to implement as a non-const function, other derived classes as a const function (so that it can be called with const objects/references). There's really no way to allow for this in the base class. Making the base class function const (and expecting the derived class to use const cast to eg. call other of its own non-const functions) seems a bit wrong. On the other hand, making it non-const now makes calling the function with a const object harder. Declaring both a non-const and const versions of the function may burden the derived class with having to implement a const version that it can't logically implement. All possible solutions have something wrong about them. |
| Richard Damon <Richard@Damon-Family.org>: Oct 10 07:38AM -0400 On 10/10/22 2:20 AM, Juha Nieminen wrote: > and const versions of the function may burden the derived class with > having to implement a const version that it can't logically implement. > All possible solutions have something wrong about them. If the definition of what the function can do is that loose, then it isn't defined well enough to be an "interface". If in some cases it must be able to be performed on a const object becuase it is defined to not change the object, but for other sub-types it can't be used on const objectes because it does change the object, then the operation isn't the "same" for all cases, and so you can't define the generic interface. Given an object which you only know is of an object defined from something of that base, you don't know if you can use that operation on it. Thus, it can't be an actual interface. It may be that all of them can use the non-const version, and specific sub-types can add (as an overload) a const version. |
| Juha Nieminen <nospam@thanks.invalid>: Oct 10 12:08PM > If the definition of what the function can do is that loose, then it > isn't defined well enough to be an "interface". That isn't very helpful if you are in this situation. I suppose the answer is: "If you can't redesign the base class in such a way that such ambiguity doesn't happen, then perhaps the best option is to make it non-const and then in the derived class create a const version that calls the non-const one using a const_cast. It might be a bit ugly, but it's the best we got." |
| Paavo Helde <eesnimi@osa.pri.ee>: Oct 10 03:13PM +0300 10.10.2022 09:20 Juha Nieminen kirjutas: > mutable or const. Some derived classes might want to implement as a > non-const function, other derived classes as a const function (so that > it can be called with const objects/references). If that's really so, then it looks like you have got two different class hierarchies or at least two interfaces, not one. Maybe the part(s) of the inheritance tree which you want to call over const references should be cut off and converted into a separate tree having a const interface. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 10 05:58PM +0200 Am 08.10.2022 um 21:19 schrieb Mr Flibble: > Bullshit. Whilst in general composition is to be preferred over > inheritance there is nothing fundamentally wrong with deep inheritance > hierarchies ... There's nothing wrong in a sense that there's usually no alternative. But nevertheless these hierarchies might be hard to design. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Oct 10 09:26AM -0700 Juha Nieminen <nospam@thanks.invalid> writes: [...] > All possible solutions have something wrong about them. That's because what you're asking for is self-contradictory. On the one hand you want to be able to invoke the method on a const reference. On the other hand you want invoking the method on a const reference to give a compile-time error. Obviously the same interface cannot do both, because either possibility necessarily precludes the other. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Oct 10 09:43AM -0700 >> it can be called with const objects/references). > If that's really so, then it looks like you have got two different > class hierarchies or at least two interfaces, not one. Right. I was wondering how long it would be before someone would reach this conclusion. Here is an outline for a scheme that supplies each of the four logically distinct possibilities: struct super_neither { protected: unsigned u_; public: super_neither() : u_(0) {} virtual ~super_neither(); }; struct super_mutable_only : public virtual super_neither { virtual unsigned u() { return ++u_; } }; struct super_nonmutable_only : public virtual super_neither { virtual unsigned u() const { return 1+u_; } }; struct super_both : public super_mutable_only, super_nonmutable_only { virtual unsigned u() { return super_mutable_only::u(); } virtual unsigned u() const { return super_nonmutable_only::u(); } }; Different subclasses should choose whichever of the four given superclasses that is most appropriate to their individual needs. Disclaimer: code intended only to illustrate the approach; some details may need changing, depending on particular circumstances. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 10 06:04PM +0200 Am 05.10.2022 um 03:41 schrieb Lynn McGuire: > How do I specify an 8 byte bool ? Long long ? If you use a long long you most times need a size_t on 64 bit platforms and a 32 bit size_t on 32 bit platforms. size_t'd bools might make sense to address two entities following each other in an array depending on the result of a boolean operation. Even this silly RISC-V-platform has an operation to load a zero or a one into a register depending on the result of a comparison (unfortunately that's the only predicated opera- tion that RISC-V has). |
| Juha Nieminen <nospam@thanks.invalid>: Oct 10 06:21AM >> I will try do this but it won't be easy task - my program has nearly 10 >> KLOC. > Moreover, my program consists of many highly-coupled files. Often that's indicative that the program could benefit from a good refactoring. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 10 01:03AM -0700 On Friday, 7 October 2022 at 16:20:41 UTC+3, Jivanmukta wrote: > > I will try do this but it won't be easy task - my program has nearly 10 > > KLOC. > Moreover, my program consists of many highly-coupled files. An attempt to remove parts that are unrelated to your problem will also help to see ways how to reduce interdependence between parts of your program (IOW to make it well-structured). |
| 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