mixed-sign arithmetic and auto - c++

In article <jOednULrFowOLQ_anZ2dnUVZ_tGonZ2d@comcast.com>,
walter@digitalmars-nospamm.com says...
> Jerry Coffin wrote:
> > A design like you're advocating
> > that makes it easy for a bug to exist for years before it's even noticed
> > almost inevitably _increases_ engineering costs by a huge margin.
>
> You're the first I've ever heard claim that undefined behavior reduces
> bugs, even by a "huge margin". I think it's an extraordinary claim.

The fact that it's undefined behavior, per se, isn't what reduces bugs.
If, for example, all math was checked and all integer overflows were
guaranteed to throw exceptions, it would accomplish much the same thing.

My list failure modes from most to least desirable:

1) guaranteed to reported at compile time
2) guaranteed to be reported at run time
3) likely to be reported at run time
4) likely to be noticed quickly
5) unlikely to be noticed quickly

If there's a truly extraordinary claim, it's that any halfway competent
programmer seeing different results from integer computations on
identical inputs could possibly help _immediately_ knowing that the code
must have a problem.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jerry Coffin wrote:
> In article <VcCdnXHUFaFTmg_anZ2dnUVZ8ternZ2d@eclipse.net.uk>,
> francis.glassborow@btinternet.com says...
>
> [ ... ]
>
>> Actually there are several Core TRs waiting in the wings (for example as
>> soon as we have done with C++0x we will start work on the Modules
>> proposal) Outr present thinking is that we will ship a revised version
>> of C++0x much sooner than 12 years from now. This may be through a
>> normative addendum or some other means but we do not intend leaving
>> several good ideas sitting on the back boiler just because we have too
>> much to do to meet the 2009 deadline.
>
> Okay -- frankly, I'm glad to hear that. Having read through the modules
> proposal (for one) I think it would be a shame to leave it sitting for
> too long. At the same time, I believe the ISO rules are that the soonest
> any real change (i.e. more than fixing obvious typos and such) can
> happen is 5 years after the standard is finalized, which probably means
> close to seven years from now anyway.
>

I could be wrong, but I think the rule is the other way around:
WG21 has *at most* 5 years after issuing a standard to state its
intention with respect to revising, reaffirming or withdrawing
that standard. But I'm no expert on ISO procedures, and this
question is probably best addressed on comp.std.c++.

-- James

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Walter Bright wrote:
> Jerry Coffin wrote:
>> A design like you're advocating
>> that makes it easy for a bug to exist for years before it's even noticed
>> almost inevitably _increases_ engineering costs by a huge margin.
>
> You're the first I've ever heard claim that undefined behavior reduces
> bugs, even by a "huge margin". I think it's an extraordinary claim.

It's likely true. Defining behavior exactly often masks bugs,
which more diversity in behavior brings to light. (Sometimes
the other way around works, but not as often as you would like
to believe.)

-- James

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jerry Coffin wrote:
> First of all, there seems to be at
> least one entirely standard way of dealing with the problem.

Sure. And one could do 64 bit double emulation in a D implementation, too.

> Second, although many programmers may _expect_ double to be a 64-bit
> type, that's most assuredly NOT required by the C++ standard. The
> standard requires that double (and long double) support magnitudes up to
> 1E+37, and requires a minimum of 10 decimal digits of precision. Meeting
> those requirements does NOT require 64 bits, or even very close to it --
> using the usual form for a floating point number, it requires about 42
> bits altogether.

My mistake, I was wrong about that. You are correct. But the point is
moot, as the SHARC only has 32 bit hardware floating point available,
not 42. Emulation is required to be standard conforming.


>> "The long long int data type is not supported."
>> Oh well, no 64 bit data! because you can dispense with 64 bit ints and
>> still call a C++ compiler "standard conforming." Fortunately, C++0x will
>> fix that oversight.
> That was hardly an oversight. It was (heavily) debated at the time.

Doesn't matter, C++ still doesn't support it, and neither does the SHARC
C++ compiler.


> The fact remains that one of the strengths of C++ is reasonable support
> for user-defined data types -- and a larger integer type than supported
> by the hardware (or at least the language) certainly qualifies.

The C++ committee recognized that C++ is short on basic types, and
proposed several new ones proposed for C++0x (long long, unsigned long
long, char16_t and char32_t). User defined types are not good enough.

--------
Walter Bright
http://www.digitalmars.com
C, C++, D programming language compilers

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jerry Coffin wrote:
> In article <VcCdnXHUFaFTmg_anZ2dnUVZ8ternZ2d@eclipse.net.uk>,
> francis.glassborow@btinternet.com says...
>
> [ ... ]
>
>> Actually there are several Core TRs waiting in the wings (for example as
>> soon as we have done with C++0x we will start work on the Modules
>> proposal) Outr present thinking is that we will ship a revised version
>> of C++0x much sooner than 12 years from now. This may be through a
>> normative addendum or some other means but we do not intend leaving
>> several good ideas sitting on the back boiler just because we have too
>> much to do to meet the 2009 deadline.
>
> Okay -- frankly, I'm glad to hear that. Having read through the modules
> proposal (for one) I think it would be a shame to leave it sitting for
> too long. At the same time, I believe the ISO rules are that the soonest
> any real change (i.e. more than fixing obvious typos and such) can
> happen is 5 years after the standard is finalized, which probably means
> close to seven years from now anyway.
>

