Difficulty with project

[nitro_punk85]

Hey guys its me again, having trouble with a project for class. We're
writing a program to Grade a test, the answer key and student answers r
in the same file and we have to read them in and score the test and
then assign a grade and output all of that to another file. I've got
everything done, just can't get the switch structure that assigns the
grades based on the score to work. This is the error I get :
error C2440: '=' : cannot convert from 'const char [2]' to 'char'

and this is the source for the function:

char examGrades(int& score)
{
char ch2;

switch(static_cast<int>(score /40.0 * 10))
{
case 0: case 1: case 2: case 3: case 4: case 5: ch2 = "F";
case 6: ch2 = "D";
case 7: ch2 = "C";
case 8: ch2 = "B";
case 9: case 10: ch2 = "A";
default: ch2 = "F";
break;
}
return ch2;

}

Any suggestions would be great as this is due by midnight tonight. I
know, I'm a horrible procrastinator! :(

Thanks Again,
Matt

[nitro_punk85]

Nevermind, I figured the problem out. Thanks anyway!

[Alex Buell]

On 25 Apr 2006 18:49:09 -0700 "ni**********@yahoo.com"
<ni**********@yahoo.com> waved a wand and this message magically
appeared:

case 0: case 1: case 2: case 3: case 4: case 5: ch2 =
"F"; case 6: ch2 = "D";
case 7: ch2 = "C";
case 8: ch2 = "B";
case 9: case 10: ch2 = "A";
default: ch2 = "F";

Your problem is that you are using double quotes (") when you should
have used single quotes (').

--
http://www.munted.org.uk

Take a nap, it saves lives.

[andy]

ni**********@yahoo.com wrote:

Hey guys its me again, having trouble with a project for class. We're
writing a program to Grade a test, the answer key and student answers r
in the same file and we have to read them in and score the test and
then assign a grade and output all of that to another file. I've got
everything done, just can't get the switch structure that assigns the
grades based on the score to work. This is the error I get :
error C2440: '=' : cannot convert from 'const char [2]' to 'char'

and this is the source for the function:

char examGrades(int& score)
{
char ch2;

switch(static_cast<int>(score /40.0 * 10))
{
case 0: case 1: case 2: case 3: case 4: case 5: ch2 = "F";
case 6: ch2 = "D";
case 7: ch2 = "C";
case 8: ch2 = "B";
case 9: case 10: ch2 = "A";
default: ch2 = "F";
break;
}
return ch2;

}

FWIW there are more errors(actually same one repeated) in your function
which will cause it not to function as you expect. Read up about switch
statement to discover what you have dong wrong. I would also look up
when it is a good idea passing arguments by reference, const reference
or by value

regards
Andy Little

[Tomás]

Do you want to return a single character (without a null terminator), or do
you want to return a string? Let's say you want a string:

char examGrades(int& score)
const char* examGrades(int score)
It's inefficient to pass by reference in the above;

{
char ch2;

const char* ch2;


switch(static_cast<int>(score /40.0 * 10))
{
case 0: case 1: case 2: case 3: case 4: case 5: ch2 = "F";

You need a "break" statment here.

case 6: ch2 = "D";

And here.

case 7: ch2 = "C";

And here.
case 8: ch2 = "B";

And here.
case 9: case 10: ch2 = "A";
And here.
default: ch2 = "F";
break;
}
return ch2;

}

There's no need for the "ch2" variable. I simply would have written:

case 7: return "C";

-Tomás

[Default User]

Tomas wrote:

There's no need for the "ch2" variable. I simply would have written:

case 7: return "C";

You could, but many coding style manuals frown on multiple returns.
There's nothing wrong with that part of the program.


Brian

[Phlip]

Default User wrote:

You could, but many coding style manuals frown on multiple returns.
There's nothing wrong with that part of the program.

There's nothing wrong with multiple returns if you follow a more general
principle - no long functions.

Once you think you must have long functions, then you get lots of extra
rules to deal with them - no goto, single return, etc.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Tomás]

... many coding style manuals frown on multiple returns.

Only retarded people have to read those manuals. People with a fully-
functional brain have the intelligence to analyse and make these decisions
all by themselves.

-Tomás

[Phlip]

Tomás wrote:

Only retarded people have to read those manuals. People with a fully-
functional brain have the intelligence to analyse and make these decisions
all by themselves.

Wow! You are smart enough to just read the ISO C++ Standard, and reconstruct
the book /C++ Coding Standards/ from it?

Glad I can read, 'cause I ain't so smart!

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Default User]

Tomas wrote:

... many coding style manuals frown on multiple returns.

