From owner-freebsd-chat Thu Jun 19 14:21:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA20027 for chat-outgoing; Thu, 19 Jun 1997 14:21:57 -0700 (PDT) Received: from xmission.xmission.com (softweyr@xmission.xmission.com [198.60.22.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA20022 for ; Thu, 19 Jun 1997 14:21:39 -0700 (PDT) Received: (from softweyr@localhost) by xmission.xmission.com (8.8.5/8.7.5) id PAA08298; Thu, 19 Jun 1997 15:21:00 -0600 (MDT) From: Wes Peters - Softweyr LLC Message-Id: <199706192121.PAA08298@xmission.xmission.com> Subject: Re: c++ To: un_x@anchorage.net (Steve Howe) Date: Thu, 19 Jun 1997 15:20:52 -0600 (MDT) Cc: chat@freebsd.org, softweyr@xmission.com In-Reply-To: from "Steve Howe" at Jun 18, 97 09:25:46 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-chat@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Redirect to chat, since this isn't really a FreeBSD topic. Steve How recently asked: > can anyone direct me to a good newsgroup/maillist > for the GNU/C++ (bleh!) language/development? Try gnu.gcc.help or gnu.g++.help on Usenet. Your first solution would be to look in the "info" files that come with GCC. If you're not using Emacs, try the "info" program. If you *are* using Emacs, just hit C-h i. > i have alot of problems/questions w/C++. Funny, I use GCC in a variety of environments (FreeBSD, SunOS, HP-UX, VxWorks RTOS, and my own attempts with the SPARClite development system) and have few problems. Maybe GCC just likes me better? ;^) > opinions on C++ welcome. IMHO, it seems like > patching a hole in the sidewall of a tire. > maybe you get some more life out of code > for a while, but you're just avoiding > a bigger impending kludge in the > longrun - as opposed to keeping ordinary > C code up-to-snuff/organized/integrated > throughout the length of development. Apparently you've never worked on a large software project with many similar but not identical elements; this is what C++ really excels at. If you've looked at C++ but NOT object-oriented design, it's not a wonder you "dont get it" yet. Last year, I and another engineer developed a 70,000 line switching application in C++, debugged, tested, out the door in 13 months. This was in an embedded system, and had to be rock solid - no memory leaks, no resources losses of any sort. We literally couldn't have done it with the constraints we had without C++. For instance, we supported four kinds of switchers. Each of these 4 types have many things in common -- they switch signals, they provide varying levels of feedback about what happened to the switch command, etc. The type of switcher used is supposed to be complete transparent to the user. So, we had a generic switcher interface that specified all of the behavior of a switcher, and implemented as much as possible. For each of the four types of switcher, we have a class that derived from the generic switcher class, and implements only the parts that are unique to that type of switcher. You can, of course, develop this application in C, and use pointers to functions to call the individual "send a switch command" and "collect switcher status" functions for each switcher type, but that is *exactly* what the C++ derivation mechanism does for you. In another area, we had a serial port collecting commands from another computer, and sending status back. This software was designed to run on 3 similar-but-different computers, with 4 kinds of serial ports, all of which needed to support the same protocol. Yet another opportunity to create a generic CommPort class, with specific derivations to handle the individual differences between the four types of serial ports. The application code just reference a CommPort, and didn't care if it was a V25CommPort, or a 68302CommPort, or an 8250CommPort, or whatever. Yes, all of this was done with GCC 2.7.2. If you want to learn what C++ is about, I recommend _Designing Object- Oriented Applications Using the Booch Method_ by Robert Martin (Prentice Hall, ISBN: 0-13-203837-4). It should help to explain what C++ can and cannot help with. C++ is NOT a panacea, it won't cure all of the programming ills in the world, but it CAN be very helpful in managing even small projects. For a review of this book, see http://www.acorn.co.uk/associates/caug/References. I have a copy on my shelf, and still refer to it when designing a new class, just in case I've forgotten some of the things I should keep in mind when doing design work. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com