Well that isn't AFAIU an actual rule but a consequence of the time it
takes for various necessary votes. However a normative addendum can be
processed faster. We have been thinking of a revised standard for about
2012/3

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

James Dennett wrote:
> Walter Bright wrote:
>> Jerry Coffin wrote:
>>> A design like you're advocating
>>> that makes it easy for a bug to exist for years before it's even noticed
>>> almost inevitably _increases_ engineering costs by a huge margin.
>>
>> You're the first I've ever heard claim that undefined behavior reduces
>> bugs, even by a "huge margin". I think it's an extraordinary claim.
>
> It's likely true.

Sorry, I'm not buying it. How many bugs have you found in your code that
were exposed by UB that would still have been bugs without UB? I can't
think of one in mine in 25 years of programming, let alone a "huge
margin" of them.


> Defining behavior exactly often masks bugs,
> which more diversity in behavior brings to light. (Sometimes
> the other way around works, but not as often as you would like
> to believe.)

I've never seen a language proposal to add UB to improve robustness,
either. Not for any language.

--------
Walter Bright
http://www.digitalmars.com
C, C++, D programming language compilers

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Walter Bright wrote:
> James Dennett wrote:
>> Walter Bright wrote:
>>> Jerry Coffin wrote:
>>>> A design like you're advocating
>>>> that makes it easy for a bug to exist for years before it's even
>>>> noticed
>>>> almost inevitably _increases_ engineering costs by a huge margin.
>>>
>>> You're the first I've ever heard claim that undefined behavior reduces
>>> bugs, even by a "huge margin". I think it's an extraordinary claim.
>>
>> It's likely true.
>
> Sorry, I'm not buying it. How many bugs have you found in your code that
> were exposed by UB that would still have been bugs without UB?

Hundreds, at a guess. Bugs that have been hidden when porting
between similar compilers/platforms but were exposed by others.
If the defined behavior had been that of the common platforms,
the bugs would have stayed hidden. Running tests across a wide
variety of platforms has brought to light many, many latent bugs.
As you yourself acknowledge, no test suite for a complex system
is complete; running it in different configurations across
platforms which have different behaviours helps to fill in some
of the gaps.

> I can't
> think of one in mine in 25 years of programming, let alone a "huge
> margin" of them.

Your experience and mine differ. That's one reason why a committee
*can* produce a more widely applicable language -- it has vastly
more diverse experience to all on than any one individual. (You
have me beaten on length of programming experience; I started only
24 years ago by my count.)

-- James

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

In article <47930F5C.1000309@digitalmars-nospamm.com>,
walter@digitalmars-nospamm.com says...

[ ... ]

> > The fact remains that one of the strengths of C++ is reasonable support
> > for user-defined data types -- and a larger integer type than supported
> > by the hardware (or at least the language) certainly qualifies.
>
> The C++ committee recognized that C++ is short on basic types, and
> proposed several new ones proposed for C++0x (long long, unsigned long
> long, char16_t and char32_t). User defined types are not good enough.

That seems to be open to some question. Most, if not all, of these types
were added in the C99 standard. One of the openly stated goals of C++
has been to retain the highest reasonable degree of compatibility with
C. As such, the only way any of these types was likely to be rejected
would be if they created a conflict.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

James Dennett wrote:
> Walter Bright wrote:
>> James Dennett wrote:
>>> Walter Bright wrote:
>>>> Jerry Coffin wrote:
>>>>> A design like you're advocating
>>>>> that makes it easy for a bug to exist for years before it's even
>>>>> noticed
>>>>> almost inevitably _increases_ engineering costs by a huge margin.
>>>>
>>>> You're the first I've ever heard claim that undefined behavior reduces
>>>> bugs, even by a "huge margin". I think it's an extraordinary claim.
>>>
>>> It's likely true.
>>
>> Sorry, I'm not buying it. How many bugs have you found in your code that
>> were exposed by UB that would still have been bugs without UB?
>
> Hundreds, at a guess. Bugs that have been hidden when porting
> between similar compilers/platforms but were exposed by others.
> If the defined behavior had been that of the common platforms,
> the bugs would have stayed hidden. Running tests across a wide
> variety of platforms has brought to light many, many latent bugs.
> As you yourself acknowledge, no test suite for a complex system
> is complete; running it in different configurations across
> platforms which have different behaviours helps to fill in some
> of the gaps.

Sorry, I'm not buying it either. This is circular logic as it only works
for a self-serving definition of a bug ("forgetting to code around an UB
properly").

I don't think it should be necessary to argue the bads of UB in this
forum. It can only mean the discussion has meandered to a point where
some fundamentals have been forgotten for the sake of the argument.

(I have some family friends who've had a son-in-law imprisoned. Our
families got to talk about it during a party, and the man's
mother-in-law said that he's doing great, he's in charge with the radio
amd TV broadcast for the prison, he's getting good food, preferential
visits, the works. She was very cheery about it all. It all sounded
great, but my Dad put the finger on the issue. He said: "Wait a
minute... she makes it sound like it's good to be in prison.")

So wait a minute there. Undefined behavior is not good. We understand
the necessity to tolerate it "for the greater good" (to quote a funny
British movie), but it's not good.


Andrei


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]