Stuck on a problem

Pages: 12
I need help with writing a program that initializes an array of characters with the phrase, “Take me to Clearwater Beach!”.

Using pointers, scan the array to make each character upper case. The catch: you may NOT use the isupper(), islower(), toupper(), or tolower() functions. You must calculate whether a character is upper or lower case, and use the same logic to convert to upper case where applicable.
Hints:
*cptr >= ‘a’ && *cptr <= ‘z’

Assuming the ASCII value for ‘a’ is greater than ‘A’, how could you use an expression like, (‘a’ – ‘A’) to convert to upper case?

Thanks in advance if anyone can help.

EDIT: Sorry forgot to post what I have so far

1
2
3
4
5
6
7
#include <iostream>
using namespace std; 
int main()
{
	int upperToLowerOffset = ('a' - 'A');
	std::cout << char('a' - upperToLowerOffset) << std::endl;
}

Last edited on
What do you have so far?
The difference between a lower case letter and it's upper case counterpart is 32. "'a' - 32" will equal 'A'. A character with the value of 32 is the space character. So you can do this:

1
2
3
4
5
int main()
{
	std::cout << char('a' - 32) << '\n';
	std::cout << char('a' - ' ');
}


Output:

A
A
The difference between a lower case letter and it's upper case counterpart is 32.


Except the instructions said:

Assuming the ASCII value for ‘a’ is greater than ‘A’, how could you use an expression like, (‘a’ – ‘A’) to convert to upper case?


Ignore the hard-coded 32 and use ('a' - 'A') instead. This is telling you how much larger the lower case letters than the upper case letters. This happens to be 32 on ASCII machines, but understanding where the difference comes from is important and fits within the constraints of the assignment.
Ignore the hard-coded 32

The second "cout" shows that you can use ' ' to skip a hardcoded number.
' ' is as magic as 32
if you read somewhere c - ' ' it is not clear that that converts to uppercase
'a' - 'A' is clearer, so you may write c - ('a'-'A') or c - 'a' + 'A'
Last edited on
' ' is as magic as 32


I would say it is even more magical than 32. At least a number looks like it could be interpreted as an offset. Using the space character is very unintuitive.

Better would be declaring and using a variable:

1
2
3
4
5
6
7
#include <iostream>

int main()
{
    int upperToLowerOffset = ('a' - 'A');
    std::cout << char('a' - upperToLowerOffset) << std::endl;
}
Last edited on
Relax guys, it's a concept. It can be implemented many ways and in the end the assignment was just asking to use ASCII values.

BTW, I find using ('a' - 'A') or the setting of a permanent variable to be overkill and un-needed. You can literally just use ' ' or 32 which is faster than setting a variable and using it over and over, also faster than the whole ('a' - 'A'). If you think it isn't clear, you can put a comment once.

I don't see the logic in being overly pedantic with this.
zapshe wrote:
I don't see the logic in being overly pedantic with this.


You aren't old enough to have coded with EBCDIC! (In which respect, you're quite lucky!)


A space is very dangerous. There seem to be an awful lot of different "spaces" in most word-processing packages.
Last edited on
I don't see the logic in being overly pedantic with this.

Not that long ago things weren't so neat and clean, cut and & dried when it came to encoding alphabetic characters.

https://en.wikipedia.org/wiki/EBCDIC

A lot of hard work and fighting resulted in a standard that still isn't fully used by different operating systems. Windows is notorious for having weird stuff floating around.
There seem to be an awful lot of different "spaces" in most word-processing packages.

I don't think that directly related to using ' ' in code. I think that's only an issue when taking data from a document.

But yea, I'm glad I'm not dealing with a lot of things that people had to back in the day!
I think the main point here is that OP's problem statement clearly lays out the allowable assumptions:
* 'a' > 'A'
* islowercase(x) = (x >= 'a' && x <= 'z')
None of the following statements are deducible from those assumptions:
* The character set is ASCII
* 'a' - 'A' == 32
* ' ' == 32
Well, I don't think that's true. His problem states this:

I need help with writing a program that initializes an array of characters with the phrase, “Take me to Clearwater Beach!”.

If this phrase is hard coded, there would be no choice than for it to be following the proper ASCII rules in C++.

Moreover, ('a' - 'A') and ' ' will always equal 32 in C++, I don't know of a way to make hard coded values like this NOT follow the proper ASCII table.


The phrasing of the OP's problem seems to almost imply there's some kind of hidden element, but I'm fairly certain this was done purposefully by the professor so that he doesn't give away to much information to the students.
Moreover, ('a' - 'A') and ' ' will always equal 32 in C++
Nope. The numeric value of character literals is implementation-defined.

I don't know of a way to make hard coded values like this NOT follow the proper ASCII table
That's simply because you've never used a non-ASCII-like system. Try using an EBCDIC system.
I see. The values of character is implementation-defined, but that just means that as long as the environment has C++ with the ASCII system, it'll always equal 32, right?

I don't think it's likely the professor is expecting them write code for a standard that died before I was born - especially since students write code on their own machine.

Try using an EBCDIC system.

I already know I'd prefer taking a swan dive off a roof.
Last edited on
as long as the environment has C++ with the ASCII system, it'll always equal 32, right?

Nope, just that the current implementation you are currently using does that.

Tomorrow it could be something entirely different.

For a learning experience, not completely wrong to make that assumption. For a real world app, it could be disastrous.

Pointer size, for example, can be especially elusive depending on if 32-bit or 64-bit code. As well as dependent on the OS.
Forgot to post what I have so far into my OP.

Went ahead and edited it in.
I don't understand why you defend so vehemently the usage of magic numbers
Nope, just that the current implementation you are currently using does that.

Tomorrow it could be something entirely different.

Doesn't sound likely. However, do you mean the C++ text system or the actual ASCII system?

Pointer size, for example, can be especially elusive depending on if 32-bit or 64-bit code. As well as dependent on the OS.

This makes more sense, since a pointer may communicate with the OS, but the ASCII system is built in kind of thing.

I don't understand why you defend so vehemently the usage of magic numbers

' ' isn't a magic number. If you argue that ' ' won't always equal the numerical value between lower and upper case letters in the ASCII table, then how would assuming that the lower case value of a letter will always be higher than the upper case one in ('a' - 'A') be any different? Or that each letter will have the same value apart from it's counterpart as every other letter does?

The only way I see 'a' - ' ' failing is if C++ uses another standard for text, in which ALL solutions here become invalid. Systems like ASCII are standard for a reason - it doesn't change on a whim - it hasn't been edited since the 1986.
Last edited on
but the ASCII system is built in kind of thing.
It's not, though. The character set is as much a property of the target platform as the value of sizeof(void *).

how would assuming that the lower case value of a letter will always be higher than the upper case one in ('a' - 'A') be any different?
Because the problem statement explicitly allows making that assumption.

The only way I see 'a' - ' ' failing is if C++ uses another standard for text, in which ALL solutions here become invalid.
For example:
\0
'A' = 1
...
'Z' = 26
'a' = 27
...
'z' = 52
' ' = 53
'!' = 54
(the rest of the code points are unassigned)
This character set is sufficient to implement OP's problem, it meets neither 'a' - 'A' == 32 nor ' ' == 32, and it doesn't break the expression c - ('a'-'A').

I'm sorry, but you're just wrong. The assumptions you're making are too strong. Learning how to read a requirements spec is a basic engineering skill that you better acquire. If a spec says something like "the program may assume that integers are always 32 bits long" and you write your code assuming two's complement because that's what you're familiar with, your program will be broken.
Last edited on
Pages: 12