won't compile, parse error?

C

Christopher

I am getting a parse error from g++ pointing at my catch line and can't
figure out whats wrong with this code:

#include "BigPosInt.h"
#include <iostream>
#include <new>
#include <assert.h>

BigPosInt::BigPosInt(int init_max_digits)
{
assert(init_max_digits > 0);

try
{
digitsArray = new int[init_max_digits];
}

catch(bad_alloc a)
{
const char* temp = a.what();
std::cout<<"\n\n"<<temp<<"\n";
std::cout<<"Insufficient free memory. \n\n";
}

// Postcondition: constructed BigPosInt has been initialized to
// represent the value 0 and can accommodate any
// BigPosInt that has up to init_max_digits digits
}

Any ideas?
thanx,
Christopher
 
A

Alf P. Steinbach

I am getting a parse error from g++ pointing at my catch line and can't
figure out whats wrong with this code:

#include "BigPosInt.h"
#include <iostream>
#include <new>
#include <assert.h>

Just to get into the habit try using <cassert> instead of <assert.h>.
Since 'assert' is a macro it's practically the same. But not for
other old C library headers.


BigPosInt::BigPosInt(int init_max_digits)

Here I would have used unsigned type for 'init_max_digits'. However,
about 50% (as far as I can determine) of the community disagrees.
The 50% or so who agree think that 'unsigned' communicates the
"must be non-negative" requirement more clearly.

