octal error

[notahipee]

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 .

 

[notahipee]

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.

 

[Default User]

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

 

[notahipee]

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;
}

 

[kwikius]

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

 

[Default User]

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

 

[kwikius]

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

 

[notahipee]

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.

 

[notahipee]

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)

 

[notahipee]

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.

 

[kwikius]

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

 

[Default User]

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

 

[notahipee]

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".

 

[Juha Nieminen]

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.

 

[Erik Wikström]

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.

 

[James Kanze]

[...]

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]

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]

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.)

 

[Nick Keighley]

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?

 

[James Kanze]

James Kanze wrote:

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?