pilla@cbnewsi.ATT.COM (michael.a.pilla) (04/27/90)
The discussion of symbolic debuggers has been interesting. I have been using HCR Corporation's *flavor* of C++ which is packaged with an excellent debugger, dbxtra. Dbxtra is based on dbx which, IMHO, was a superior debugger to sdb for regular C. HCR's version is fully AT&T compatible, plus, is packaged with Gorlen's NIH classes. I believe the price is around $1K (US) and support is excellent. I have no affiliation with HCR other than a satisfied customer.
jimad@microsoft.UUCP (Jim ADCOCK) (04/30/90)
In article <813@maui.ACA.MCC.COM> db@maui.ACA.MCC.COM (David Murray Bridgeland) writes: > > - software IC's .... >Does anyone have a reference to this? "Object-oriented Programming; An Evolutionary Approach" Brad J. Cox Addison-Wesley 1986 ISBN 0-201-10393-1 This book is the Objective-C manifesto, with "Software-IC" its rallying cry. I would claim that integrated circuits and software have little in common, no matter how they are packaged. For a better book, see Meyer's "Object Oriented Software Construction", which is the equivalent book for Eiffel, with the rallying cry: "Asserts: pre, post, and class invariants."
jimad@microsoft.UUCP (Jim ADCOCK) (05/01/90)
In article <1006@media01.UUCP> pkr@media01.UUCP (Peter Kriens) writes: > One of the basic principles of object orientedness > is information hiding. In C++ I can understand that > some information is hidden from the programmer. BUT > not from the compiler. As far as I can see, this will > increase the number of include files & necessary > recompiles enormously. I believe this question relates to two issues: inline functions, and embedded objects. If you don't use embedded objects, but rather use references or pointers to objects, and if you don't use inline functions, then you will find [if you do it right] that you need little in the way of include files and recompiles. You'll also find that your code has speed and size closer to that of historical object oriented languages. Personally, I agree with you that C++ programmers are overusing embedded objects and inline functions. But since C++ is designed with a prejudice towards speed [a good prejudice IMHO] the language makes embedding and inlining the most convenient thing to write. > As far as I understand C++ inheritance is done > statically with the exception of the virtual > classes. Advantages in Smalltalk with complete > generic Bag's, Set's which depend on messages > on the objects that they contain seems almost > impossible to me, unless all classes are built > from one root. And this seems very hard if you > if you get outside classes. A lot of this has to do with the style people choose to program in C++. Unlike other OOPLs, C++ doesn't force you to follow one style of programming, but enables many styles of programming. Choosing the "right" style for you is left up to you. One philosophy says one should explicetely design the public protocols one needs for a particular job, express that protocol as virtual functions in an abstract class, and then inherit that protocol and implement its methods for a particular class. -- If you need your objects to be Bag'able, inherit the Bag'able protocol. Since C++ supports multiple inheritence, you aren't forced to place all your protocols in one big pile in your one base class -- requiring all objects to support several hundred methods! > I love the idea of Brad Cox of Software IC's. I > think the object oriented paradigm allows us to > buy very high level functions, while not having to > know anything about the implementation. Even buy > an alternate if one doesn't work right. I do not > see how such a structure could be implemented in > C++ without giving away too much of the internals. "Software IC" presumably being a metaphor implying the importance of encapsulation, rather than inheritance? [yes, I read Cox's book] -- I can't think of how "Software IC" is a good metaphor for inheritance, can you? As an example of this issue:, I think just about anyone with C experience has used files. One *could* look in the .h files and reverse engineer part of the file objects, but why would one bother to do so? Personally, I believe letting people see typical .h file stuff is a reasonable trade-off between the rights of the producer, and the rights of the consumer. I think a consumer has the right to see at least part of what they're using. If you're totally paranoid about letting anyone see any part of your class, make a proxy class that just contains a pointer to the actual objects you're implementing, and which delegates all proxy class methods to that class. Then no one can see any part of your implementation. ....This does add an extra level of indirection, which again, is going to give you performance more like other object oriented languages.... [ps: I believe "Software IC" has been copyrighted by Brad, or PPI, or someone]