{
assert(init_max_digits > 0);

For 'unsigned' you'd want to make this 'assert( init_max_digits <= INT_MAX )',
just to be on the safe side.

try
{
digitsArray = new int[init_max_digits];

Assuming 'digitsArray' is a member variable.
}

catch(bad_alloc a)

Make that 'catch( std::bad_alloc const& a )'

{
const char* temp = a.what();

You don't need a temp variable here.

std::cout<<"\n\n"<<temp<<"\n";
std::cout<<"Insufficient free memory. \n\n";

Remember to rethrow the exception!

You'd probably also be better off flushing std::cout here.


std::cout << std::flush;
throw;
}

// Postcondition: constructed BigPosInt has been initialized to
// represent the value 0 and can accommodate any
// BigPosInt that has up to init_max_digits digits

If you don't rethrow the exception you will violate that
postcondition in case of an exception.
 
C

Chris Johnson

I am getting a parse error from g++ pointing at my catch line and can't
figure out whats wrong with this code:
I'm not one to be nit-picky but you might want to past the complete
diagnostic error next time.
#include "BigPosInt.h"
#include <iostream>
#include <new>
#include <assert.h>

BigPosInt::BigPosInt(int init_max_digits)
{
assert(init_max_digits > 0);

try
{
digitsArray = new int[init_max_digits];
}

catch(bad_alloc a)
catch(std::bad_alloc a)
// I see no using namespace std::bad_alloc
// or using namespace std; etc..
{
const char* temp = a.what();
std::cout<<"\n\n"<<temp<<"\n";
std::cout<<"Insufficient free memory. \n\n";
}

// Postcondition: constructed BigPosInt has been initialized to
// represent the value 0 and can accommodate any
// BigPosInt that has up to init_max_digits digits
}

Any ideas?

There's one for ya
thanx,
Christopher
Hope that helps,
Chris Johnson
 
A

Attila Feher

Christopher said:
I am getting a parse error from g++ pointing at my catch line and
can't figure out whats wrong with this code:

#include "BigPosInt.h"
#include <iostream>
#include <new>
#include <assert.h>

BigPosInt::BigPosInt(int init_max_digits)
{
assert(init_max_digits > 0);

try
{
digitsArray = new int[init_max_digits];
}

catch(bad_alloc a)

catch(std::bad_alloc const &a)
 
A

Attila Feher

Alf P. Steinbach wrote:
[SNIP]
Here I would have used unsigned type for 'init_max_digits'. However,
about 50% (as far as I can determine) of the community disagrees.
The 50% or so who agree think that 'unsigned' communicates the
"must be non-negative" requirement more clearly.

Most of the platforms don't agree with you. They cannot allocate or address
more bytes than the maximum of std::ptrdiff_t, and std::ptrdiff_t is signed.
Remember to rethrow the exception!

You'd probably also be better off flushing std::cout here.

Why not simply use endl; above? Or better off cerr?
std::cout << std::flush;
throw;

Rethrowing is a good point.
 
C

Chris Johnson

catch(std::bad_alloc a)
// I see no using namespace std::bad_alloc
// or using namespace std; etc..
While I don't want to tear your code snippet apart
(you did ask a very specific question)
I want to correct something in my reply:

catch(std::bad_alloc const& a)

I think in the end run this is more what you will be after
although my original post 'should' remove your parse error

Other points of mention are things like
#include <cassert>
instead of
#include <assert.h>
as well as other things - I'm not trying to "beat you up" though
I am sure more posters will correct some other parts of your
code, none of it with malicious intent of course.

Chris Johnson
 
C

Chris Johnson

Christopher wrote:

catch(std::bad_alloc const &a)

Yes yes - I noticed that immediately after I sent it and I am kicking
myself over that one. Unfortunately I couldn't delete the post before
it went out. I got in a hurry and didn't catch I was not finished with
my editing. Oh well nothing like leaving my mark in history on USENET
that I sometimes toggle the idiot bit and leave a public record of it.

D'OH!

Chris Johnson
 
A

Alf P. Steinbach

Alf P. Steinbach wrote:
[SNIP]
Here I would have used unsigned type for 'init_max_digits'. However,
about 50% (as far as I can determine) of the community disagrees.
The 50% or so who agree think that 'unsigned' communicates the
"must be non-negative" requirement more clearly.

Most of the platforms don't agree with you. They cannot allocate or address
more bytes than the maximum of std::ptrdiff_t, and std::ptrdiff_t is signed.

Allocation error throws, too large or small range is not an issue here.

Why not simply use endl; above? Or better off cerr?

Right. Even better, not do debug i/o at that level. I considered
how much to write about it, and I think I chose a good level to
further progress. Otherwise there's even more to say.
Rethrowing is a good point.

All my points are good... ;-)
 
A

Attila Feher

Alf said:
Alf P. Steinbach wrote:
[SNIP]
BigPosInt::BigPosInt(int init_max_digits)

Here I would have used unsigned type for 'init_max_digits'.
However, about 50% (as far as I can determine) of the community
disagrees. The 50% or so who agree think that 'unsigned'
communicates the "must be non-negative" requirement more clearly.

Most of the platforms don't agree with you. They cannot allocate or
address more bytes than the maximum of std::ptrdiff_t, and
std::ptrdiff_t is signed.

Allocation error throws, too large or small range is not an issue
here.

IMHO it is. If you give an interface saying: I can do 32 and in practice
portably you can only do 16 (and portably mean eg: Windows cannot) this is
not OK. Also according to Bjarne just to rule out negative numbers you must
not use unsigned. According to Dan Saks using std::size_t will lead to
problems, since most implementations will not support it.

And for you short, IMHO arrogant reply about it being a non-issue: if you
prefer runtime errors over compile time errors (khm: warnings) then I think
there is not much to discuss.
Right. Even better, not do debug i/o at that level.

I see. So you prefer having a high level debug message saying "Something
went wrong somewhere"?
I considered how much to write about it,
and I think I chose a good level to
further progress. Otherwise there's even more to say.

Without knowing anything about the intent of the program snippet and its
context? What would those be?
All my points are good... ;-)

Except of the unsigned. It makes the interface communicate a lie on most
platforms and in addition to this moves a compile time detectable bug to
runtime.
 
A

Attila Feher

Chris Johnson wrote:
[SNIP]
my editing. Oh well nothing like leaving my mark in history on USENET
that I sometimes toggle the idiot bit and leave a public record of it.

Been there, done that. More times than I care to admit. But this is the
way we learn. We make mistakes. At least mine does not start a war or a
blackout of a country. :)
 
A

Alf P. Steinbach

Alf said:
Alf P. Steinbach wrote:
[SNIP]
BigPosInt::BigPosInt(int init_max_digits)

Here I would have used unsigned type for 'init_max_digits'.
However, about 50% (as far as I can determine) of the community
disagrees. The 50% or so who agree think that 'unsigned'
communicates the "must be non-negative" requirement more clearly.

Most of the platforms don't agree with you. They cannot allocate or
address more bytes than the maximum of std::ptrdiff_t, and
std::ptrdiff_t is signed.

Allocation error throws, too large or small range is not an issue
here.

IMHO it is. If you give an interface saying: I can do 32 and in practice
portably you can only do 16 (and portably mean eg: Windows cannot) this is
not OK. Also according to Bjarne just to rule out negative numbers you must
not use unsigned. According to Dan Saks using std::size_t will lead to
problems, since most implementations will not support it.

And for you short, IMHO arrogant reply about it being a non-issue: if you
prefer runtime errors over compile time errors (khm: warnings) then I think
there is not much to discuss.

I think you're trolling again.

I see. So you prefer having a high level debug message saying "Something
went wrong somewhere"?

I think you're trolling again.

Without knowing anything about the intent of the program snippet and its
context?

I think you're trolling again.


What would those be?

For one thing, the stated postcondition has a logical value for the
constructed object; if the class has just one possible logical value it's
meaningless, and otherwise some initialization seems to be required.

For another, it is generally a good idea to use std::vector instead of a
raw array, especially for a novice.



Except of the unsigned. It makes the interface communicate a lie on most
platforms and in addition to this moves a compile time detectable bug to
runtime.

I think you're trolling again.
 
W

WW

Alf said:
Alf said:
On Wed, 24 Sep 2003 07:49:33 +0300, "Attila Feher"

Alf P. Steinbach wrote:
[SNIP]
BigPosInt::BigPosInt(int init_max_digits)

Here I would have used unsigned type for 'init_max_digits'.
However, about 50% (as far as I can determine) of the community
disagrees. The 50% or so who agree think that 'unsigned'
communicates the "must be non-negative" requirement more clearly.

Most of the platforms don't agree with you. They cannot allocate
or
address more bytes than the maximum of std::ptrdiff_t, and
std::ptrdiff_t is signed.

Allocation error throws, too large or small range is not an issue
here.

IMHO it is. If you give an interface saying: I can do 32 and in
practice
portably you can only do 16 (and portably mean eg: Windows cannot)
this is
not OK. Also according to Bjarne just to rule out negative numbers
you must
not use unsigned. According to Dan Saks using std::size_t will lead
to
problems, since most implementations will not support it.

And for you short, IMHO arrogant reply about it being a non-issue:
if you
prefer runtime errors over compile time errors (khm: warnings) then
I think
there is not much to discuss.

I think you're trolling again.

You start with a lie: I think.
I think you're trolling again.

You start with a lie: I think.
I think you're trolling again.

You start with a lie: I think.

If you don't know what to answer, just don't answer. As I have told you
already I do not appreciate your arrogant and annoying comments. It seems
that since you once did a review for Andrei you think that you are the only
one here who is allowed to express an opinion. This won't help anyone.
For one thing, the stated postcondition has a logical value for the
constructed object; if the class has just one possible logical value
it's meaningless,

Meaningless. That is what the above is for me. Could you explain what do
you mean by that? The default constructor (is supposed to) initialize the
object to represent 0. What is wrong with that? What other postcondition
could there be? Throwing the exception?

I am afraid to say since all you do is call me a troll nowadays but you seem
to be closer and closer to Terekhov. You seem to love giving an answer what
only 1% of the living can understand. Do you want to pick a fight? Why do
you post at all if you don't care to answer the question straight? I really
don't get what is good in this one. It seems to be a waste of time, both
mine and yours.
and otherwise some initialization seems to be required.

Do you mean setting the integers to zero?
For another, it is generally a good idea to use std::vector instead
of a raw array, especially for a novice.

That is one I can agree with.
I think you're trolling again.

You think wrong again. So Bjarne Stroustrup, Dan Saks are both trolls in
your not so humble opinion, yes? Alf get a life.
 
A

Alf P. Steinbach

Alf said:
Alf P. Steinbach wrote:
On Wed, 24 Sep 2003 07:49:33 +0300, "Attila Feher"

Alf P. Steinbach wrote:
[SNIP]
BigPosInt::BigPosInt(int init_max_digits)

Here I would have used unsigned type for 'init_max_digits'.
However, about 50% (as far as I can determine) of the community
disagrees. The 50% or so who agree think that 'unsigned'
communicates the "must be non-negative" requirement more clearly.

Most of the platforms don't agree with you. They cannot allocate
or
address more bytes than the maximum of std::ptrdiff_t, and
std::ptrdiff_t is signed.

Allocation error throws, too large or small range is not an issue
here.

IMHO it is. If you give an interface saying: I can do 32 and in
practice
portably you can only do 16 (and portably mean eg: Windows cannot)
this is
not OK. Also according to Bjarne just to rule out negative numbers
you must
not use unsigned. According to Dan Saks using std::size_t will lead
to
problems, since most implementations will not support it.

And for you short, IMHO arrogant reply about it being a non-issue:
if you
prefer runtime errors over compile time errors (khm: warnings) then
I think
there is not much to discuss.

I think you're trolling again.

You start with a lie: I think.

I must ask as Alexander did, but not as politely: have you gone off
your rockers?
 
W

WW

Alf said:
I must ask as Alexander did, but not as politely: have you gone off
your rockers?

Not really. But I am a basically good person. So I thought if you make a
flame bait it is flame what you want.

That's all? For that you have wasted a whole, unsnipped post? I thought
you might lower yourself down to an everyday person like me and explain what
did you mean by your innuendo:
 
A

Alf P. Steinbach

Not really. But I am a basically good person. So I thought if you make a
flame bait it is flame what you want.

That's all? For that you have wasted a whole, unsnipped post? I thought
you might lower yourself down to an everyday person like me and explain what
did you mean by your innuendo: ^^^^^^^^

Stated postcondition:


// Postcondition: constructed BigPosInt has been initialized to
// represent the value 0 and can accommodate any
// BigPosInt that has up to init_max_digits digits


Code to achieve that postcondition:


digitsArray = new int[init_max_digits];


'digitsArray' is not guaranteed to be zero-initialized. §5.3.4/15, for
this case: "the object created has indeterminate value". An indeterminate
value can work if and only if the object has only one possible logical value.

There is no other code in the constructor that affects object members.


Hth.,

- Alf
 
W

WW

Alf said:
Stated postcondition:


// Postcondition: constructed BigPosInt has been initialized to
// represent the value 0 and can accommodate any
// BigPosInt that has up to init_max_digits
digits


Code to achieve that postcondition:


digitsArray = new int[init_max_digits];


'digitsArray' is not guaranteed to be zero-initialized. §5.3.4/15,
for
this case: "the object created has indeterminate value". An
indeterminate value can work if and only if the object has only one
possible logical value.

There is no other code in the constructor that affects object members.

OK. You meant that. Full sentence:
"For one thing, the stated postcondition has a logical value for the
constructed object; if the class has just one possible logical value it's
meaningless, and otherwise some initialization seems to be required."

Note:

"and otherwise some initialization seems to be required"

So I was thinking that since the initialization is on the "otherwise", in
this context "in addition to all this" part, it means you wanted to say
something else as well. What did I misunderstand?
 
A

Alf P. Steinbach

Alf said:
For one thing, the stated postcondition has a logical value for the
constructed object; if the class has just one possible logical value
it's meaningless,

Stated postcondition:


// Postcondition: constructed BigPosInt has been initialized to
// represent the value 0 and can accommodate any
// BigPosInt that has up to init_max_digits
digits


Code to achieve that postcondition:


digitsArray = new int[init_max_digits];


'digitsArray' is not guaranteed to be zero-initialized. §5.3.4/15,
for
this case: "the object created has indeterminate value". An
indeterminate value can work if and only if the object has only one
possible logical value.

There is no other code in the constructor that affects object members.

OK. You meant that. Full sentence:
"For one thing, the stated postcondition has a logical value for the
constructed object; if the class has just one possible logical value it's
meaningless, and otherwise some initialization seems to be required."

Note:

"and otherwise some initialization seems to be required"

So I was thinking that since the initialization is on the "otherwise", in
this context "in addition to all this" part, it means you wanted to say
something else as well. What did I misunderstand?

Regarding the terminology: "in addition" was not implied. "Otherwise"
referred to "if the object has more than one possible logical value".
That being the logical other case in this context.

But then, as always, it's practically impossible to cover all cases in a
short Usenet message.

For example, I can imagine (extremely unlikely, but theoretically possible)
that the object has a member


SmartInt length;


with a constructor that initializes it to logical zero... ;-)
 
W

WW

Alf P. Steinbach wrote:
[SNIP]
For example, I can imagine (extremely unlikely, but theoretically
possible) that the object has a member

SmartInt length;

with a constructor that initializes it to logical zero... ;-)

Yeah. As much as we saw from the class declaration it might not even use
digitsArray anywhere else. :)
 
J

jeffc

Alf P. Steinbach said:
Regarding the terminology: "in addition" was not implied. "Otherwise"
referred to "if the object has more than one possible logical value".
That being the logical other case in this context.

But then, as always, it's practically impossible to cover all cases in a
short Usenet message.

Neither snow nor rain nor heat nor gloom of night stays the Pedant Man from
the swift completion of his appointed rounds!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top