slc1290@hare.udev.cdc.com (steve chesney x4662) (06/22/91)
Our group is embarking on a large project to provide object oriented interfaces to a CAD/CAM database product. We have little experience in the OO world (and probably will implement the features in straight C), but want to approach the design from a genuine object view. Please recommend any training (or even books) in doing software design from an object orientation. We assume courses would nnormally be provided outside Minnesota, but on-site delivery is not ruled out. Thanks. -- Steve Chesney Control Data Corporation slc1290@hare.udev.cdc.com
txr@helios.sybase.com (Tim Rentsch) (06/24/91)
steve chesney writes: >Our group is embarking on a large project to provide object oriented >interfaces to a CAD/CAM database product. We have little experience in >the OO world (and probably will implement the features in straight C), >but want to approach the design from a genuine object view. C is obsolete. At least use C++. Why not? >Please recommend any training (or even books) in doing software design from >an object orientation. We assume courses would nnormally be provided >outside Minnesota, but on-site delivery is not ruled out. Thanks. Rational has an extensive object oriented training program. From what I know about the program, it might be just what you're looking for. They do take their show on the road, so you might even get your on-site delivery. Contact: Joe Marasco at Rational (don't have the phone number handy but they are in Santa Clara, area code 408). cheers, Tim
jls@netcom.COM (Jim Showalter) (06/25/91)
>C is obsolete. At least use C++. Why not? Well, for starters many organizations have a suite of tools built up over many years that is specifically targeted to C, and such tool commonly get tripped up by little gotchas when they're run on C++ code (e.g. mangled names, etc). This is not to say that such tools cannot be upgraded in a relatively short period of time, just that it IS necessary to do so--and some companies don't see a business case for making the extra effort. Don't get me wrong--I'm a big advocate of using more modern languages to do software engineering, but the facts and figures to support my gut intuition that, say, opaque types and formal interfaces help foster better code than do older languages are few and far between. You can easily sell C++ to a technical manager with the same gut intuition, but try selling it to a less technical manager with more of a dollars and cents focus. Have fun... This tools issue is not just idle chitchat, by the way. Last year I worked with a Very Large Telecommunications Company on a project to migrate 1MSLOC of a 4MSLOC project from C to C++, and one of the sticking points was the fact that they wouldn't even have a DEBUGGER for the C++ code until the end of the year. Seems the demands of their particular application domain had led them to add all kinds of proprietary (and perfectly justifiable) features to their toolset, many of which now fell over dead because of differences between C and C++. In a large organization, where toolbuilding is often the province of a service group beholden to no individual project, getting them to change existing tools can be about as easy as getting them to volunteer for root canals without anesthetic. C++ is technically superior to C, no question. But is it superior to C from a BUSINESS standpoint?--depends on a lot of other factors. >Rational has an extensive object oriented training program. From >what I know about the program, it might be just what you're looking >for. They do take their show on the road, so you might even get >your on-site delivery. Rational does exceptional OO training, and has been doing it for years (Grady Booch works at Rational). I used to work there and do OO training on their behalf--good stuff. Call Rational Consulting, (408) 496-3700. -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
dmg@ssc-vax (David M Geary) (06/26/91)
In article <1991Jun24.190417.10440@netcom.COM> jls@netcom.COM (Jim Showalter) writes: ]>C is obsolete. At least use C++. Why not? ] ]Well, for starters many organizations have a suite of tools ]built up over many years that is specifically targeted to ]C, and such tool commonly get tripped up by little gotchas ]when they're run on C++ code (e.g. mangled names, etc). This ]less technical manager with more of a dollars and cents focus. ]Have fun... ] ]This tools issue is not just idle chitchat, by the way. Last year ]I worked with a Very Large Telecommunications Company on a project ]to migrate 1MSLOC of a 4MSLOC project from C to C++, and one of the ]sticking points was the fact that they wouldn't even have a DEBUGGER ]for the C++ code until the end of the year. Seems the demands of ] ]C++ is technically superior to C, no question. But is it superior ]to C from a BUSINESS standpoint?--depends on a lot of other factors. ] Yes, tools are a problem at this stage of the game with C++. Another factor is portability. We have had to support a *Cimlinc* workstation (never heard of one, right?), a Unix box that has a C compiler, but does not, nor ever will, have a C++ compiler, since the machine is no longer produced, and noone's writing compilers for it. (BTW g++ is not an option for us, due to internal policies in Boeing). Therefore, due to lack of tools, or lack of compilers, many who would probably like to be programming in C++ are stuck doing C. However, this does not mean that one cannot apply the principles of OOP when writing C. There are many things one can do in C to achieve a high degree of modularity and reusability, however, many C programmers are not well versed in this area. -- |~~~~~~~~~~ David Geary, Boeing Aerospace, Seattle, WA. ~~~~~~~~~~| |-----------------------------------------------------------------------------| |~~~~~~ Seattle: America's most attractive city... to the *jetstream* ~~~~~~| |-----------------------------------------------------------------------------|
plyon@ut-emx.uucp (Paul Lyon) (06/28/91)
In article <4203@ssc-bee.ssc-vax.UUCP> dmg@ssc-vax.UUCP (David M Geary) writes: > Therefore, due to lack of tools, or lack of compilers, many who > would probably like to be programming in C++ are stuck doing C. > > However, this does not mean that one cannot apply the principles > of OOP when writing C. There are many things one can do in C to > achieve a high degree of modularity and reusability, however, many > C programmers are not well versed in this area. > > For those who would desire to become better versed, here a couple of references that could help: John W.L. Ogilvie, _Advanced C Struct Programming: Data Structure Design & Implementation in C_, Wiley & Sons, New York, 1990. This has useful examples, together with a running discussion on designing "abstract data types" that is oriented towards practical work (and seems clearly to be based on practical experience). C programmers trying to convert to C++ might also benefit from this book, not so much for guidance on programming in C++ (for there is no discussion of that therein), but more for the spirit of the thing: the idea being that once one sees how to design with abstract data types in C, one will be better prepared for programming in a C based language with support for abstract data types. Roger Sessions, _Reusable Data Structures for C_, Prentice-Hall Englewood Cliffs, 1989. This book has some instructive examples about how one might go about providing a measure of encapsulation within C for basic data structures such as linked lists, stacks, queues, and binary trees. [Sessions calls the reusable code modules that he presents "packages" (Hmm.., and what other language has he been using? :-)]. A nice feature of this book is the effort Sessions makes, in his "Performance" chapter, to speak to the concerns C programmers might have about efficiency, since his approach requires smallish functions (with a view towards making it easier to try to decide correctness). [His reply to such worries is a reasonable elaboration of "make it work before you make it fast".] Paul Lyon
txr@helios.sybase.com (Tim Rentsch) (06/29/91)
In article <4203@ssc-bee.ssc-vax.UUCP> dmg@ssc-vax.UUCP (David M Geary) writes: > Another factor is portability. We have had to support a *Cimlinc* > workstation (never heard of one, right?), a Unix box that has a C > compiler, but does not, nor ever will, have a C++ compiler, since the > machine is no longer produced, and noone's writing compilers for it. > (BTW g++ is not an option for us, due to internal policies in Boeing). The AT&T C++ translator produces C as output. Just get an AT&T C++ source license, run the translator through itself (on a sun, say), take the output C files, ship them over to the Cimlinc, compile, and you're in business. (Honesty in advertising section: there are also some hardware/os dependencies that need to be fiddled. No big deal. Any self-respecting C programmer would have the translator ported in less than a week.) Bottom line: if you've got a C compiler on your unix box, C++ can be available. > However, this does not mean that one cannot apply the principles > of OOP when writing C. One could apply the principles of zen meditation when writing C. Would that make the program a zen program? In practical terms it is very difficult to realize the benefits of OOP in a language that does not support OOP directly. C doesn't cut it. C++ does. On a scale from 1 to 10 of supporting OOP, if C were a 2, C++ would be 417. C++ is actually more like an 8 or a 9 on the OOP-support scale -- what does that tell you about C? > There are many things one can do in C to > achieve a high degree of modularity and reusability, however, many > C programmers are not well versed in this area. Mostly agree. The word "high" is relative. "Higher than the average C program" I completely agree with; "high compared to what's achievable in C++" is, in my experience, simply wrong. Don't get me wrong: C++ has its problems (need for better tools certainly among them). Problems and need for better tools notwithstanding, C++ is still a better choice than C. cheers, Tim