C++ counter

Started by
20 comments, last by M2tM 13 years, 7 months ago
What is the easiest way to do a counter(can have multiple digits) that counts the alphabet(capitalized) instead of like normal? A -> B -> C -> etc
Advertisement
I'm not exactly sure what you mean. But maybe this is what you are looking for.

char first = 'A';char last = 'Z';int count = last - first + 1;


Since they are already in sequence and a character is represented by a number, then you should be able to do simple subtraction to get your result. The '+ 1' is because 26-1=25 and if you are trying to get the count instead of the difference you will need to compensate for that.

I hope this helps.
As far as I know, everything in memory is stored a bunch of bits, and the way the program goes about them depends on their type, so if you cast an int into a char the program should treat the integer as a char.

// main.cpp#include <iostream>int main(){	char last = 'Z';	char first = 'A';		for (int counter = first; counter <= last; counter++) {		std::cout << (char)counter << std::endl;	}}


the above will iterate through all capital letters and display them to the console. You can assign 'A' to an int counter and advance in a loop until counter == 'Z' and check how many times the loop had to repeat to get there.

// main.cpp#include <iostream>int main(){	char last = 'Z';	char first = 'A';		int counter = 0;	for (int i = first; i <= last; i++) {		std::cout << (char)i << std::endl;		counter++;	}	std::cout << "There was " << counter << " letters." << std::endl;		return 0;}

Yo dawg, don't even trip.

mozie: Fast, but not correct. It will work almost everywhere, but the C++ standard does not define which encoding is used for char. It might also be EBCDIC, where there are discontinuities. See also <cctype> / <ctype.h>.

One correct solution that lets you resist before the holy gremium would be ...

char increment (char c) {    switch (c) {    case 'a': return 'b';    case 'b': return 'c';    case 'c': return 'd';    case 'd': return 'e';    case 'e': return 'f';    case 'f': return 'g';    case 'g': return 'h';    case 'h': return 'i';    case 'i': return 'j';    case 'j': return 'k';    case 'k': return 'l';    ...    }    // if not handled, fail    throw std::runtime_error(std::string("Character '")+c+"' not handled in increment()");}


There's not a need to make this faster by hand, as the compiler prolly replaces your switch statement with a looked up jump target, or is even smart enough to roll out a lookup table.



boogyman19946:

Apart from the bit I already sayd, you don't need to cast a char to int to do calculations with them, they belong to the integral types.

Note though that the standard does not define whether a char is signed or unsigned. Hence, char, unsigned char and signed char are distinct types (for the template-ppl among us, you can specialize on all three char-types).
Thx all, you've given me a lot to think about.
Jacob Jingle.
The easiest thing to do is not do it -- just use an integer and convert it at output time.

And that's fairly easy using a normal digit printer but just doing it in base-26 instead of base-10.

...

for (char c = 'A'; c <= 'Z'; ++ c){// Do stuff}


Simple enough. Chances of ASCII are high.
This works because a char is really nothing more than an integer with a smaller range.

http://www.asciitable.com/

[Edited by - 1863 on August 25, 2010 10:20:49 PM]
The standards-conforming variant is dead simple, too. And it is guaranteed to always work. Is there any real advantage of using implementation defined behaviour and making the application dirty?
IMO, yes there is. This is a simple problem requiring a simple solution. We should be keeping it real in the beginner forum, not busting out switch statements when we could do this in 25 adds. No beginner posting here is going to be working on a system that defaults to an obscure encoding method where this doesn't work.
I'd think that, to most people, the switch implementation looks dirty and impractical, since ASCII is so ubiquitous. That is an interesting fact I wasn't aware of, though, Phresnel. It's an assumed "constraint" I never would have thought needed mentioning.

This topic is closed to new replies.

Advertisement