Wrap up Text

Discussion in 'C Programming' started by FUGATO, Mar 3, 2006.

  1. FUGATO

    FUGATO Guest

    I need to help in my assignment. I need to wrap a text with the
    following indications:
    1.If you have reached the end of the line (number of characters on this
    line >= 40) AND you have reached the end of the current word, start a
    new line and reset the number of characters on the line to 0. The end
    of a word will be denoted by one of these: blank space, '\n',
    '.', ',' or ';'.

    #include <stdio.h>
    #include <ctype.h>

    main()
    {
    FILE *fp1,*fp2; //fp1 input file, fp2 output file
    char filename[30]; //filename character and x is character
    char line[80];
    char x;
    int count=0; // count the line of the file 1
    int j=0; //count of character of file 2

    printf("Enter the filename to be scanned: "); // ask the user
    scanf("%s", filename);

    fp1= fopen(filename, "r"); //open input file,read-only
    fp2= fopen("output.txt", "w"); //open outp file,write-only

    while((x=getc(fp1))!=EOF) //get next char from input file, store
    in x
    {


    if(x=='\n' || x=='*') //count the lines of the file1
    count++;


    if(x=='\n') //separete words

    putc(' ' ,fp2);

    else if(x=='*'){ //new line with an indentation \t

    putc('\t',fp2);


    }
    else if(x!='*') //delete *
    {



    j++;

    putc(x,fp2); //output file

    //Begin the Wrap up text but I have problem here. Help!!!
    if((j>=40) && (x==' ' || x==';' || x=='.' || x==',' || x=='\n'))

    do{
    putc('\n',fp2); //start new line
    count1++;
    j=0;
    }while(j!=0);
    if(x=='\n')
    putc('\n',fp2);
    }



    }
    FUGATO, Mar 3, 2006
    #1
    1. Advertising

  2. In article <>,
    FUGATO <> wrote:
    >I need to help in my assignment.


    >1.If you have reached the end of the line (number of characters on this
    >line >= 40) AND you have reached the end of the current word, start a
    >new line and reset the number of characters on the line to 0. The end
    >of a word will be denoted by one of these: blank space, '\n',
    >'.', ',' or ';'.


    >#include <stdio.h>
    >#include <ctype.h>


    >main()


    Minus 1 point for not using integer main(void)

    >{
    > FILE *fp1,*fp2; //fp1 input file, fp2 output file


    Noted: C99 style comments, not valid in C89.

    > char filename[30]; //filename character and x is character
    > char line[80];
    > char x;
    > int count=0; // count the line of the file 1
    > int j=0; //count of character of file 2
    >
    > printf("Enter the filename to be scanned: "); // ask the user


    Minus 1 point for not ending the prompt with '\n' and another for
    not using fflush() to ensure that the prompt will be displayed before the
    read.

    > scanf("%s", filename);


    Automatic 2 grade-letter deduction using scanf() to read a string you
    don't control the size of. What happens if the user enters a 35
    character filename?

    Minus 1 point for using scanf("%s") to read a filename that might
    contain a blank. The %s format skips leading whitespace, then reads
    consequative non-whitespace, stopping at the first whitespace. That's
    not going to be able to handle a filename such as

    C:\Program Files\Fugato\WordWrap.data

    > fp1= fopen(filename, "r"); //open input file,read-only


    Minus 1 point for not checking that the input file was opened properly.

    > fp2= fopen("output.txt", "w"); //open outp file,write-only


    Minus 1 point for not checking that the out file was opened properly.

    > while((x=getc(fp1))!=EOF) //get next char from input file, store


    Minus 1 point for assigning the result of getc() to a char variable
    that might be unsigned and thus not able to store a value equal to
    EOF (which is certain to be negative.)

    >in x
    > {
    >
    >
    > if(x=='\n' || x=='*') //count the lines of the file1
    > count++;


    Minus 1 point for using the magic test against '*' which is not
    documented in the requirements as being one of the special characters
    to be tested for.

    Minus 1 point for counting * as indicating the end of a line -- it
    isn't. If there was a special requirement that it be treated
    as a newline, then instead minus 1 point for not fully stating
    the requirements.

    >
    > if(x=='\n') //separete words


    Typo in comment. Noted but we'll let it go this time.

    >
    > putc(' ' ,fp2);


    Minus 1 point for bug of assuming that end of line in the
    input will always result in a space in the output file. If you've
    reached the natural end of a word and you are over the column
    limit, then there should not be a space emitted before the output
    lineline.

    > else if(x=='*'){ //new line with an indentation \t
    >
    > putc('\t',fp2);


    Minus 3 points: 1 for not adjusting the character count to take
    into account the indentation; 1 for not documenting
    what the indentation size is nor allowing the user to control
    the indentation; and 1 for outputting indentation even if there is
    no further output to go on the line (e.g., end of file.)

    >
    > }
    > else if(x!='*') //delete *


    Minus 1 point for redundant condition: if x was '\n' or '*' then
    you could not have gotten here through the chain of if/else
    so testing for non-'*' is unnecessary.

    > {
    >
    > j++;
    >
    > putc(x,fp2); //output file
    >
    >//Begin the Wrap up text but I have problem here. Help!!!
    > if((j>=40) && (x==' ' || x==';' || x=='.' || x==',' || x=='\n'))


    Minus 1 point for not recognizing that x cannot be '\n' here because
    of the if/else chains.

    >
    > do{
    > putc('\n',fp2); //start new line
    > count1++;


    Minus 3 points for using an undeclared variable (count1). This would
    not compile, so you have submitted an answer which is not the one
    you have actually run: minus 7 points for that.

    > j=0;
    > }while(j!=0);


    Minus 1 point for not recognizing that j will always be 0 after the
    do{}, so the while() condition is not useful, and the construct
    should just be replaced with a plain statement block {}.

    > if(x=='\n')


    x cannot be '\n' here, but we already docked you for that.

    > putc('\n',fp2);


    On the other hand, this would get you a double newline on output if you
    did manage to get here, so that's another logic bug and another
    point docked.
    > }


    Minus 1 point for failing to return an exit status to the
    operating system, which is recommended for C89 programs.

    Minus another point for failing to return an exit status to the
    operating system, which is mandatory for C99 programs. We know
    that you are using C99 because of the comment style. If you wish
    to claim that you should not be docked here because you are using
    C89 and returning a value is optional for C89, then you will
    instead be docked for using C99 style comments in a C89 program.


    Minus 1 point for failing to ensure that the text file fp2 ends
    in a newline.

    Minus 1 point for failing to close the input and output files.

    Minus 1 point for not using the result of counting the lines.
    If you don't use the count, then don't do the count.

    Minus 1 point for not using the declared array 'line'.
    > }


    --
    "law -- it's a commodity"
    -- Andrew Ryan (The Globe and Mail, 2005/11/26)
    Walter Roberson, Mar 3, 2006
    #2
    1. Advertising

  3. On 2006-03-03, Walter Roberson <-cnrc.gc.ca> wrote:
    > Minus 1 point for not using integer main(void)


    I guess you mean "int", there is no type named "integer" that I know
    of :)

    > Minus 1 point for failing to return an exit status to the
    > operating system, which is recommended for C89 programs.
    >
    > Minus another point for failing to return an exit status to the
    > operating system, which is mandatory for C99 programs. We know
    > that you are using C99 because of the comment style. If you wish
    > to claim that you should not be docked here because you are using
    > C89 and returning a value is optional for C89, then you will
    > instead be docked for using C99 style comments in a C89 program.


    If I'm not mistaken you got this backwards.
    C89 I believe required an explicit return statement at the end of main,
    while C99 does not.

    5.1.2.2.3 Program Termination
    "reaching the } that terminates the main function returns a value of 0"

    > Minus 1 point for failing to close the input and output files.


    That's more of an issue of style and hardly grounds for removing points,
    as all open files are closed upon program exit.

    7.19.3 Files
    5) "... If the main function returns to its original caller or if the
    exit function is called, all open files are closed (hence all output
    streams are flushed) before program termination."

    > Minus 1 point for not using the result of counting the lines.
    > If you don't use the count, then don't do the count.


    Minus 1 point for keeping a point counter during your whole reply, and
    not telling us the final count at the end :)


    --
    John Tsiombikas (Nuclear / Mindlapse)

    http://nuclear.demoscene.gr/
    John Tsiombikas (Nuclear / Mindlapse), Mar 3, 2006
    #3
  4. -cnrc.gc.ca (Walter Roberson) writes:
    > In article <>,
    > FUGATO <> wrote:

    [...]
    >> printf("Enter the filename to be scanned: "); // ask the user

    >
    > Minus 1 point for not ending the prompt with '\n' and another for
    > not using fflush() to ensure that the prompt will be displayed before the
    > read.


    With a call to fflush(stdout) after the printf(), a newline is not
    necessary. (In fact, I prefer not to have a newline at the end of a
    prompt; it makes things clearer to the user.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Mar 3, 2006
    #4
  5. "John Tsiombikas (Nuclear / Mindlapse)" <> writes:
    > On 2006-03-03, Walter Roberson <-cnrc.gc.ca> wrote:

    [...]
    >> Minus 1 point for failing to close the input and output files.

    >
    > That's more of an issue of style and hardly grounds for removing points,
    > as all open files are closed upon program exit.


    Style issues can certainly be grounds for removing points; after all,
    good style is one of the things we're trying to teach.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Mar 3, 2006
    #5
  6. In article <>,
    Keith Thompson <> wrote:
    >-cnrc.gc.ca (Walter Roberson) writes:
    >> In article <>,
    >> FUGATO <> wrote:


    >>> printf("Enter the filename to be scanned: "); // ask the user


    >> Minus 1 point for not ending the prompt with '\n' and another for
    >> not using fflush() to ensure that the prompt will be displayed before the
    >> read.


    >With a call to fflush(stdout) after the printf(), a newline is not
    >necessary.


    For text files, the status of the last line is officially indeterminate
    if there is no newline at the end of the line. fflush() does not
    introduce that newline: it just spills the accumulated buffer.
    Hence to be -sure- that prompt will be visible, you must terminate
    it with a newline.

    >(In fact, I prefer not to have a newline at the end of a
    >prompt; it makes things clearer to the user.)


    Yeah, but it relies upon system-specific behaviour.

    Though this discussion does lead to the question of whether
    stdout is a text stream or a binary stream ?
    --
    I was very young in those days, but I was also rather dim.
    -- Christopher Priest
    Walter Roberson, Mar 3, 2006
    #6
  7. -cnrc.gc.ca (Walter Roberson) writes:
    > In article <>,
    > Keith Thompson <> wrote:
    >>-cnrc.gc.ca (Walter Roberson) writes:
    >>> In article <>,
    >>> FUGATO <> wrote:

    >
    >>>> printf("Enter the filename to be scanned: "); // ask the user

    >
    >>> Minus 1 point for not ending the prompt with '\n' and another for
    >>> not using fflush() to ensure that the prompt will be displayed before the
    >>> read.

    >
    >>With a call to fflush(stdout) after the printf(), a newline is not
    >>necessary.

    >
    > For text files, the status of the last line is officially indeterminate
    > if there is no newline at the end of the line. fflush() does not
    > introduce that newline: it just spills the accumulated buffer.
    > Hence to be -sure- that prompt will be visible, you must terminate
    > it with a newline.


    Only if it's the last line of output.

    >>(In fact, I prefer not to have a newline at the end of a
    >>prompt; it makes things clearer to the user.)

    >
    > Yeah, but it relies upon system-specific behaviour.
    >
    > Though this discussion does lead to the question of whether
    > stdout is a text stream or a binary stream ?


    It's a text stream.

    C99 7.19.1p3:

    stderr
    stdin
    stdout

    which are expressions of type "pointer to FILE" that point to the
    FILE objects associated, respectively, with the standard error,
    input, and output streams.

    C99 7.19.3p7:

    At program startup, three text streams are predefined and need not
    be opened explicitly -- _standard input_ (for reading conventional
    input), _standard output_ (for writing conventional output), and
    _standard error_ (for writing diagnostic output). As initially
    opened, the standard error stream is not fully buffered; the
    standard input and standard output streams are fully buffered if
    and only if the stream can be determined not to refer to an
    interactive device.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Mar 3, 2006
    #7
  8. On Fri, 3 Mar 2006 06:01:43 UTC, "John Tsiombikas (Nuclear /
    Mindlapse)" <> wrote:

    > > Minus 1 point for failing to close the input and output files.

    >
    > That's more of an issue of style and hardly grounds for removing points,
    > as all open files are closed upon program exit.


    Noways, failing to close the files is failing any chance to dedect
    errors. Econ fclose() will return an error indicator showing that data
    is not written and/or that the filecan't simply closed at all because
    some error on the target device hinders that.

    > 7.19.3 Files
    > 5) "... If the main function returns to its original caller or if the
    > exit function is called, all open files are closed (hence all output
    > streams are flushed) before program termination."


    Yeah - but what is when the last byte can't been written to the file
    because device is full, gets crashed....? What is when the underlying
    system is unable to write the management information to the file? A
    failsave application will inform the user about any critical error
    that it can not recover from itself.

    So -30 points to the OP by leaving off each and any error handling.
    -3,000 points to you by giving false hints to the OP and to the
    community.


    --
    Tschau/Bye
    Herbert

    Visit http://www.ecomstation.de the home of german eComStation
    eComStation 1.2 Deutsch ist da!
    Herbert Rosenau, Mar 4, 2006
    #8
  9. On 2006-03-04, Herbert Rosenau <> wrote:
    >
    > On Fri, 3 Mar 2006 06:01:43 UTC, "John Tsiombikas (Nuclear /
    > Mindlapse)" <> wrote:
    >
    >> > Minus 1 point for failing to close the input and output files.

    >>
    >> That's more of an issue of style and hardly grounds for removing points,
    >> as all open files are closed upon program exit.

    >
    > Noways, failing to close the files is failing any chance to dedect
    > errors.


    I agree, still it's perfectly valid for a C program to not close them
    explicitly.

    > Econ fclose() will return an error indicator showing that data
    > is not written and/or that the filecan't simply closed at all because
    > some error on the target device hinders that.

    .... snip ...
    > A failsave application will inform the user about any critical error
    > that it can not recover from itself.


    The stream (FILE*) *will* be closed, regardless of what the OS does with
    the actual file.
    Your point is just that you miss a chance to provide an error message to
    the user (or error code to the caller) that some of the data may have
    not being written. While this is a very good practice, and I definitely
    want to encourage it, however the OP's program was not *wrong* in this
    respect, just not very user-friendly.

    > So -30 points to the OP by leaving off each and any error handling.
    > -3,000 points to you by giving false hints to the OP and to the
    > community.


    Charming ... :)

    --
    John Tsiombikas (Nuclear / Mindlapse)

    http://nuclear.demoscene.gr/
    John Tsiombikas (Nuclear / Mindlapse), Mar 7, 2006
    #9
    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. Sara T.

    WRAP text in <TD>

    Sara T., Jul 26, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    635
    Sara T.
    Jul 26, 2003
  2. Dan
    Replies:
    2
    Views:
    2,059
    Tommy
    Mar 2, 2004
  3. Aaron Fude

    To wrap or not to wrap?

    Aaron Fude, May 8, 2008, in forum: Java
    Replies:
    12
    Views:
    686
    Chronic Philharmonic
    May 10, 2008
  4. Art Werschulz

    Text::Wrap::wrap difference

    Art Werschulz, Sep 22, 2003, in forum: Perl Misc
    Replies:
    0
    Views:
    221
    Art Werschulz
    Sep 22, 2003
  5. Art Werschulz

    Text::Wrap::wrap difference

    Art Werschulz, Sep 24, 2003, in forum: Perl Misc
    Replies:
    1
    Views:
    233
    Anno Siegel
    Sep 25, 2003
Loading...

Share This Page