Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!usc!apple!sun-barr!lll-winken!ubvax!ardent!jra!jss From: jss@jra.ardent.com (Jerry Schwarz (Compiler)) Newsgroups: comp.lang.c++ Subject: Re: Strings Message-ID: <8835@ardent.UUCP> Date: 25 Oct 89 02:02:51 GMT References: Sender: news@ardent.UUCP Reply-To: jss@jra.ardent.com (Jerry Schwarz (Compiler)) Distribution: comp Organization: Ardent Computer Corp., Sunnyvale, CA Lines: 28 In article dl@oswego.edu writes: > >6) Avoid reliance on generic conversion functions like dec(), and >build special conversion buffers, etc., into the stream classes. AT&T >2.0 streams appear to do something along these lines. As Jerry says, >this puts too much smarts in the stream classes, but is entirely safe. My remark was subject to misinterpretation. I'll try to clarify. The 2.0 iostream classes contain mechanisms (xalloc, bitalloc, iword, and pword) to support formatting state for user defined classes. If I were redoing the package I would be inclined to use that general mechanism to deal with the builtins as well. This would eliminate all the special stuff for them. I'm not sure what "special conversion buffers" are. I don't think the iostream library has anything that is reasonably described with that phrase. >Unfortunately, it is also not as easily extensible as one might like. I'm not sure whether this refers to functionality or the amount of effort required to write the extension. It does require more coding than I would like to do some kinds of extensions, but I've achieved a reasonable functionality in all cases I've encountered. Jerry Schwarz