470,849 Members | 1,082 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,849 developers. It's quick & easy.

octal error

I have been trying to cin an number from 0 to 9 with a leading 0. For
example 00 or 07. I was using a switch case.
switch (int)
{
case 01: break;
case 02: break;.....
My problem arises at 08 and 09 because they are not octal. Is there
any way to coerce the input variable to decimal despite it having a
leading zero .
Jun 27 '08 #1
25 3622
notahipee wrote:
I have been trying to cin an number from 0 to 9 with a leading 0. For
example 00 or 07. I was using a switch case.
You were using a switch case for what?
switch (int)
^^^^^^^^^^^
That's a syntactically incorrect statement.
{
case 01: break;
case 02: break;.....
My problem arises at 08 and 09 because they are not octal.
What problem would that be?
Is there
any way to coerce the input variable to decimal despite it having a
leading zero .
This is a glimmer of an actual problem you seem to be having... But
I am not seeing the alleged behaviour in the following program.

#include <iostream>
#include <ostream>
int main()
{
int a = 666;
std::cin >a;
std::cout << "you entered " << a << std::endl;
}

If I enter 08, it prints 'you entered 8'. What's the problem?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jun 27 '08 #2
What I was trying to do looks like this:
#include <iostream>
#include <ostream>
int main()
{
int a;

cout << "enter a number " << endl;
cin >a;
switch (a)
{
case 00: cout << zero;
case 01: cout << zero one;
etc.
}
Since a leading zero changes the number to octal it crashes at 08 and
09.
Jun 27 '08 #3
notahipee wrote:
I have been trying to cin an number from 0 to 9 with a leading 0. For
example 00 or 07. I was using a switch case.
switch (int)
{
case 01: break;
case 02: break;.....
My problem arises at 08 and 09 because they are not octal. Is there
any way to coerce the input variable to decimal despite it having a
leading zero .
Please post complete, minimal code that demonstrates the problem.


Brian
Jun 27 '08 #4
notahipee wrote:
What I was trying to do looks like this:
#include <iostream>
#include <ostream>
int main()
{
int a;

cout << "enter a number " << endl;
cin >a;
switch (a)
{
case 00: cout << zero;
case 01: cout << zero one;
etc.
}
Since a leading zero changes the number to octal it crashes at 08 and
09.
FAQ 5.8.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jun 27 '08 #5
This is all of it.
#include <iostream>
#include <ostream>
int main()
{
int a;

cout << "enter a number " << endl;
cin >a;
switch (a)
{
case 00: cout << zero;
case 01: cout << zero one;
case 02: cout << zero two;
case 03: cout << zero three;
case 04: cout << zero four;
case 05: cout << zero five;
case 06: cout << zero six;
case 07: cout << zero seven;
case 08: cout << zero eight;
case 09: cout << zero ninne;
}

return 0;
}
Jun 27 '08 #6

"notahipee" <we********@hotmail.comwrote in message
news:9a**********************************@s50g2000 hsb.googlegroups.com...
What I was trying to do looks like this:
#include <iostream>
#include <ostream>
int main()
{
int a;

cout << "enter a number " << endl;
cin >a;
switch (a)
{
case 00: cout << zero;
case 01: cout << zero one;
etc.
}
Since a leading zero changes the number to octal it crashes at 08 and
09.
How about using 010, 011 then ...?

:-)

regards
Andy Little

Jun 27 '08 #7
notahipee wrote:
This is all of it.
#include <iostream>
#include <ostream>
int main()
{
int a;

cout << "enter a number " << endl;
cin >a;
switch (a)
{
case 00: cout << zero;
case 01: cout << zero one;
case 02: cout << zero two;
case 03: cout << zero three;
case 04: cout << zero four;
case 05: cout << zero five;
case 06: cout << zero six;
case 07: cout << zero seven;
case 08: cout << zero eight;
case 09: cout << zero ninne;
}

return 0;
}
And what errors you get? I believe you just need to drop the
leading zero in all of your 'case' labels, but that's just
a guess.

What is it you're trying to accomplish with the leading 0?
Keep in mind that whatever form you enter your 'a' in, is
getting converted into the internal representation which is
just a value. And if you want to put octal numbers in your
'case' labels, you shouldn't use '08' or '09' since they are
not octal numbers, use '010' and '011'...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jun 27 '08 #8
notahipee wrote:
What I was trying to do looks like this:
#include <iostream>
#include <ostream>
int main()
{
int a;

cout << "enter a number " << endl;
cin >a;
switch (a)
{
case 00: cout << zero;
case 01: cout << zero one;
etc.
}
Since a leading zero changes the number to octal it crashes at 08 and
09.
The simple answer is, "don't do that".

Why are you putting the leading zero in the case labels? What do you
think this achieves?

Brian
Jun 27 '08 #9

"Default User" <de***********@yahoo.comwrote in message
news:68*************@mid.individual.net...
notahipee wrote:
>What I was trying to do looks like this:
#include <iostream>
#include <ostream>
int main()
{
int a;

cout << "enter a number " << endl;
cin >a;
switch (a)
{
case 00: cout << zero;
case 01: cout << zero one;
etc.
}
Since a leading zero changes the number to octal it crashes at 08 and
09.

The simple answer is, "don't do that".

Why are you putting the leading zero in the case labels? What do you
think this achieves?
Yep... octal is a bit "retro" these days... hexadecimal on the other hand is
useful

regards
Andy Little
Jun 27 '08 #10
On many occasion people are asked to enter dates like 01/01/07 for Jan
first 1807 for example. So I want the leading 0. Also I can't have the
user entering octal but I have tried to get the int a; to be coreced
to from a decimal entry to octal for use by the switchcase. but \d
doesn't work. Unfortunately I am not sure how to apply cin.get or
cin.ignore properly.

Jun 27 '08 #11
On May 9, 3:12*pm, notahipee <werldpe...@hotmail.comwrote:
On many occasion people are asked to enter dates like 01/01/07 for Jan
first 1807 for example. So I want the leading 0. Also I can't have the
user entering octal but I have tried to get the int a; to be coreced
to from a decimal entry to octal for use by the switchcase. but \d
doesn't work. Unfortunately I am not sure how to apply cin.get or
cin.ignore properly.
I just got it to work. I placed above the switch case the following:
if (b>0 && b<=9)
Jun 27 '08 #12
On May 9, 3:17*pm, notahipee <werldpe...@hotmail.comwrote:
On May 9, 3:12*pm, notahipee <werldpe...@hotmail.comwrote:
On many occasion people are asked to enter dates like 01/01/07 for Jan
first 1807 for example. So I want the leading 0. Also I can't have the
user entering octal but I have tried to get the int a; to be coreced
to from a decimal entry to octal for use by the switchcase. but \d
doesn't work. Unfortunately I am not sure how to apply cin.get or
cin.ignore properly.

I just got it to work. I placed above the switch case the following:
if (b>0 && b<=9)
I forgot to say thank for the input.
Jun 27 '08 #13

"notahipee" <we********@hotmail.comwrote in message
news:a6**********************************@m44g2000 hsc.googlegroups.com...
On many occasion people are asked to enter dates like 01/01/07 for Jan
first 1807 for example. So I want the leading 0. Also I can't have the
user entering octal but I have tried to get the int a; to be coreced
to from a decimal entry to octal for use by the switchcase. but \d
doesn't work. Unfortunately I am not sure how to apply cin.get or
cin.ignore properly.
There is a lot of difference between console input from a user and how
numbers are conventionally represented in source code.

User input is simply a sequence of characters and users are quite capable of
entering pretty much anything. And what the actually mean is up to you not
the C++ programming language. First you should document valid formats you
expect the user to enter the date in. Generally IMO its best to read into a
std::string rather than to try to use the inbuilt input overloads for
something like this.

Then you can look at the string character by character to see if the input
is valid according to your spec. If not you need to inform the user,
Otherwise You can translate the string into values the program can
understand.

HTH

regards
Andy Little
Jun 27 '08 #14
notahipee wrote:
On many occasion people are asked to enter dates like 01/01/07 for Jan
first 1807 for example. So I want the leading 0.
You should read in a string and parse it. Or not require the user to
input the leading zeroes when you are using the date components as
numbers. Save that for the output.
Also I can't have the
user entering octal but I have tried to get the int a; to be coreced
to from a decimal entry to octal for use by the switchcase.
But you DON'T want octal, or you wouldn't be trying to have 08. There
is no '8' in octal.

Dates are not normally written in octal, why are you trying to use
octal?


Brian
Jun 27 '08 #15
Actually the problem was thinking that I needed to include the leading
0 in the switch case like so- case 07: break;
Someone mentioned that it was not necessary to do that. So the program
is working fine now. I am able to enter 07 at the prompt and the
output reads "zero seven".
Jun 27 '08 #16
notahipee wrote:
Since a leading zero changes the number to octal it crashes at 08 and
09.
It crashes? Then you should make a bug report to the compiler developers.
Jun 27 '08 #17
On 2008-05-09 23:59, Victor Bazarov wrote:
notahipee wrote:
>This is all of it.
#include <iostream>
#include <ostream>
int main()
{
int a;

cout << "enter a number " << endl;
cin >a;
switch (a)
{
case 00: cout << zero;
case 01: cout << zero one;
case 02: cout << zero two;
case 03: cout << zero three;
case 04: cout << zero four;
case 05: cout << zero five;
case 06: cout << zero six;
case 07: cout << zero seven;
case 08: cout << zero eight;
case 09: cout << zero ninne;
}

return 0;
}

And what errors you get? I believe you just need to drop the
leading zero in all of your 'case' labels, but that's just
a guess.

What is it you're trying to accomplish with the leading 0?
Keep in mind that whatever form you enter your 'a' in, is
getting converted into the internal representation which is
just a value. And if you want to put octal numbers in your
'case' labels, you shouldn't use '08' or '09' since they are
not octal numbers, use '010' and '011'...
Even assuming that you drop the leading zeros (and fix the other issues)
the program will not work as expected since it will print "zero one"
even if the user just entered "1".

If you explain what you are trying to do (not getting the switch
statement to work, but rather why you have it to begin with) we might be
able to help you more.

--
Erik Wikström
Jun 27 '08 #18
On 9 mai, 23:22, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
notahipee wrote:
I have been trying to cin an number from 0 to 9 with a leading 0. For
example 00 or 07. I was using a switch case.
[...]
This is a glimmer of an actual problem you seem to be
having... But I am not seeing the alleged behaviour in the
following program.
#include <iostream>
#include <ostream>
int main()
{
int a = 666;
std::cin >a;
std::cout << "you entered " << a << std::endl;
}
If I enter 08, it prints 'you entered 8'. What's the problem?
I don't know if it's his problem, but what you describe is the
behavior required by the standard. In the classical iostreams
(pre-standard), stream's were initialized with basefield 0, and
not std::ios::dec; 0 means that the compiler should process the
integer more or less like C++ does: a leading 0 means octal, a
leading 0x or 0X hex. In case of doubt concerning which version
of iostream you might end up using, the best policy is probably
to set decimal explicitly:

std::cin.setf( std::ios::dec, std::ios::basefield ) ;

before starting (except, of course, if the std:: are necessary,
it shouldn't be necessary).

(But as I said, I'm far from sure that this is his problem. In
one posting, he spoke of crashing, and of course, using the
wrong base to convert won't cause anything to crash.)

--
James Kanze (GABI Software) email:ja*********@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
Jun 27 '08 #19
notahipee wrote:
On many occasion people are asked to enter dates like 01/01/07 for Jan
first 1807 for example.
<snip>

Please try not to do that.

01/02/03 is the 1st of February in Europe, and the 2nd of January in the
USA. And exactly which century?

I always feel there's a case for doing all my releases after the 12th of
the month...

Andy
Jun 27 '08 #20
On 10 mai, 19:20, Andy Champ <no....@nospam.comwrote:
notahipee wrote:
On many occasion people are asked to enter dates like
01/01/07 for Jan first 1807 for example.
<snip>
Please try not to do that.
01/02/03 is the 1st of February in Europe, and the 2nd of
January in the USA. And exactly which century?
Yes. If the input is in a GUI, the best solution I've seen has
been to use separate fields for each field, with an image as the
background, with a very light D or day for the day field, a very
light M or month for the month field, etc. Otherwise, which
field is which will depend on the locale (but how many people
set that correctly).
I always feel there's a case for doing all my releases after
the 12th of the month...
And of course, you make very sure you test the 29th Feb. in a
leap year before releasing as well. Just as when time is
involved, you make sure you test 2:30 AM the day you go on, and
the day you go off summer time. And on a 32 bit machine, you'll
definitely test some dates after 2038.

In practice, we link against a special library, which has a
modified time() function which allows setting an arbitrary
offset to the system time, so the program does think it's in
such cases. (Our library doesn't modify the view of file
timestamps, since we don't use them.)

--
James Kanze (GABI Software) email:ja*********@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
Jun 27 '08 #21
James Kanze wrote:
>I always feel there's a case for doing all my releases after
the 12th of the month...

And of course, you make very sure you test the 29th Feb. in a
leap year before releasing as well. Just as when time is
involved, you make sure you test 2:30 AM the day you go on, and
the day you go off summer time. And on a 32 bit machine, you'll
definitely test some dates after 2038.
Sure. But you miss my point.

A release date of 1/12/08 could be in the future or the past; a release
data of 1/13/08 (or 13/1/08) is definitely in the past!

I was writing code long before the Millennium Bug went pop very quietly...

Andy
Jun 27 '08 #22
On 11 mai, 22:26, Andy Champ <no....@nospam.comwrote:
James Kanze wrote:
I always feel there's a case for doing all my releases after
the 12th of the month...
And of course, you make very sure you test the 29th Feb. in a
leap year before releasing as well. Just as when time is
involved, you make sure you test 2:30 AM the day you go on, and
the day you go off summer time. And on a 32 bit machine, you'll
definitely test some dates after 2038.
Sure. But you miss my point.
Not really.
A release date of 1/12/08 could be in the future or the past;
a release data of 1/13/08 (or 13/1/08) is definitely in the
past!
I was writing code long before the Millennium Bug went pop
very quietly...
So was I.

All I can say is that you made a valid point: that one has to
test all of the special cases. And all I wanted to add is that
that there are a lot of special cases, when it comes to dates
(and time).

I added it because I suspect that a lot of programmers forget to
test them. Just as they don't take into account that in most of
the world, the standard format for entering dates is dd/mm/YYYY.
(Or dd-mm-YYYY. Or, if you take into account ISO: YYYYmmdd.)

--
James Kanze (GABI Software) email:ja*********@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
Jun 27 '08 #23
notahipee wrote:
This is all of it.
no it isn't
#include <iostream>
#include <ostream>
int main()
{
int a;

cout << "enter a number " << endl;
cin >a;
switch (a)
{
case 00: cout << zero;
case 01: cout << zero one;
case 02: cout << zero two;
case 03: cout << zero three;
case 04: cout << zero four;
case 05: cout << zero five;
case 06: cout << zero six;
case 07: cout << zero seven;
case 08: cout << zero eight;
case 09: cout << zero ninne;
}

return 0;
}
my compiler gives

C:\bin\nota.cpp(8) : error C2065: 'cout' : undeclared identifier
C:\bin\nota.cpp(8) : error C2297: '<<' : bad right operand
C:\bin\nota.cpp(8) : error C2065: 'endl' : undeclared identifier
C:\bin\nota.cpp(9) : error C2065: 'cin' : undeclared identifier
C:\bin\nota.cpp(13) : error C2065: 'zero' : undeclared identifier
C:\bin\nota.cpp(14) : error C2146: syntax error : missing ';' before
identifier 'one'
C:\bin\nota.cpp(14) : error C2065: 'one' : undeclared identifier
C:\bin\nota.cpp(15) : error C2146: syntax error : missing ';' before
identifier 'two'
C:\bin\nota.cpp(15) : error C2065: 'two' : undeclared identifier
C:\bin\nota.cpp(16) : error C2146: syntax error : missing ';' before
identifier 'three'
C:\bin\nota.cpp(16) : error C2065: 'three' : undeclared identifier
C:\bin\nota.cpp(17) : error C2146: syntax error : missing ';' before
identifier 'four'
C:\bin\nota.cpp(17) : error C2065: 'four' : undeclared identifier
C:\bin\nota.cpp(18) : error C2146: syntax error : missing ';' before
identifier 'five'
C:\bin\nota.cpp(18) : error C2065: 'five' : undeclared identifier
C:\bin\nota.cpp(19) : error C2146: syntax error : missing ';' before
identifier 'six'
C:\bin\nota.cpp(19) : error C2065: 'six' : undeclared identifier
C:\bin\nota.cpp(20) : error C2146: syntax error : missing ';' before
identifier 'seven'
C:\bin\nota.cpp(20) : error C2065: 'seven' : undeclared identifier
C:\bin\nota.cpp(21) : error C2041: illegal digit '8' for base '8'
C:\bin\nota.cpp(21) : error C2146: syntax error : missing ';' before
identifier 'eight'
C:\bin\nota.cpp(21) : error C2065: 'eight' : undeclared identifier
C:\bin\nota.cpp(22) : error C2041: illegal digit '9' for base '8'
C:\bin\nota.cpp(22) : error C2146: syntax error : missing ';' before
identifier 'ninne'
C:\bin\nota.cpp(22) : error C2065: 'ninne' : undeclared identifier

you also misssed all the breaks out of your switch statement.

I can't see what "zero one" is supposed to mean in

case 01: cout << zero one;

wouldn't

case 01: cout << "zero one";

make more sense?

--
Nick Keighley


Jun 27 '08 #24
James Kanze wrote:
<snip>
I added it because I suspect that a lot of programmers forget to
test them. Just as they don't take into account that in most of
the world, the standard format for entering dates is dd/mm/YYYY.
(Or dd-mm-YYYY. Or, if you take into account ISO: YYYYmmdd.)
James,

I'm pretty sure, with a French sig., you aren't going to be one of the
people who assumes the world ends at the Rio Grande. But I've met an
awful lot of people who will check all the cases - even to the precise
1900-wasn't-but-2000-was-a-leap-year calculations - then forget to deal
with different human orders in dates.

All your points are good and valid; they just aren't the one I was
trying to make. We need *both* sets borne in mind. Perhaps I am
over-optimistic in assuming that leap years will be done correctly.

Andy
Jun 27 '08 #25
On May 13, 12:08 am, Andy Champ <no....@nospam.comwrote:
James Kanze wrote:
<snip>I added it because I suspect that a lot of programmers forget to
test them. Just as they don't take into account that in most of
the world, the standard format for entering dates is dd/mm/YYYY.
(Or dd-mm-YYYY. Or, if you take into account ISO: YYYYmmdd.)
I'm pretty sure, with a French sig., you aren't going to be
one of the people who assumes the world ends at the Rio
Grande. But I've met an awful lot of people who will check
all the cases - even to the precise
1900-wasn't-but-2000-was-a-leap-year calculations - then
forget to deal with different human orders in dates.
Interestingly, I think that the risk is actually greater here in
Europe. When you see that France, Germany, Italy and even the
United Kingdom do it the same way, it's easy to think that that
way is universal. Where as in the US, even the military use
day/month/year. (FWIW, I might add that in Europe, Monday is
the first day of the week, not Sunday. Which can also lead to
ambiguities.)

Anyhow, I think we basically agree. I was just reacting a bit
flippantly to your comment about being sure to test on a date
which was ambiguous---I think we can also both agree that there
are a lot of border cases in this domain which typically aren't
tested.
All your points are good and valid; they just aren't the one
I was trying to make. We need *both* sets borne in mind.
Perhaps I am over-optimistic in assuming that leap years will
be done correctly.
I think most code will depend on the standard library to get
that right, and presumably, it does. The special case I worry
most about is the switches between summer and winter time; will
the software behave correctly if there is no 2:30AM Sunday? Or
if there are two?

--
James Kanze (GABI Software) email:ja*********@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
Jun 27 '08 #26

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

20 posts views Thread by Sean McIlroy | last post: by
27 posts views Thread by fuch6921 | last post: by
15 posts views Thread by jaks.maths | last post: by
7 posts views Thread by Gary Brown | last post: by
10 posts views Thread by laurent.pauloin | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.