simple class

Discussion in 'C++' started by nvangogh, May 9, 2014.

  1. nvangogh

    nvangogh Guest

    Hi,
    I am reading c++ primer.

    Exercise 7.4:
    Write a class named person that represents the name and address of a
    person. Use a string to hold each of these elements. Subsequent
    exercises will incrementally add features to this class.

    Exercise 7.5:
    Provide operations in your person class to return the name and address.
    Should these functions be const? Explain your choice.

    So I have completed exercise 7.5 in this way:

    // a class named person with operations

    #include <string>

    class Person
    {
    std::string name() const { return first_name;}
    std::string addr() const { return address;}

    // data members
    std::string first_name;
    std::string address;
    };

    Is this correct?
     
    nvangogh, May 9, 2014
    #1
    1. Advertisements

  2. nvangogh

    nvangogh Guest

    On 09/05/14 14:53, nvangogh wrote:
    > Hi,
    > I am reading c++ primer.
    >
    > Exercise 7.4:
    > Write a class named person that represents the name and address of a
    > person. Use a string to hold each of these elements. Subsequent
    > exercises will incrementally add features to this class.
    >
    > Exercise 7.5:
    > Provide operations in your person class to return the name and address.
    > Should these functions be const? Explain your choice.
    >
    > So I have completed exercise 7.5 in this way:
    >
    > // a class named person with operations
    >
    > #include <string>
    >
    > class Person
    > {
    > std::string name() const { return first_name;}
    > std::string addr() const { return address;}
    >
    > // data members
    > std::string first_name;
    > std::string address;
    > };
    >
    > Is this correct?
    >

    Also what would the constructors for this class look like?
     
    nvangogh, May 9, 2014
    #2
    1. Advertisements

  3. On 5/9/2014 10:02 AM, nvangogh wrote:
    > On 09/05/14 14:53, nvangogh wrote:
    >> Hi,
    >> I am reading c++ primer.
    >>
    >> Exercise 7.4:
    >> Write a class named person that represents the name and address of a
    >> person. Use a string to hold each of these elements. Subsequent
    >> exercises will incrementally add features to this class.
    >>
    >> Exercise 7.5:
    >> Provide operations in your person class to return the name and address.
    >> Should these functions be const? Explain your choice.
    >>
    >> So I have completed exercise 7.5 in this way:
    >>
    >> // a class named person with operations
    >>
    >> #include <string>
    >>
    >> class Person
    >> {
    >> std::string name() const { return first_name;}
    >> std::string addr() const { return address;}
    >>
    >> // data members
    >> std::string first_name;
    >> std::string address;
    >> };
    >>
    >> Is this correct?
    >>

    > Also what would the constructors for this class look like?


    Consider "Subsequent exercises will incrementally add features...", and
    you might find out [later] how the class is to be used, which will
    suggest the interface for constructing objects of that class.

    The common approach is to provide a constructor that takes two
    arguments, each a ref to a const std::string, from which the respective
    data member shall be constructed.

    *Similar* to a point in two dimensions:

    class Point {
    ...
    Point(double x, double y) : mem_x(x), mem_y(y) {}
    ...
    };

    (note that the Point c-tor's args are passed by value).

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, May 9, 2014
    #3
  4. nvangogh

    Osmium Guest

    "nvangogh" wrote:

    > I am reading c++ primer.
    >
    > Exercise 7.4:
    > Write a class named person that represents the name and address of a
    > person. Use a string to hold each of these elements. Subsequent exercises
    > will incrementally add features to this class.
    >
    > Exercise 7.5:
    > Provide operations in your person class to return the name and address.
    > Should these functions be const? Explain your choice.
    >
    > So I have completed exercise 7.5 in this way:
    >
    > // a class named person with operations
    >
    > #include <string>
    >
    > class Person
    > {
    > std::string name() const { return first_name;}
    > std::string addr() const { return address;}
    >
    > // data members
    > std::string first_name;
    > std::string address;
    > };
    >
    > Is this correct?


    I don't think so. The intent was to have the functions be public, the data
    be private. The default is private so an "outsider" can not use the
    functions.

    As to the first name - I would use the full name. You might want to skim
    ahead and see where the author is going with this. First name sounds almost
    useless.

    Note that "c++ primer" does not identify a book, you need the author's name
    too.
     
    Osmium, May 9, 2014
    #4
  5. On 5/9/2014 4:20 PM, Martijn Lievaart wrote:
    > On Fri, 09 May 2014 14:53:51 +0100, nvangogh wrote:
    >
    >> Hi,
    >> I am reading c++ primer.
    >>
    >> Exercise 7.4:
    >> Write a class named person that represents the name and address of a
    >> person. Use a string to hold each of these elements. Subsequent
    >> exercises will incrementally add features to this class.
    >>
    >> Exercise 7.5:
    >> Provide operations in your person class to return the name and address.
    >> Should these functions be const? Explain your choice.
    >>
    >> So I have completed exercise 7.5 in this way:
    >>
    >> // a class named person with operations
    >>
    >> #include <string>
    >>
    >> class Person {
    >> std::string name() const { return first_name;}
    >> std::string addr() const { return address;}
    >>
    >> // data members
    >> std::string first_name;
    >> std::string address;
    >> };
    >>
    >> Is this correct?

    >
    > I would do something like this:
    >
    > class Person
    > {
    > public:
    > std::string get_name() const { return name; }


    ... { return name_; }

    > std::string get_addres() const { return address; }


    ... { return address_; }

    ;-)

    >
    > private:
    > // data members
    > std::string name_;
    > std::string address_;
    >
    > Then, and I think this will be the subsequent exercises, I would provide
    > a constructor and setters:
    >
    > public:
    > Person(const std::string &n, const std::string &a)
    > : address_(a), name_(n)
    > {
    > }
    > void set_name(const std::string &n) { name_ = n; }
    > void set_addres(const std::string &a) { address_ = a; }
    > }
    >
    > M4
    >


    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, May 9, 2014
    #5
  6. nvangogh

    Stefan Ram Guest

    nvangogh <> writes:
    >Write a class named person that represents the name and address of a
    >person. Use a string to hold each of these elements. Subsequent
    >exercises will incrementally add features to this class.


    This is asking for static fields. Otherwise, the wording would
    have to be:

    »Write a class named person /whose instances/ represent
    the name and address ...«.

    It is a common error of beginners not to properly
    distinguish between classes and objects.

    >Provide operations in your person class to return the name and address.


    What's an »operation«? Are there any differences to »function«?
     
    Stefan Ram, May 9, 2014
    #6
  7. nvangogh

    Osmium Guest

    "Stefan Ram" wrote:

    > nvangogh <> writes:
    >>Write a class named person that represents the name and address of a
    >>person. Use a string to hold each of these elements. Subsequent
    >>exercises will incrementally add features to this class.

    >
    > This is asking for static fields. Otherwise, the wording would
    > have to be:
    >
    > »Write a class named person /whose instances/ represent
    > the name and address ...«.
    >
    > It is a common error of beginners not to properly
    > distinguish between classes and objects.
    >
    >>Provide operations in your person class to return the name and address.

    >
    > What's an »operation«? Are there any differences to »function«?


    The book author sounds like one of those nasty real world people. Probably
    has germs too ...
     
    Osmium, May 10, 2014
    #7
  8. On 2014-05-09 06:53, nvangogh wrote:
    >
    > // a class named person with operations
    >
    > #include <string>
    >
    > class Person
    > {
    > std::string name() const { return first_name;}
    > std::string addr() const { return address;}
    >
    > // data members
    > std::string first_name;
    > std::string address;
    > };


    I understand that the exercise was to write something similar to this,
    and that features will be added later, but I cannot help wondering
    what this class, which has a data member and an inspector function
    (and will probably also need a setter function) for each "property",
    buys over a simple struct:

    struct Person
    {
    std::string name;
    std::string address;
    };

    I see so many examples like this which I think are stupid, and I
    believe examples should be more realistic and interesting in terms
    of using language features for solving actual problems (e.g. using
    encapsulation facilities to enforce class invariants), not just
    for the sake of using the features.

    --
    Seungbeom Kim
     
    Seungbeom Kim, May 10, 2014
    #8
  9. nvangogh

    Jorgen Grahn Guest

    On Fri, 2014-05-09, Stefan Ram wrote:
    > nvangogh <> writes:
    >>Write a class named person that represents the name and address of a
    >>person. Use a string to hold each of these elements. Subsequent
    >>exercises will incrementally add features to this class.

    >
    > This is asking for static fields. Otherwise, the wording would
    > have to be:
    >
    > »Write a class named person /whose instances/ represent
    > the name and address ...«.


    That's way too pedantic, IMO. The class exists so we can talk about
    these hundreds or millions of person objects as a group, and then it
    seems wasteful to pretend we can't talk about the class -- only about
    the set of instances of the class. The set of instances /is/ the
    class.

    I'm pleasantly surprised that the exercise uses the word "represents",
    i.e. starts by outlining the /meaning/ of the class. It's not obvious
    that a "person" is a name and address rather than a SSN and shoe size
    number, or 46 cromosomes, or whatever.

    > It is a common error of beginners not to properly
    > distinguish between classes and objects.


    I'm often annoyed and/or confused when people mix up that terminology
    (e.g. say "class" but really talk about a specific object) but this is
    not one of those cases.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, May 10, 2014
    #9
  10. Jorgen Grahn schreef op 10-May-14 2:52 PM:
    > On Fri, 2014-05-09, Stefan Ram wrote:
    >> nvangogh <> writes:
    >>> Write a class named person that represents the name and address of a
    >>> person. Use a string to hold each of these elements. Subsequent
    >>> exercises will incrementally add features to this class.

    >>
    >> This is asking for static fields. Otherwise, the wording would
    >> have to be:
    >>
    >> »Write a class named person /whose instances/ represent
    >> the name and address ...«.

    >
    > That's way too pedantic, IMO. The class exists so we can talk about
    > these hundreds or millions of person objects as a group, and then it
    > seems wasteful to pretend we can't talk about the class -- only about
    > the set of instances of the class. The set of instances /is/ the
    > class.


    I totally agree. Some common sense is always required to read a text.

    On the other hand... I use a programming style where (templatized)
    classes are used to create (compile time) polymorphism. (No objects are
    ever created.) Is there a short way to express this? "this class
    represents a serial channel" could easily be misinterpred as "an
    instance of this class ... ".

    Wouter van Ooijen
     
    Wouter van Ooijen, May 10, 2014
    #10
  11. nvangogh

    Stefan Ram Guest

    Wouter van Ooijen <> writes:
    >On the other hand... I use a programming style where (templatized)
    >classes are used to create (compile time) polymorphism. (No objects are
    >ever created.) Is there a short way to express this? "this class
    >represents a serial channel" could easily be misinterpred as "an
    >instance of this class ... ".


    In C++, the word »class« can never be interpreted as meaning
    »an instance of a class« by any reader sane in his mind.

    With the first iconsistent use of terminology, the chain is
    forged. The first speech crippled...the first thought
    mangled...the first expression denied - chains us all,
    irrevocably.
     
    Stefan Ram, May 10, 2014
    #11
  12. nvangogh

    Stefan Ram Guest

    David Harmon <> writes:
    >On 10 May 2014 15:30:14 GMT in comp.lang.c++, -berlin.de
    >(Stefan Ram) wrote,
    >>In C++, the word »class« can never be interpreted as meaning
    >>»an instance of a class« by any reader sane in his mind.

    >In my more lucid moments I might like to agree with you;
    >nevertheless, that train has left the station. It was already gone
    >when people were talking about passing structs to functions.


    In N3797, the word »struct« is used rarely in the English
    text, at one place »a struct type« is used. But, in the case
    of C++, what is most important is given in an appendix of
    N3797 (C1.2 3.3): »a struct is a class«.

    So, when someone speaks of »passing structs to functions«,
    this reminds me more of C than of C++. N1570 takes care to
    use the terms »structure type« and »structure object«
    instead of just »struct«.

    In colloquial speech some people indeed omit determinata,
    they say »My Internet is slow.« instead of »My Internet
    /connection/ is slow.« But when teaching to beginners and
    writing assignments, it is more safe to err on the side of
    clearness.
     
    Stefan Ram, May 10, 2014
    #12
  13. nvangogh

    Stefan Ram Guest

    -berlin.de (Stefan Ram) writes:
    >In colloquial speech some people indeed omit determinata,


    Speech wants to be efficient. So when an isolated word is
    ambiguous, this can still be healed by context.

    When one says: »I am passing this struct to the function.«,
    does he mean »structure type« or »structure object«?
    A structure type cannot be passed to a function, so we can
    safely conclude that he must mean »structure object«.
    Thus, while »struct« is ambiguous in isolation, it is not
    ambiguous in the context just given.

    But now let's have a look at

    |Write a class named person that represents the name and
    |address of a person.

    . Is »class« »class type« or »class instance« here? In this
    case, both interpretations are possible. For example, we
    already know the class »::string« that represents
    information about the implementation used by providing us
    with /static/ fields such as »::string::npos«. Therefore, in
    this case, the context does not help to resolve the
    ambiguity.

    Also, one noun in a phrase cannot mean both »class« and
    »class instance« at the same time. The author writes

    |class named person

    . Here, he does not seem to want to say that a class
    /instance/ should be named »person«, but the class itself
    should be named »person«. Thus, by the use of this noun
    phrase, the meaning of the word »class« in this sentence is
    already determined by context and it cannot be read to have
    another meaning later.
     
    Stefan Ram, May 10, 2014
    #13
  14. nvangogh

    Stefan Ram Guest

    David Harmon <> writes:
    >if it can only mean "class type" when context makes it pretty
    >evident that he intends "class instance".


    So, you read

    |Write a class named person

    as

    |Write a class instance named person

    ?
     
    Stefan Ram, May 10, 2014
    #14
  15. nvangogh

    Osmium Guest

    "Stefan Ram" wrote:

    > But when teaching to beginners and
    > writing assignments, it is more safe to err on the side of
    > clearness.


    It is always more better to write with a lot of clearness.
     
    Osmium, May 10, 2014
    #15
  16. nvangogh

    Stefan Ram Guest

    Vir Campestris <> writes:
    >One of the nice things about accessors, not just publicising the data,
    >is that you are hiding the implementation.


    I doubt this.

    Say, we have a bank account with an interface:

    public: double getBalance();

    and a field:

    private: double balance;

    . Then, problems with »double« are observed, and the
    programmer of the account class is asked to change this.
    His first change is:

    private: ::example::library::fixeddecimal balance;

    . But the problems with double values are still being
    observed, because the interface still is:

    public: double getBalance();

    . So eventually, he is forced to change the interface too:

    public: ::example::library::fixeddecimal getBalance();

    . Now, where is the hiding of the implementation?
     
    Stefan Ram, May 11, 2014
    #16
  17. nvangogh

    Osmium Guest

    "Seungbeom Kim" wrote:

    > On 2014-05-09 06:53, nvangogh wrote:
    >>
    >> // a class named person with operations
    >>
    >> #include <string>
    >>
    >> class Person
    >> {
    >> std::string name() const { return first_name;}
    >> std::string addr() const { return address;}
    >>
    >> // data members
    >> std::string first_name;
    >> std::string address;
    >> };

    >
    > I understand that the exercise was to write something similar to this,
    > and that features will be added later, but I cannot help wondering
    > what this class, which has a data member and an inspector function
    > (and will probably also need a setter function) for each "property",
    > buys over a simple struct:
    >
    > struct Person
    > {
    > std::string name;
    > std::string address;
    > };
    >
    > I see so many examples like this which I think are stupid, and I
    > believe examples should be more realistic and interesting in terms
    > of using language features for solving actual problems (e.g. using
    > encapsulation facilities to enforce class invariants), not just
    > for the sake of using the features.


    I agree, it would be nice to have more appealing examples but I have yet to
    see an example that was simple enough for a student and at the same time
    meaningful. Some things just have to be bought on faith.

    For those with some programming background but new to C++ I feel there is a
    sense of security when debugging. The constant thought in the back of your
    mind that someone (perhaps your own code) is munging your data. The chances
    of accidental munging in C++ are pretty remote; this means you can focus on
    the problem at hand.
     
    Osmium, May 11, 2014
    #17
  18. nvangogh

    Stefan Ram Guest

    Paavo Helde <> writes:
    >Err, no. If the ultimate goal is to keep interfaces fixed, then
    >getBalance() would still return double for back-compatibility (and marked
    >deprecated in the documentation and/or by the relevant compiler-specific
    >extensions) and there would be a new function getBalanceEx() returning a
    >fixed decimal.


    But the effect is the same: all clients that want to benefit
    from the new implementation have to be changed. I used to
    believe that the promise of encapsulation was that the
    implementation can be changed without the clients having to
    be changed.
     
    Stefan Ram, May 11, 2014
    #18
  19. nvangogh

    Jorgen Grahn Guest

    On Sun, 2014-05-11, Vir Campestris wrote:
    > On 10/05/2014 06:38, Seungbeom Kim wrote:
    >> I understand that the exercise was to write something similar to this,
    >> and that features will be added later, but I cannot help wondering
    >> what this class, which has a data member and an inspector function
    >> (and will probably also need a setter function) for each "property",
    >> buys over a simple struct:
    >>
    >> struct Person
    >> {
    >> std::string name;
    >> std::string address;
    >> };
    >>
    >> I see so many examples like this which I think are stupid, and I
    >> believe examples should be more realistic and interesting in terms
    >> of using language features for solving actual problems (e.g. using
    >> encapsulation facilities to enforce class invariants), not just
    >> for the sake of using the features.

    >
    > One of the nice things about accessors, not just publicising the data,
    > is that you are hiding the implementation.
    >
    > Imagine that I've decided to compress the data. Everyone whose name is
    > Wong will be described by having an ID of 1, everybody whose name is
    > Smith by 2, and so on.
    >
    > If you've publicised the data you can't do this. If you've publicised a
    > method returning a const reference to the string you can.


    That's the traditional argument for set/get functions.

    But let's face it: in 99 cases out of 100 you're in control over the
    client code. Then if you can no longer expose the member, you just
    make it private, implement get() and fix up the calling code (which
    now fails to compile).

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, May 11, 2014
    #19
  20. nvangogh

    Jorgen Grahn Guest

    On Sun, 2014-05-11, Osmium wrote:
    > "Seungbeom Kim" wrote:

    ....
    >> I understand that the exercise was to write something similar to this,
    >> and that features will be added later, but I cannot help wondering
    >> what this class, which has a data member and an inspector function
    >> (and will probably also need a setter function) for each "property",
    >> buys over a simple struct:
    >>
    >> struct Person
    >> {
    >> std::string name;
    >> std::string address;
    >> };
    >>
    >> I see so many examples like this which I think are stupid, and I
    >> believe examples should be more realistic and interesting in terms
    >> of using language features for solving actual problems (e.g. using
    >> encapsulation facilities to enforce class invariants), not just
    >> for the sake of using the features.

    >
    > I agree, it would be nice to have more appealing examples but I have yet to
    > see an example that was simple enough for a student and at the same time
    > meaningful. Some things just have to be bought on faith.


    It's not hard.

    All that's needed here is an example where there's a relationship
    between the members. Stroustrup picked (in TC++PL) a Date class with
    year, month and day-of-month. Then you eventually want to prevent
    things like the 31th of February year 0, and there's suddenly a real
    reason to have more than just a boring struct.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, May 11, 2014
    #20
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. cyril
    Replies:
    2
    Views:
    4,544
    cyril
    Aug 25, 2004
  2. Loic
    Replies:
    2
    Views:
    707
    Johan Poppe
    Nov 26, 2004
  3. Purush
    Replies:
    4
    Views:
    2,859
    Purush Rudrakshala
    Apr 13, 2005
  4. E11
    Replies:
    1
    Views:
    5,904
    Thomas Weidenfeller
    Oct 12, 2005
  5. christopher diggins
    Replies:
    16
    Views:
    1,096
    Pete Becker
    May 4, 2005
  6. Joseph Turian
    Replies:
    5
    Views:
    934
  7. Christian Maier
    Replies:
    3
    Views:
    669
    John Harrison
    Feb 15, 2007
  8. chandan
    Replies:
    2
    Views:
    948
    chandan
    Dec 3, 2007
Loading...