A fatal exception

[Developwebsites]

A fatal exception 0E has occurred at 0028:C027B6DC in VXD VWIN32(04)+00001088.
The current application will be terminated.

Same program below run in DOS does not crash.


#include<iostream>
#include<iomanip>

int numb_cities=0;
const int MAX = 120;

class Cities {
private:
char cityname[MAX][MAX];//an array of 120 cities.
int temp[MAX];

public:
Cities();
void output();
};

Cities:: Cities()
{
char y_n;
do{
cout<<"\n\n";
cout<<"Please enter name of city: ";
cin>>cityname[numb_cities];
cout<<"\nPlease enter temp: ";
cin>>temp[numb_cities];
numb_cities++;
cout<<"\nAnother city?(Y/N)";
cin>>y_n;
}while(y_n =='y' || y_n =='Y');
cout<<"\n\n";
}

void Cities:utput()
{
cout<<"\n"<<"name of city"
<<" temperature"
<<"\n";
for(int t=0;t<numb_cities;t++)
{
cout<<setw(5)<<cityname[t]<<setw(15)<<temp[t]<<"\n";
}
}//close output

int main()
{
Cities info;
info.output();
return 0;
}

 

[Ron Natalie]

int numb_cities=0;

Why is this a global variable if you are going to use it to
count the number of cityname's input into a single object.
If you ever have more than one City object, this is not going
to work.

char cityname[MAX][MAX];//an array of 120 cities.

What do you have against strings?

But all that being said, I don't know why it crashes....
Did you try a debugger.

 

[Alan Morgan]

A fatal exception 0E has occurred at 0028:C027B6DC in VXD VWIN32(04)+00001088.
The current application will be terminated.

What input did you use? Did the program crash immediately or did it crash when
you entered in the city name or was it when you entered in the temperature or
was it when you entered in Y or N?

I can think of a couple of reasons why the program might crash, but you haven't
given enough information to determine which one it is.

Have you tried using a debugger? Have you tried putting trace statements in the
code to figure out what is going wrong? Do you know which line is causing the
problem?

Alan

 

[Developwebsites]

What input did you use? Did the program crash immediately or did it crash

when

the program compiled but crashed right when I tried to run it; did not have a
chance to enter input.

 

[Jerry Coffin]

A fatal exception 0E has occurred at 0028:C027B6DC in VXD VWIN32(04)+00001088.
The current application will be terminated.

Sounds like you're using Windows 95 or its ilk -- the crash is more
likely due to the OS than your program.

#include<iostream>
#include<iomanip>

Well, it's nice to see that at least you've fixed _something_ since you
posted the same thing 12 days ago.

int numb_cities=0;
const int MAX = 120;

