C++ Primer ex 6.20

Discussion in 'C++' started by arnuld, Aug 6, 2007.

  1. arnuld

    arnuld Guest

    it works fine. i am posting it to know your views (please remember, i am
    at chapter 6, so i have not encountered stuf like Functions):

    /* C++ Primer - 4/e
    *
    * exercise 6.20
    * STATEMENT
    * write a programme to rad a sequence of strings from standard
    input until either the same word occurs twice in succession or all the
    words have been read. use the while loop to read a word at a time. use
    the break statement to terminate the loop if awords occurs twice in
    succession & print that word or else print the message that no word was
    repeated.
    *
    */


    #include <iostream>
    #include <string>

    int main()
    {
    std::string cstr, pstr;
    bool same_str = false;

    while(std::cin >> cstr)
    {
    if(cstr == pstr)
    {
    same_str = true;
    break;
    }

    pstr = cstr;
    }


    if(same_str)
    {
    std::cout << "\n'"
    << cstr
    << "' was repeated\n";
    }
    else
    {
    std::cout << "\nno word was repeated\n";
    }

    return 0;
    }



    --
    http://arnuld.blogspot.com
    arnuld, Aug 6, 2007
    #1
    1. Advertising

  2. arnuld

    Barry Guest

    arnuld wrote:
    > it works fine. i am posting it to know your views (please remember, i am
    > at chapter 6, so i have not encountered stuf like Functions):


    So, what's the point?
    Barry, Aug 6, 2007
    #2
    1. Advertising

  3. arnuld

    Jim Langston Guest

    "arnuld" <> wrote in message
    news:p...
    > it works fine. i am posting it to know your views (please remember, i am
    > at chapter 6, so i have not encountered stuf like Functions):
    >
    > /* C++ Primer - 4/e
    > *
    > * exercise 6.20
    > * STATEMENT
    > * write a programme to rad a sequence of strings from standard
    > input until either the same word occurs twice in succession or all the
    > words have been read. use the while loop to read a word at a time. use
    > the break statement to terminate the loop if awords occurs twice in
    > succession & print that word or else print the message that no word was
    > repeated.
    > *
    > */
    >


    Personally, I'm not in favor of the break statement when other methods can
    be easily used. I would rather do (untested code)

    > #include <iostream>
    > #include <string>
    >
    > int main()
    > {
    > std::string cstr, pstr;
    > bool same_str = false;
    >

    while(! same_str && std::cin >> cstr)
    > {
    > if(cstr == pstr)
    > same_str = true;
    > pstr = cstr;
    > }
    >
    >
    > if(same_str)
    > std::cout << "\n'" << cstr << "' was repeated\n";
    > else
    > std::cout << "\nno word was repeated\n";
    >
    > return 0;
    > }
    >
    >
    >
    > --
    > http://arnuld.blogspot.com
    >
    Jim Langston, Aug 6, 2007
    #3
  4. On 2007-08-06 10:29, Barry wrote:
    > arnuld wrote:
    >> it works fine. i am posting it to know your views (please remember, i am
    >> at chapter 6, so i have not encountered stuf like Functions):

    >
    > So, what's the point?


    Point of what?

    --
    Erik Wikström
    =?ISO-8859-1?Q?Erik_Wikstr=F6m?=, Aug 6, 2007
    #4
  5. arnuld

    arnuld Guest

    > On Aug 6, 1:43 pm, "Jim Langston" <> wrote:
    > Personally, I'm not in favor of the break statement when other methods can
    > be easily used. I would rather do (untested code)


    > while(! same_str && std::cin >> cstr)


    thanks, i will use it :)


    -- arnuld
    http://arnuld.blogspot.com
    arnuld, Aug 6, 2007
    #5
  6. arnuld

    Guest

    On Aug 6, 2:04 am, arnuld <> wrote:
    > > On Aug 6, 1:43 pm, "Jim Langston" <> wrote:
    > > Personally, I'm not in favor of the break statement when other methods can
    > > be easily used. I would rather do (untested code)
    > > while(! same_str && std::cin >> cstr)

    >
    > thanks, i will use it :)
    >
    > -- arnuldhttp://arnuld.blogspot.com


    I'm not a fan of unnecessary state variables (same_str) which can be
    handled by logic in the code instead.

    You can also omit the "return 0;" in C++.

    So I propose the following version of your code:

    #include <iostream>
    #include <string>

    int main()
    {
    std::string cstr, pstr;

    while( std::cin >> cstr && pstr != cstr )
    {
    pstr = cstr;
    cstr = "";
    }

    if( cstr != "" )
    std::cout << "\n'" << cstr << "' was repeated\n";
    else
    std::cout << "\nno word was repeated\n";
    }

    Cheers,
    Andre
    , Aug 6, 2007
    #6
  7. arnuld

    BobR Guest

    <> wrote in message...
    >
    > You can also omit the "return 0;" in C++.


    BUT, why would you want to?

    Lazy?

    --
    Bob R
    POVrookie
    BobR, Aug 6, 2007
    #7
  8. BobR wrote:
    > <> wrote in message...
    >>
    >> You can also omit the "return 0;" in C++.

    >
    > BUT, why would you want to?
    >
    > Lazy?


    <shrug> I don't understand the desire to label somebody right away
    with a negative epithet. Every use of a member name in a non-static
    member function _can_ be preceded by 'this->'. Do *you* do that?
    I don't think so. Why? Lazy? It's unnecessary in *most* cases.

    Same here. It's unnecessary to spell out "return 0;". What do you
    *gain* (except more typing exercise for your hands) when you spell
    it out?

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Aug 6, 2007
    #8
  9. arnuld

    werasm Guest

    Jim Langston wrote:

    > Personally, I'm not in favor of the break statement when other methods can
    > be easily used. I would rather do (untested code)


    [snip]

    > while(! same_str && std::cin >> cstr)
    > > {
    > > if(cstr == pstr)
    > > same_str = true;
    > > pstr = cstr;
    > > }



    This causes one unnecessary string assignment, even
    though the strings already tested equal. IMO this could
    be regarded as pessimizing prematurely (for the sake
    of not using a break?). It also causes additional an
    comparison. If you did not want to break, the least
    you could have done is continue after the if( cstr == pstr ).
    Matter of style: Using no braces after if is often a source
    of error.
    werasm, Aug 6, 2007
    #9
  10. arnuld

    James Kanze Guest

    On Aug 6, 8:36 pm, "" <> wrote:
    > On Aug 6, 2:04 am, arnuld <> wrote:


    > > > On Aug 6, 1:43 pm, "Jim Langston" <> wrote:
    > > > Personally, I'm not in favor of the break statement when other methods can
    > > > be easily used. I would rather do (untested code)
    > > > while(! same_str && std::cin >> cstr)


    > > thanks, i will use it :)


    > I'm not a fan of unnecessary state variables (same_str) which can be
    > handled by logic in the code instead.


    > You can also omit the "return 0;" in C++.


    You can, but not everything that you can do you should do. The
    return is good form, and I would generally criticize a
    programmer for omitting it.

    --
    James Kanze (GABI Software) email:james.kanze:gmail.com
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Aug 6, 2007
    #10
  11. arnuld

    werasm Guest

    arnuld wrote:


    > int main()
    > {
    > std::string cstr, pstr;
    > bool same_str = false;
    >
    > while(std::cin >> cstr)
    > {
    > if(cstr == pstr)
    > {
    > same_str = true;
    > break;
    > }
    >
    > pstr = cstr;
    > }
    >
    >
    > if(same_str)
    > {
    > std::cout << "\n'"
    > << cstr
    > << "' was repeated\n";
    > }
    > else
    > {
    > std::cout << "\nno word was repeated\n";
    > }
    >
    > return 0;
    > }


    As I see it, if the end of std::cin is reach (highly unlikely but
    possible
    if you associate it with a file buffer, for instance), then the
    duplicate
    consecutive words were not found (due to your break). For this reason
    the boolean same_str is unnecessary, and only serves a documenting
    purpose.

    This could have been a possible solution:

    int main()
    {
    using namespace std;

    string prev, next;
    while( cin >> next )
    {
    if( prev != next )
    {
    prev = next;
    continue;
    }
    break;
    }

    if( cin.eof() == false ) //...or if( !cin.eof() ) if you like
    {
    cout << "Word repeated was " << next;
    }
    else
    {
    cout << "No word repeated";
    }
    cout << "." << endl;
    }
    werasm, Aug 6, 2007
    #11
  12. arnuld

    BobR Guest

    Victor Bazarov <> wrote in message...
    > BobR wrote:
    > > <> wrote in message...
    > >>
    > >> You can also omit the "return 0;" in C++.

    > >
    > > BUT, why would you want to?
    > >
    > > Lazy?

    >
    > <shrug> I don't understand the desire to label somebody right away
    > with a negative epithet.


    Not epithetical, just a question.

    > Every use of a member name in a non-static
    > member function _can_ be preceded by 'this->'. Do *you* do that?


    Sometimes, yes.

    > I don't think so. Why? Lazy? It's unnecessary in *most* cases.


    And in other cases, it makes it clear enough that you don't need to write a
    long comment on it.

    >
    > Same here. It's unnecessary to spell out "return 0;". What do you
    > *gain* (except more typing exercise for your hands) when you spell
    > it out?


    So, we should put this line in the FAQ:

    "DO NOT write 'return 0;' in main()"!

    <G>

    It seems silly to tell a newbie not to do it.
    And what about old code in books/net (often posted by newbies):

    void main(){
    return 0;
    }

    Now the compiler *should* complain!
    (assume an old compiler that didn't flag the 'void'.)

    --
    Bob R
    POVrookie
    BobR, Aug 6, 2007
    #12
  13. arnuld

    BobR Guest

    Jim Langston <> wrote in message...
    >
    > "arnuld" <> wrote in message...
    > > it works fine. i am posting it to know your views (please remember, i am
    > > at chapter 6, so i have not encountered stuf like Functions):
    > >
    > > /* C++ Primer - 4/e * exercise 6.20
    > > * STATEMENT
    > > * write a programme to rad a sequence of strings from standard
    > > input until either the same word occurs twice in succession or all the
    > > words have been read. use the while loop to read a word at a time. use
    > > the break statement to terminate the loop if awords occurs twice in
    > > succession & print that word or else print the message that no word was
    > > repeated.
    > > */

    >
    > Personally, I'm not in favor of the break statement when other methods can
    > be easily used. I would rather do (untested code)


    Unfortunately, the 'break' *is in* the spec.

    >
    > > #include <iostream>
    > > #include <string>
    > >
    > > int main(){
    > > std::string cstr, pstr;
    > > bool same_str = false;


    /*
    > while(! same_str && std::cin >> cstr){
    > > if(cstr == pstr)
    > > same_str = true;
    > > pstr = cstr;
    > > }

    */
    while( ! same_str && std::cin >> cstr ){
    same_str = ( cstr == pstr );
    pstr = cstr;
    // if( same_str ){ cstr += "break;"; } // for spec :-}
    }
    // <G>
    > >
    > > if(same_str)
    > > std::cout << "\n'" << cstr << "' was repeated\n";
    > > else
    > > std::cout << "\nno word was repeated\n";
    > > return 0;
    > > }


    --
    Bob R
    POVrookie
    BobR, Aug 7, 2007
    #13
  14. arnuld

    Jim Langston Guest

    "werasm" <> wrote in message
    news:...
    >
    > Jim Langston wrote:
    >
    >> Personally, I'm not in favor of the break statement when other methods
    >> can
    >> be easily used. I would rather do (untested code)

    >
    > [snip]
    >
    >> while(! same_str && std::cin >> cstr)
    >> > {
    >> > if(cstr == pstr)
    >> > same_str = true;
    >> > pstr = cstr;
    >> > }

    >
    >
    > This causes one unnecessary string assignment, even
    > though the strings already tested equal. IMO this could
    > be regarded as pessimizing prematurely (for the sake
    > of not using a break?). It also causes additional an
    > comparison. If you did not want to break, the least
    > you could have done is continue after the if( cstr == pstr ).


    > Matter of style: Using no braces after if is often a source
    > of error.


    RE: the matter of style. I've gone back and forth on this over the years.
    I've done it so I always use brackets. I've done it so I don't use brackets
    unless I have to. I've done it where I'd use brackets if it was a function
    call, etc...

    At this point in time I'm not using brackets when not needed and in my own
    code it hasn't caused any problems of any importance (something that took me
    more than a minute or two to find and fix). But then, I've read many many
    lines of code in many many languages over the years in many formats.

    I tend to go for the white space format, I.E.

    if ( condition )
    {
    statements
    }

    rather than

    if ( condition ) {
    statements
    }

    Which may make a difference. It would be easy to miss the fact that there
    is only one statement if you are not used to seeing a bracket on the
    preceeding line.
    Jim Langston, Aug 7, 2007
    #14
  15. arnuld

    James Kanze Guest

    On Aug 6, 10:03 pm, "Victor Bazarov" <> wrote:
    > BobR wrote:
    > > <> wrote in message...


    > >> You can also omit the "return 0;" in C++.


    > > BUT, why would you want to?


    > > Lazy?


    > <shrug> I don't understand the desire to label somebody right away
    > with a negative epithet.


    There's a question mark. He's not labeling anybody. He's
    asking if that is the reason (which is, IMHO, an indirect way to
    ask whether there are any other reasons).

    > Every use of a member name in a non-static
    > member function _can_ be preceded by 'this->'. Do *you* do that?
    > I don't think so. Why? Lazy? It's unnecessary in *most* cases.


    Coherence. I never use this->. I always put a return at the
    end of a function which has a return value. Why should main be
    an exception.

    In practice, of course, I don't think I've ever written any real
    code where it was just "return 0". Any real program will have
    output somewhere, output can fail, and if the output fails, you
    don't want to return 0. You might as well get into the habit of
    writing the return, since it's going to be necessary in any
    program that is actually used.

    > Same here. It's unnecessary to spell out "return 0;". What do you
    > *gain* (except more typing exercise for your hands) when you spell
    > it out?


    Coherence. Orthogonality.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Aug 7, 2007
    #15
  16. arnuld

    James Kanze Guest

    On Aug 7, 5:32 am, "Jim Langston" <> wrote:

    [Totally changing topic, but...]
    > I tend to go for the white space format, I.E.


    > if ( condition )
    > {
    > statements
    >
    > }


    > rather than


    > if ( condition ) {
    > statements
    >
    > }


    You put a blank line before the closing brace. I've noticed
    this a lot recently (in the past year or two?), but had never
    seen it (or at least noticed it) before, and I don't do it
    myself.

    I'm curious as to why? Is it an intentional decision, or is it
    based on some tool, or what?

    > Which may make a difference. It would be easy to miss the
    > fact that there is only one statement if you are not used to
    > seeing a bracket on the preceeding line.


    Agreed. Like you, I've used different styles over time. The
    important thing is that the code has an "expected" look; if you
    change something, and that look isn't there, it strikes you
    immediately. If the rule is "a flow control statement is
    followed either by a single indented statement, or a { on a line
    by itself, not indented", then adding a second statement just
    doesn't look right unless you add the {.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Aug 7, 2007
    #16
  17. arnuld

    werasm Guest

    James Kanze wrote:


    > Agreed. Like you, I've used different styles over time. The
    > important thing is that the code has an "expected" look; if you
    > change something, and that look isn't there, it strikes you
    > immediately. If the rule is "a flow control statement is
    > followed either by a single indented statement, or a { on a line
    > by itself, not indented", then adding a second statement just
    > doesn't look right unless you add the {.


    Certain style issues don't concern me that much, such
    as brace positions and naming conventions, as long as
    consistency exists. Other style issues could lead to errors,
    and I consider lack of braces one such.

    For instance in...

    if( condition )
    doX();
    doY();

    doY() could easily be mistaken (by a quick reader) as
    part of the condition, where in this case:

    if( condition )
    { doX(); }
    doY();

    or variations therefore, the mistake is less possible.

    Werner
    werasm, Aug 7, 2007
    #17
  18. arnuld

    Richard Guest

    werasm <> writes:

    > James Kanze wrote:
    >
    >
    >> Agreed. Like you, I've used different styles over time. The
    >> important thing is that the code has an "expected" look; if you
    >> change something, and that look isn't there, it strikes you
    >> immediately. If the rule is "a flow control statement is
    >> followed either by a single indented statement, or a { on a line
    >> by itself, not indented", then adding a second statement just
    >> doesn't look right unless you add the {.

    >
    > Certain style issues don't concern me that much, such
    > as brace positions and naming conventions, as long as
    > consistency exists. Other style issues could lead to errors,
    > and I consider lack of braces one such.
    >
    > For instance in...
    >
    > if( condition )
    > doX();
    > doY();
    >
    > doY() could easily be mistaken (by a quick reader) as
    > part of the condition, where in this case:
    >
    > if( condition )
    > { doX(); }
    > doY();


    And one of the main reasons to advocate the K&R bracketing because in
    your example the brackets are easily missed, especially in longer lines.

    if (f){
    doX();
    }
    doY();

    leaves no room for confusion. Obviously the good tab lengths (Linux src
    is 8) and indenting correctly helps eliminate any issue regardless.

    >
    > or variations therefore, the mistake is less possible.
    >
    > Werner
    >


    --
    Richard, Aug 7, 2007
    #18
  19. Richard wrote:
    > [..] Obviously the good tab lengths (Linux
    > src is 8) [..]


    The "tab length" is a setting of a text editor. How can "src" have
    any "tab length"? Did you mean indentation offset in spaces? I,
    personally, hate tab characters in the source.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Aug 7, 2007
    #19
  20. * Victor Bazarov:
    > Richard wrote:
    >> [..] Obviously the good tab lengths (Linux
    >> src is 8) [..]

    >
    > The "tab length" is a setting of a text editor. How can "src" have
    > any "tab length"? Did you mean indentation offset in spaces? I,
    > personally, hate tab characters in the source.


    Bah. As long as you just remember that 1 tab = 3 spaces, it's a boon to
    productivity. I think. <g>

    Seriously, 4 spaces per tab is of course the only sane choice.

    Heh heh...

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Aug 7, 2007
    #20
    1. Advertising

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. Richard

    SSL / authentication primer

    Richard, Jul 25, 2003, in forum: Java
    Replies:
    2
    Views:
    482
    Richard
    Jul 25, 2003
  2. Chris
    Replies:
    0
    Views:
    366
    Chris
    Apr 18, 2005
  3. Captain Dondo

    SVG primer

    Captain Dondo, Jan 21, 2006, in forum: HTML
    Replies:
    1
    Views:
    572
    Toby Inkster
    Jan 22, 2006
  4. Charles L

    'C++ Primer 2nd Ed' errata

    Charles L, Apr 11, 2004, in forum: C++
    Replies:
    2
    Views:
    363
  5. hugo
    Replies:
    1
    Views:
    358
    Ali Cehreli
    Aug 17, 2004
Loading...

Share This Page