EACONS@MTUS5.BITNET (Ernie Anderson) (10/08/90)
Hello all...
I'm trying to pound the fundamentals of C++ through my thick skull,
and I've run into a stumper. In "Programming in C++" by Dewhurst and
Stark in chapter 3 where they introduce their brain-dead example string
class, I have a question. The code in question is
#include <stdio.h>
#include <string.h>
class String {
char *str;
public:
String() {str = new char[1]; *str = 0; }
String(char *);
void print() {printf(" %s", str); }
...
};
Then later they do something like:
String a;
...
a = String (buffer);
Now when a was declared, a single character of storage was allocated, right?
and when buffer was converted to a String and assigned to a, the value of
str in that temporary instance for buffer was copied to a's str, right? So
isn't the byte of storage allocated by declaring a lost?
Please either confirm this, or tell me where I'm going wrong...
Ernest J. Anderson
eacons@mtus5.cts.mtu.edu, eacons@mtus5.bitnet, ejanders@symmetry.cs.mtu.eduEACONS@MTUS5.BITNET (Ernie Anderson) (10/11/90)
Thanks to all who responded by email to my question. The message I heard over and over was about the = operator being overloaded to take care of deallocating the memory. That is what I had been thinking, but the book's example did not redefine it. I'm relieved that I wasn't just being paranoid. I'm a little disappointed with the text, they shouldn't have done something as negligent as that, even for an example. At least they could have put a note afterward pointing out the flaw. Anyway, I'll shelve that one for now and just work with my Lippman text. Thanks again everyone. Ernie EACONS at MTUS5(bitnet), EACONS@mtus5.cts.mtu.edu, ejanders@symmetry.cs.mtu.edu
roger@zuken.co.jp (Roger Meunier) (10/12/90)
In article <90281.014850EACONS@MTUS5.BITNET> EACONS@MTUS5.BITNET (Ernie Anderson) writes: > String a; > ... > a = String (buffer); > > Now when a was declared, a single character of storage was allocated, right? > and when buffer was converted to a String and assigned to a, the value of > str in that temporary instance for buffer was copied to a's str, right? So > isn't the byte of storage allocated by declaring a lost? I don't have a copy of the book which contains the example, but I would assume that within the portion of the class declaration of String which you abreviated, the equals (=) operator has been redefined. I would also assume that said redefinition included the deletion of the old string contents and then a copying of the pointer given as the rhs of the operator to the lhs instance. In the above example, the rhs is probably an implicitly defined (auto) instance of String which contains a pointer to a copy of buffer. Just a guess... -- Roger Meunier @ Zuken, Inc. Yokohama, Japan (roger@zuken.co.jp)
weh@dryer.ATT.COM (XGPB30000-HopkinsWE(DR9274)237) (10/12/90)
From article <90284.103929EACONS@MTUS5.BITNET>, by EACONS@MTUS5.BITNET (Ernie Anderson): > Thanks to all who responded by email to my question. The message I heard > over and over was about the = operator being overloaded to take care of > deallocating the memory. That is what I had been thinking, but the book's > example did not redefine it. I'm relieved that I wasn't just being paranoid. > I'm a little disappointed with the text, they shouldn't have done something > as negligent as that, even for an example. At least they could have put a > note afterward pointing out the flaw. Anyway, I'll shelve that one for now > and just work with my Lippman text. Thanks again everyone. My original response must have been lost. You shouldn't be disappointed with the Dewhurst and Stark book because they *did* overload operator = in chapter 4 (section 4.2 titled ``Strings'', pg. 80, first printing). I surmise that they did not include the overloaded = in the previous chapter to simplify the initial presentation of a String class. The more refined example in chapter 4 includes the use of a separate representation class and reference counting. It seems that to shelve a book because an example didn't do all it should have is a bit rash. In this case, it is a matter of the authors refining a example as they build up familiarity with the concepts. Dewhurst and Stark's book has the nice property of giving a relatively quick and practical introduction to the features (and the use thereof) that C++ introduced in addition to what was already part of C. Lippman's book is a more comprehensive text, taking the reader from ground zero to multiple inheritance and pointers to members. The details are carefully explained and illustrated. Both are excellent books but with different purposes. Bill Hopkins AT&T Bell Labs 11900 N. Pecos St. Denver, CO 80234 w.e.hopkins@att.com