brad@SSD.CSD.HARRIS.COM (Brad Appleton) (11/15/90)
Does someone have a list of errata for Lippman's "A C++ Primer"?
If so, could they e-mail it to me at `brad@ssd.csd.harris.com'
(or post it here)? I would me much obliged.
advTHANXance
______________________ "And miles to go before I sleep." ______________________
Brad Appleton brad@ssd.csd.harris.com Harris Computer Systems
uunet!hcx1!brad Fort Lauderdale, FL USA
~~~~~~~~~~~~~~~~~~~~ Disclaimer: I said it, not my company! ~~~~~~~~~~~~~~~~~~~des@adi.com (Dave Steinhoff) (11/17/90)
news@travis.csd.harris.com asks: > Does someone have a list of errata for Lippman's "A C++ Primer"? > If so, could they e-mail it to me at `brad@ssd.csd.harris.com' > (or post it here)? I would me much obliged. I picked this up from the net way back. Enjoy. From: stan@kaiser.UUCP (s Lippman) Newsgroups: comp.lang.c++ Subject: errata in C++ Primer Date: 19 Jun 89 16:15:16 GMT Organization: AT&T Bell Laboratories, Liberty Corner My ``C++ Primer'' is based on a draft of Bjarne's C++ Reference Manual (and matching in-house pre- release versions Release 2.0). Subsequent to the delivery of the manuscript a review of the language definition resulted in a few modifications. This impacts the book as follows: p.24 : the keyword ``handle'' is now replaced with the keyword ``catch'' (also page 430). p.40 : named enumerations now define unique integral types. For example, enum TestStatus { NOT_RUN=-1, FAIL, PASS }; enum Boolean { FALSE, TRUE }; main() { TestStatus test = NOT_RUN; Boolean found = FALSE; test = -1; // error: TestStatus = int test = 10; // error: TestStatus = int test = found; // error: TestStatus = Boolean test = FALSE; // error: TestStatus = const Boolean int st = test; // ok: implicit conversion } for compatibility with prior releases, the 2.0 implementation issues warnings rather than errors. p. 159: Overloaded functions can now be distinquished by arguments of an enumeration type. For example, enum Bool { FALSE, TRUE } found; enum Stat { FAIL, PASS }; extern void ff( Bool ); extern void ff( Stat ); extern void ff( int ); ff( PASS ); // ff( Stat ) ff( 0 ); // ff( int ) ff( found ); // ff( Bool ) p. 264-265: Class instances of operator new and operator delete should define arguments of type ``size_t'' rather than of type long. As Andy Koenig pointed out in a discussion of these operators, the current 2.0 implementation accepts the long argument and replaces it with that of size_t. The class instance of operator delete must define a return type of void. (There was a brief window when it was permitted to define an arbitrary return type -- this section was completed during this window.) p. 354 : A virtual function invoked within either the constructor OR destructor of a base class is resolved statically to the instance defined by the base class. (Thanks to Andy Koenig for pointing out the destructor case.) These corrections will be reflected in a subsequent reprinting of the book. Stan Lippman AT&T Bell Laboratories From: mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) Newsgroups: comp.lang.c++ Subject: Re: errata in C++ Primer Date: 19 Jun 89 19:26:44 GMT Reply-To: mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) Organization: Center for Supercomputing R&D (Cedar), U. of Ill. [I'm sorry if the original cancelled one gets out, too.] In article <883@kaiser.UUCP> stan@kaiser.UUCP (s Lippman) writes: >p.40 : named enumerations now define unique integral > types. For example, > > enum TestStatus { NOT_RUN=-1, FAIL, PASS }; > enum Boolean { FALSE, TRUE }; > > main() { > TestStatus test = NOT_RUN; > Boolean found = FALSE; > > test = -1; // error: TestStatus = int > test = 10; // error: TestStatus = int > test = found; // error: TestStatus = Boolean > test = FALSE; // error: TestStatus = const Boolean > int st = test; // ok: implicit conversion > } I'd like to see more details on what the semantics exactly are. The only examples here are for assignment, but for full clarity, I need to know the results of applying any operator to an enum operand. What happens when I have values and operations like: enum_X <op> enum_X => enum_X ? Y* <op> enum_X => Y* or error? int <op> enum_X => enum_X or error? type var[enum_X]; => tye var[(int) enum_X]; or error? Any other cases I've neglected? Suppose I want to count the number of times NOT_RUN, FAIL, and PASS occur. So I'd actually do something like this: enum TestStatus { NOT_RUN, FAIL, PASS, MAX_TEST }; int status_count[MAX_TEST]; for (TestStatus i = NOT_RUN; i < MAX_TEST; i++) status_count[i] = 0; enum TestStatus rc; while (dotest(&rc)) status_count[rc]++; Is this legal or not? I'd hate to have to muck about with int status_count[(int) MAX_TEST]; ... status_count[(int) rc]++; > int st = test; // ok: implicit conversion Bleah. Are there any other cases in C++ where type var = expr; is not equivalent to type var; var = expr; ? Are there any other possible "implicit conversions"? >p.40 : named enumerations now define unique integral types What's a "named enumeration"? Is typedef enum {FOO, BAR} widget; a named enumeration? What if we have enum {FOO, BAR} a; a = 1; // legal or no? Why are "named" enumerations distinguished from "unnamed" ones? -- "Let me control a planet's oxygen supply, and I don't care who makes the laws." - GREAT CTHUHLU'S STARRY WISDOM BAND (via Roger Leroux) __ \ Tim, the Bizarre and Oddly-Dressed Enchanter \ mcdaniel@uicsrd.csrd.uiuc.edu /\ mcdaniel%uicsrd@{uxc.cso.uiuc.edu,uiuc.csnet} _/ \_ {uunet,convex,pur-ee}!uiucuxc!uicsrd!mcdaniel From: ark@alice.UUCP (Andrew Koenig) Newsgroups: comp.lang.c++ Subject: Re: errata in C++ Primer Date: 20 Jun 89 12:55:52 GMT Organization: AT&T Bell Laboratories, Liberty Corner NJ In article <1304@garcon.cso.uiuc.edu>, mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) writes: > I'd like to see more details on what the semantics exactly are. The > only examples here are for assignment, but for full clarity, I need to > know the results of applying any operator to an enum operand. Every enumerated type is a separate type. When used in a context that requires an integer, a value of an enumerated type is quietly converted to an int. Converting the other way requires a cast. > What happens when I have values and operations like: > enum_X <op> enum_X => enum_X ? If <op> is something like `+', the result is an int. > Y* <op> enum_X => Y* or error? The enum_X value is quietly converted to int; the result is Y*. > int <op> enum_X => enum_X or error? The result is an int. > type var[enum_X]; => tye var[(int) enum_X]; or error? The enum_X is converted to an int. > Suppose I want to count the number of times NOT_RUN, FAIL, and PASS > occur. So I'd actually do something like this: > enum TestStatus { NOT_RUN, FAIL, PASS, MAX_TEST }; > int status_count[MAX_TEST]; OK so far. > for (TestStatus i = NOT_RUN; i < MAX_TEST; i++) > status_count[i] = 0; > > enum TestStatus rc; > while (dotest(&rc)) > status_count[rc]++; It's legal. The only part of this that's questionable is the notion of applying ++ to an enum, but I'm pretty sure that's OK even though the corresponding use of + would require a cast to convert the result back to enum. > Bleah. Are there any other cases in C++ where > type var = expr; > is not equivalent to > type var; > var = expr; > ? Are there any other possible "implicit conversions"? Saying type var = expr; is NEVER equivalent to saying type var; var = expr; The first case creates var and simultaneously initializes it to expr. The second creates var, initializes it to a default value (which is often garbage) and then obliterates that value with `expr.' It is possible to define types for which either of these is legal and the other is illegal. > >p.40 : named enumerations now define unique integral types > What's a "named enumeration"? Is > typedef enum {FOO, BAR} widget; > a named enumeration? What if we have > enum {FOO, BAR} a; > a = 1; // legal or no? No -- you need a cast to convert an integer to an enumerated type. > Why are "named" enumerations distinguished from "unnamed" ones? An unnamed enumeration doesn't give you a useful handle for the type it defines. It defines several objects (the one above defines FOO, BAR, and a) of a nameless type. Since the type is nameless, it's not possible to get at it again. -- --Andrew Koenig ark@europa.att.com -- ------------------------------------------------------------------- Dave Steinhoff Applied Dynamics, Int'l des@amara.UUCP 3800 Stone School Rd. des@adi.com Ann Arbor, Mi 48108 ...uunet!amara!des (313)973-1300 -------------------------------------------------------------------
des@adi.com (Dave Steinhoff) (11/17/90)
OOPS! My message had extra stuff appended. Stan's message ends with his signature. I apologize for any wasted bandwidth. Dave -- ------------------------------------------------------------------- Dave Steinhoff Applied Dynamics, Int'l des@amara.UUCP 3800 Stone School Rd. des@adi.com Ann Arbor, Mi 48108 ...uunet!amara!des (313)973-1300 -------------------------------------------------------------------
philip@pescadero.Stanford.EDU (Philip Machanick) (11/17/90)
In article <DES.90Nov16111839@minnow.adi.com>, des@adi.com (Dave Steinhoff) writes: |> |> news@travis.csd.harris.com asks: |> > Does someone have a list of errata for Lippman's "A C++ Primer"? |> > If so, could they e-mail it to me at `brad@ssd.csd.harris.com' |> > (or post it here)? I would me much obliged. |> |> I picked this up from the net way back. Enjoy. |> |> From: stan@kaiser.UUCP (s Lippman) |> Newsgroups: comp.lang.c++ |> Subject: errata in C++ Primer |> Date: 19 Jun 89 16:15:16 GMT In my copy - reprinted with corrections, July 1989 - all the items mentioned are fixed. One more (trivial) error - the index (p. 453) lists !! logical OR operator (instead of ||). -- Philip Machanick philip@pescadero.stanford.edu
brad@SSD.CSD.HARRIS.COM (Brad Appleton) (11/20/90)
In article <DES.90Nov16111839@minnow.adi.com> des@adi.com (Dave Steinhoff) writes: > > news@travis.csd.harris.com asks: >> Does someone have a list of errata for Lippman's "A C++ Primer"? >> If so, could they e-mail it to me at `brad@ssd.csd.harris.com' >> (or post it here)? I would me much obliged. > >I picked this up from the net way back. Enjoy. > Well, since my original post I have recieved loads of e-mail asking me to post such I list if I received it. I have not recieved it. The posting quoted above had some useful information regarding various revisions but is still not an errata listing (of typos and other misinformation in LippMan's Text). I have sent e-mail directly to the author asking for such a list to be posted but I have no knowledge of its receipt by the author. IMHO, It has become increasingly clear however that such an "errata list" is NOT currently available. On a longshot - I was wondering if perhaps various readers of both Lippman's text and of this newsgroup have their own personal(but not exhaustive) lists of errors they have found. If such folks would be willing to e-mail their lists to me at `brad@ssd.csd.harris.com' I would be willing to attempt to make one list out of the whole mess and post it back to this newsgroup (unless of course a complete errata list is posted before then ;-) Thank you all for your time. ______________________ "And miles to go before I sleep." ______________________ Brad Appleton brad@ssd.csd.harris.com Harris Computer Systems uunet!hcx1!brad Fort Lauderdale, FL USA ~~~~~~~~~~~~~~~~~~~~ Disclaimer: I said it, not my company! ~~~~~~~~~~~~~~~~~~~
cline@cheetah.ece.clarkson.edu (Marshall Cline) (11/21/90)
In article <1570@travis.csd.harris.com> brad@SSD.CSD.HARRIS.COM (Brad Appleton) writes: >On a longshot - I was wondering if perhaps various readers of both Lippman's >text and of this newsgroup have their own personal(but not exhaustive) lists >of errors they have found. Stan Lippman posted this to comp.lang.c++ early this summer. I believe his book's recent printings don't contain some of these errors, however, so this list may be hopelessly out-of-date. Enjoy! Marshall Cline _____________________________________________________________________________ From: stan@kaiser.UUCP (s Lippman) Newsgroups: comp.lang.c++ Subject: Errata in C++ Primer Date: 19 Jun 89 16:15:16 GMT Organization: AT&T Bell Laboratories, Liberty Corner My ``C++ Primer'' is based on a draft of Bjarne's C++ Reference Manual (and matching in-house pre- release versions Release 2.0). Subsequent to the delivery of the manuscript a review of the language definition resulted in a few modifications. This impacts the book as follows: p.24 : the keyword ``handle'' is now replaced with ``catch'' (also page 430). p.40 : named enumerations now define unique integral types. For example: enum TestStatus { NOT_RUN=-1, FAIL, PASS }; enum Boolean { FALSE, TRUE }; main() { TestStatus test = NOT_RUN; Boolean found = FALSE; test = -1; // error: TestStatus = int test = 10; // error: TestStatus = int test = found; // error: TestStatus = Boolean test = FALSE; // error: TestStatus = const Boolean int st = test; // ok: implicit conversion } For compatibility, the cfront 2.0 issues warnings rather than errors. p. 159: Overloaded functions can now be distinquished by args of enum types: enum Bool { FALSE, TRUE } found; enum Stat { FAIL, PASS }; extern void ff( Bool ); extern void ff( Stat ); extern void ff( int ); ff( PASS ); // ff( Stat ) ff( 0 ); // ff( int ) ff( found ); // ff( Bool ) p. 264-265: Class instances of operator new and operator delete should define arguments of type ``size_t'' rather than of type long. As Andy Koenig pointed out, the current 2.0 implementation accepts the long argument and replaces it with that of size_t. The class instance of operator delete must return void. (There was a brief window when it was permitted to define an arbitrary return type -- this section was completed during this window.) p. 354: A virtual function invoked within either constructors OR destructor of a base class is resolved statically to the instance defined by the base class. (Thanks to Andy Koenig for pointing the destructor case.) These corrections will be reflected in a subsequent reprinting of the book. Stan Lippman AT&T Bell Laboratories _____________________________________________________________________________ -- PS: If your company is interested in on-site C++/OOD training, drop me a line! PPS: Career search in progress; ECE faculty; research oriented; will send vita. -- Marshall Cline / Asst.Prof / ECE Dept / Clarkson Univ / Potsdam, NY 13676 cline@sun.soe.clarkson.edu / Bitnet:BH0W@CLUTX / uunet!clutx.clarkson.edu!bh0w Voice: 315-268-3868 / Secretary: 315-268-6511 / FAX: 315-268-7600