Only retarded people have to read those manuals.

Jackass.

Brian

[Default User]

Phlip wrote:

Default User wrote:

You could, but many coding style manuals frown on multiple returns.
There's nothing wrong with that part of the program.

There's nothing wrong with multiple returns if you follow a more
general principle - no long functions.

In my personal code, I try to keep the number of returns reduced but
I'm not dogmatic about it. There are occasions when it's the clearer
choice. I don't think the case given is one of those, but opinions will
vary. In my professional code, I have to follow the style guide. Single
return is a requirement.

My point to Tomas (who has demonstrated that he's not a person worth
dealing with after all) was that it's a stylistic choice and far from
clear-cut. I generally abhor style comments in responses here unless it
refers to something that badly affects readability. This case, again in
my opinion, was not that type of situation.


Brian

[Phlip]

Default User wrote:

In my personal code, I try to keep the number of returns reduced but
I'm not dogmatic about it. There are occasions when it's the clearer
choice. I don't think the case given is one of those, but opinions will
vary. In my professional code, I have to follow the style guide. Single
return is a requirement.

My point to Tomas (who has demonstrated that he's not a person worth
dealing with after all) was that it's a stylistic choice and far from
clear-cut. I generally abhor style comments in responses here unless it
refers to something that badly affects readability. This case, again in
my opinion, was not that type of situation.

My brief experience and subjective guesswork about the single-return rule is
it helps refactoring. Generally because if you drag your mouse from here to
there, everything between should itself also be single-entry single-exit,
too.

Contrarily, 'return' answers the old chestnut "how to break out of nested
loops without goto?" very nicely!

I won't ask if your day job's style guide specifies short functions. But
ours does. ;-)

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[red floyd]

Tomás wrote:

... many coding style manuals frown on multiple returns.

Only retarded people have to read those manuals. People with a fully-
functional brain have the intelligence to analyse and make these decisions
all by themselves.

So if you were working on a project with a MIL-STD-498 development
model, and you would feel free to ignore your Software Development Plan?

Nice.

[Default User]

Phlip wrote:

Default User wrote:

In my personal code, I try to keep the number of returns reduced but
I'm not dogmatic about it. There are occasions when it's the clearer
choice. I don't think the case given is one of those, but opinions
will vary. In my professional code, I have to follow the style
guide. Single return is a requirement.

My point to Tomas (who has demonstrated that he's not a person worth
dealing with after all) was that it's a stylistic choice and far
from clear-cut. I generally abhor style comments in responses here
unless it refers to something that badly affects readability. This
case, again in my opinion, was not that type of situation.

My brief experience and subjective guesswork about the single-return
rule is it helps refactoring. Generally because if you drag your
mouse from here to there, everything between should itself also be
single-entry single-exit, too.

Contrarily, 'return' answers the old chestnut "how to break out of
nested loops without goto?" very nicely!

I won't ask if your day job's style guide specifies short functions.
But ours does. ;-)

No, our coding standard it fairly black-and-white on most issues. It's
used a lot these days by the tools group to create rules for code
analyzers.

Brian

[Jim Langston]

"Phlip" <ph******@yahoo.com> wrote in message
news:Pa******************@newssvr33.news.prodigy.c om...

Default User wrote:

You could, but many coding style manuals frown on multiple returns.
There's nothing wrong with that part of the program.

There's nothing wrong with multiple returns if you follow a more general
principle - no long functions.

Once you think you must have long functions, then you get lots of extra
rules to deal with them - no goto, single return, etc.

Actually, one of the coding standards came up with one entry point and one
exit point per function. I believe it was top down coding, but am not
positive, that was many years ago. I tend to agree with it, however.

The exception I make to the rule is in case of error conditions such as a
function/method used to load a table returning a bool value on success or
failure. If the file can't be loaded I will display an error, or log to a
file, then return false. The other exception I make is at the very bottom
of a function I may have a
return true;
else
return false;

[Michiel.Salters]

Default User wrote:

Tomas wrote:

There's no need for the "ch2" variable. I simply would have written:

case 7: return "C";

You could, but many coding style manuals frown on multiple returns.
There's nothing wrong with that part of the program.

Laziness. Multiple returns are tricky if they're irregular. If EVERY
return is
inside a switch statement, and EVERY label has a return statement,
those
multiple return statements make a more regular & readable function. The
alternative is to define a return_ variable, which has no other purpose
but
to satisfy a dumb rule. Result: the compiler, the programmer and the
end
user are all worse off by the rule; the rule maker saves writing a few
sentences.

HTH,
Michiel Salters