Thread View: comp.sys.mac.oop.macapp3
2 messages
2 total messages
Started by Personal Software, Alan Dail,PRT
Wed, 27 Jan 1993 15:54
Re2: C++ (was re: bedrock defe
Author: Personal Software, Alan Dail,PRT
Date: Wed, 27 Jan 1993 15:54
Date: Wed, 27 Jan 1993 15:54
48 lines
2814 bytes
2814 bytes
Larry, >You're right about this, and I haven't considered these issues. The == vs. >= problem is a flaw that C++ inherits from C. The same is true of switch >statements (where leaving out the break in each case is usually a mistake). There are other examples that cannot be blamed on C. One is the lack of a key word when overriding or overloading a method. This would give a safty check that you havn't made a mistake in your method name. Another example is the lack of the key word inherited. This allows your code to automatically adapt as your superclasses evolve. As it stands now, if you insert an override, it may never get invoked and you will not get any kind of indication from the compiler. Fortuanatly, C++ allows you to write superclassname::methodname() to get the effect of inherited. However, even then, if you change your superclass, you will have trouble. In any other OO language I'm aware of, you would have used either inherited or super originally and never run into a problem. >> like having various features clash when used together or having the wrong >I think there's a tradeoff here. You could remove lots of features from >the language, but then there would be useful things that you couldn't do. You wouldn't have to remove features, just design them to coexist better. For example, if you overload a function and then override one instance of it, all of the other instances get hidden. Why not allow these featues to coexist instead of conflict. >> defaults when using features (why isn't virtual the default?). It's a shame >C++ was designed for maximum performance. Changing the default would improve reliability without having to impact performance. All a programmer would have to do to get the performance would be to explicitly declare critical methods as nonvirtual. >For example, removing stack-based objects would simplify things >considerably, but stack-based objects are useful in many places. I agree that stack-based objects are usefull. However, I don't think they are quite the same thing as a class and could be restricted to structs. Doing this would allow class to be changed to have virtual for its default (or even better, have no default). I don't think any of these changes would this would impact the power of C++, but would make it less error prone and easier to learn. Alan
Re: Re2: C++ (was re: bedrock defe
Author: Mark Lanett
Date: Thu, 28 Jan 1993 01:32
Date: Thu, 28 Jan 1993 01:32
40 lines
2734 bytes
2734 bytes
ALANDAIL@AppleLink.Apple.COM (Personal Software, Alan Dail,PRT) writes: >You wouldn't have to remove features, just design them to coexist better. For >example, if you overload a function and then override one instance of it, all >of the other instances get hidden. Why not allow these featues to coexist >instead of conflict. The "hiding" *is* a feature, provided so C++ can warn you about covariant relationships, on the theory that overriding one function but not its siblings is more likely to be a logical error. You are free to provide pass-through overrides of the siblings if it applies to your situation. >Changing the default would improve reliability without having to impact >performance. All a programmer would have to do to get the performance would be >to explicitly declare critical methods as nonvirtual. Or use an intelligent DevEnv like Component Workshop. A lot of C++ stupidities have more to do with the need to parse it as text and compile it without knowing what context it's going to be used in. As we climb out of the text-based DevEnv hole, the language will be able to evolve to take advantage of information provided by the development environment. >I agree that stack-based objects are usefull. However, I don't think they are >quite the same thing as a class and could be restricted to structs. Doing this >would allow class to be changed to have virtual for its default (or even >better, have no default). Heh, never tried resource acquisition? If MacApp had real exception handling you'd see a LOT of stack-based classes for that purpose. It would do away with almost all FailInfo clauses that exist in your code today. That's a real plus. >I don't think any of these changes would this would impact the power of C++, >but would make it less error prone and easier to learn. How do stack-based objects make C++ harder to learn? The only situation I can think of is declaring one with the parenthesis for a default constuction (i.e. "CFoo f();") which instead declares a function returning such an object. It results in a compile-time error anyway, so all you need is a compiler that provides an intelligent error message in that case.
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads