By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,956 Members | 1,457 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,956 IT Pros & Developers. It's quick & easy.

won't compile, parse error?

P: n/a
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
Jul 19 '05 #1
Share this Question
Share on Google+
19 Replies


P: n/a
On Wed, 24 Sep 2003 04:17:17 GMT, "Christopher" <cp***@austin.rr.com> wrote:
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.
}


Jul 19 '05 #2

P: n/a
In article <hV********************@twister.austin.rr.com>, Christopher wrote:
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
--
echo "qr*********@rkpvgr.pbz" | rot13
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Jul 19 '05 #3

P: n/a
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.
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.


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


Rethrowing is a good point.

--
Attila aka WW
Jul 19 '05 #4

P: n/a
Christopher wrote:
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)

--
Attila aka WW
Jul 19 '05 #5

P: n/a
In article <sl*********************@gestalt.localdomain>, Chris Johnson wrote:
In article <hV********************@twister.austin.rr.com>, Christopher wrote:
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
--
echo "qr*********@rkpvgr.pbz" | rot13
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Jul 19 '05 #6

P: n/a
In article <bk**********@newstree.wise.edt.ericsson.se>, Attila Feher wrote:
Christopher wrote:

catch(std::bad_alloc const &a)

--
Attila aka WW


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
--
echo "qr*********@rkpvgr.pbz" | rot13
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Jul 19 '05 #7

P: n/a
On Wed, 24 Sep 2003 07:49:33 +0300, "Attila Feher" <at**********@lmf.ericsson.se> wrote:
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.

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.


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.
std::cout << std::flush;
throw;


Rethrowing is a good point.


All my points are good... ;-)

Jul 19 '05 #8

P: n/a
Alf P. Steinbach wrote:
On Wed, 24 Sep 2003 07:49:33 +0300, "Attila Feher"
<at**********@lmf.ericsson.se> wrote:
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.
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.


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


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?
std::cout << std::flush;
throw;


Rethrowing is a good point.


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.

--
Attila aka WW
Jul 19 '05 #9

P: n/a
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. :-)

--
Attila aka WW
Jul 19 '05 #10

P: n/a
On Wed, 24 Sep 2003 09:01:44 +0300, "Attila Feher" <at**********@lmf.ericsson.se> wrote:
Alf P. Steinbach wrote:
On Wed, 24 Sep 2003 07:49:33 +0300, "Attila Feher"
<at**********@lmf.ericsson.se> wrote:
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.

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

Why not simply use endl; above? Or better off cerr?
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 think you're trolling again.

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?


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.

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

Rethrowing is a good point.


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.


I think you're trolling again.

Jul 19 '05 #11

P: n/a
WW
Alf P. Steinbach wrote:
On Wed, 24 Sep 2003 09:01:44 +0300, "Attila Feher"
<at**********@lmf.ericsson.se> wrote:
Alf P. Steinbach wrote:
On Wed, 24 Sep 2003 07:49:33 +0300, "Attila Feher"
<at**********@lmf.ericsson.se> wrote:

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

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

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 think you're trolling again.


You start with a lie: I think.
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?


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


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.
> std::cout << std::flush;
> throw;

Rethrowing is a good point.

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.


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.

--
WW aka Attila
Jul 19 '05 #12

P: n/a
On Wed, 24 Sep 2003 17:21:57 +0300, "WW" <wo***@freemail.hu> wrote:
Alf P. Steinbach wrote:
On Wed, 24 Sep 2003 09:01:44 +0300, "Attila Feher"
<at**********@lmf.ericsson.se> wrote:
Alf P. Steinbach wrote:
On Wed, 24 Sep 2003 07:49:33 +0300, "Attila Feher"
<at**********@lmf.ericsson.se> wrote:

> 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?
>>> 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.
>
> Why not simply use endl; above? Or better off cerr?

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 think you're trolling again.


You start with a lie: I think.
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?


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


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.
>> std::cout << std::flush;
>> throw;
>
> Rethrowing is a good point.

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.


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.

--
WW aka Attila


Jul 19 '05 #13

P: n/a
WW
Alf P. Steinbach wrote:
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?


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:
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,


--
WW aka Attila
Jul 19 '05 #14

P: n/a
On Wed, 24 Sep 2003 17:40:14 +0300, "WW" <wo***@freemail.hu> wrote:
Alf P. Steinbach wrote:
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?


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:

^^^^^^^^
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.
Hth.,

- Alf

Jul 19 '05 #15

P: n/a
WW
Alf P. Steinbach wrote:
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?

--
WW aka Attila
Jul 19 '05 #16

P: n/a
On Wed, 24 Sep 2003 17:59:42 +0300, "WW" <wo***@freemail.hu> wrote:
Alf P. Steinbach wrote:
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... ;-)

Jul 19 '05 #17

P: n/a
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. :-)

--
WW aka Attila
Jul 19 '05 #18

P: n/a

"Alf P. Steinbach" <al***@start.no> wrote in message
news:3f***************@News.CIS.DFN.DE...

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!
Jul 19 '05 #19

P: n/a
jeffc wrote:
Neither snow nor rain nor heat nor gloom of night stays the Pedant
Man from the swift completion of his appointed rounds!


Stop trolling!

--
Attila aka WW
Jul 19 '05 #20

This discussion thread is closed

Replies have been disabled for this discussion.