class Cities {
private:
char cityname[MAX][MAX];//an array of 120 cities.
int temp[MAX];

In the previous thread I recommended using a vector of strings. I'll
repeat that recommendation now. I'll also recommend that you upgrade
your OS -- it sounds like the problems you're seeing at the moment are
due more to a screwup in your OS than in your own code.

 

[Thomas Matthews]

A fatal exception 0E has occurred at 0028:C027B6DC in VXD VWIN32(04)+00001088.
The current application will be terminated.

Same program below run in DOS does not crash.


#include<iostream>
#include<iomanip>

int numb_cities=0;
const int MAX = 120;

class Cities {
private:
char cityname[MAX][MAX];//an array of 120 cities.

As others have said:

int temp[MAX];

Any temporary variables should be declared and used
within a method or function.

public:
Cities();
void output();
};

A style suggestion: Place public declarations first
because these are the items that the users of your
class will want to know. They won't want to scroll
through a list of private and protected stuff just
to get to the public area.

Cities:: Cities()
{
char y_n;
do{
cout<<"\n\n";
cout<<"Please enter name of city: ";
cin>>cityname[numb_cities];
cout<<"\nPlease enter temp: ";

What is temp? A number, string, letter?

cin>>temp[numb_cities];
numb_cities++;
cout<<"\nAnother city?(Y/N)";
cin>>y_n;
}while(y_n =='y' || y_n =='Y');

See also std::toupper or std::tolower
while (std::toupper(y_n) == 'Y')

cout<<"\n\n";

I highly suggest you do not perform I/O in the constructor
of an object. Some objects _may_ be constructed before
the I/O stream. A better thing to do is to have an
input method and place that in your main() function.

}

void Cities:utput()
{
cout<<"\n"<<"name of city"
<<" temperature"
<<"\n";
for(int t=0;t<numb_cities;t++)
{
cout<<setw(5)<<cityname[t]<<setw(15)<<temp[t]<<"\n";
}
}//close output

int main()
{
Cities info;
info.output();
return 0;
}

Why do we care if your E-mail is shut off?
You post here. We respond here.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[Jerry Coffin]

[ ... ]

A style suggestion: Place public declarations first
because these are the items that the users of your
class will want to know. They won't want to scroll
through a list of private and protected stuff just
to get to the public area.

While I realize this idea is widely parroted, I (for one) am willing to
go on record as saying that it's a _bad_ idea. First of all, the public
interface should be _documented_, not gleaned from the declaration, so
the idea is only relevant if everything involved is a complete and utter
mess from beginning to end.

Second, anything has to be declared before use, therefore if you have
screwed up so badly that somebody is scrolling through code to find the
declaration, they're probably scrolling UP to find it -- so they'll find
it first if it's at the end of the declaration.

Third, if your declaration is sufficiently large and complex that any of
this makes any difference in finding the public parts of the class, then
moving declarations around is basically applying a small band-aid in a
situation where major surgery is what's really needed.

Finally, this style leads to bugs.

class X {
public:
// public stuff

// private stuff
};

and you've forgotten to put the "private:" before the private parts of
the class, so now everything is public. The compiler can't catch a
problem, because it doesn't see anything wrong. A user doesn't know
that you intended some particular part to be private, so he breaks the
encapsulation you intended to have.

Now, you can say that this could only happen if you're declaring a class
that's FAR too large -- and I'd agree. But I'd also point out that only
in such a case would your "solution" become useful anyway.

In fact, I'd say the point at which the class should be refactored is
LOWER than the point at which position of declarations would have a hope
of doing anything useful. IOW, your idea is useful only as a way of
preventing really bad code from getting fixed.

 

[Mike Wahler]

[ ... ]

A style suggestion: Place public declarations first
because these are the items that the users of your
class will want to know. They won't want to scroll
through a list of private and protected stuff just
to get to the public area.

While I realize this idea is widely parroted, I (for one) am willing to
go on record as saying that it's a _bad_ idea. First of all, the public
interface should be _documented_, not gleaned from the declaration, so
the idea is only relevant if everything involved is a complete and utter
mess from beginning to end.

Second, anything has to be declared before use, therefore if you have
screwed up so badly that somebody is scrolling through code to find the
declaration, they're probably scrolling UP to find it -- so they'll find
it first if it's at the end of the declaration.

Third, if your declaration is sufficiently large and complex that any of
this makes any difference in finding the public parts of the class, then
moving declarations around is basically applying a small band-aid in a
situation where major surgery is what's really needed.

Finally, this style leads to bugs.

class X {
public:
// public stuff

// private stuff
};

and you've forgotten to put the "private:" before the private parts of
the class, so now everything is public. The compiler can't catch a
problem, because it doesn't see anything wrong. A user doesn't know
that you intended some particular part to be private, so he breaks the
encapsulation you intended to have.

Now, you can say that this could only happen if you're declaring a class
that's FAR too large -- and I'd agree. But I'd also point out that only
in such a case would your "solution" become useful anyway.

In fact, I'd say the point at which the class should be refactored is
LOWER than the point at which position of declarations would have a hope
of doing anything useful. IOW, your idea is useful only as a way of
preventing really bad code from getting fixed.

I'll throw in my two cents here:

I define my classes like so:

class C
{
/* types (class, enum, typedef, forward decls, etc.) */

/* data members */

/* functions */

public:
/* types */

/* data members (I try to avoid public ones, however */

/* ctors, dtor, assignment op */

/* other functions */
};

My rationale is that when I write:
class C {

it *means* "what follows is private, until I specify
otherwise.

Of course this is only a style/opinion issue.
IMO a more important aspect is consistency
(within the class definitions, as well as among
them).

-Mike

 

[lilburne]

Of course this is only a style/opinion issue.
IMO a more important aspect is consistency
(within the class definitions, as well as among
them).

You can also script the style up so that all someone needs
to do is enter a command like:

make_class -header myNewClassName

which produces a default class header with various bits
filled in like default ctor and dtor, assignment and copy
ctor (in private section of course), class validity object,
etc. Encourages conformity to a standard layout.

 

[Mike Wahler]

You can also script the style up so that all someone needs
to do is enter a command like:

make_class -header myNewClassName

which produces a default class header with various bits
filled in like default ctor and dtor, assignment and copy
ctor (in private section of course), class validity object,
etc. Encourages conformity to a standard layout.

Encourages laziness. No thanks.

And I don't want 'dummy' member functions written
(e.g. ctors) when I don't need to define them at all.
Nor do I want to have to delete them after the fact.

I like to actually 'pay attention' to what I'm doing
when creating a class definition.

$.02
-Mike

 

[lilburne]

Encourages laziness. No thanks.

And I don't want 'dummy' member functions written
(e.g. ctors) when I don't need to define them at all.
Nor do I want to have to delete them after the fact.

I like to actually 'pay attention' to what I'm doing
when creating a class definition.

Well no one forces anyone to use the scripts, they can type
the each character themselves if they want.

But the resulting layout *will* conform to the house rules,
there *will* be a justification provided for why compiler
generated default functions have been allowed, or why there
are copy ctors and assignment operators, and there *will* be
a justification for why the class validity checker is
missing, otherwise the code will rejected when submitted for
integration.