«

* Greg Herlihy:
> On 3/5/07 9:14 AM, in article , "Alf P.
> Steinbach" <> wrote:
>
>> * Greg Herlihy:
>>> I think that a better compiler would have the asserts turned off. The
>>> point here is that a more thoroughly-tested compiler would see no
>>> benefit from shipping with its asserts enabled. Shipping a program
>>> with asserts enabled can only mean that the software has not been
>>> adequately tested. So in this case, anyone who uses g++ is
>>> effectively participates in the product's QA.
>>>
>>> And while such an arrangement may be reasonable for a free product
>>> like g++, it probably won't fly for those who program with a $500 C++
>>> compiler.
>> As they say, that's not even wrong. $500-compilers do produce Internal
>> Compiler Errors. And g++'s free support is superior to e.g. Microsoft's
>> non-existent free support.
>
> I see you disagree with several points that are not in my post, but it would
> be interesting to know whether you take issue with anything that I actually
> wrote. After all, I offered no opinion whether a $500 compiler crashes any
> less often than a free C++ compiler - only that some who spends $500 on a
> compiler (such as the Intel compiler) but be expecting something different
> than would expect from a free compiler.

Insights into people's actual expectations are probably better discussed
in an ESP or psychology group.


[snip]
> I have used commercial programs - but I never remember using a shipping
> version of a commercial program that had its asserts enabled. And until
> programmers start writing software that does not fail often enough, I doubt
> I'll be seeing asserts in shipping commercial software anytime soon.

The commercial version of MSVC is one commercial compiler (in the price
range you mention, the 7.1 version with documentation was about 13.000
NKr) that ships with asserts enabled -- it ICEs regularly.

For that matter, even Windows Explorer, the Windows GUI, ships with
asserts, or an equivalent mechanism, enabled, doing a report-and-restart
when it crashes.

For an honest and competent developer it's lunacy to turn off asserts.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On 6 Mar, 07:27, Greg Herlihy <gre...@pacbell.net> wrote:
> Who would prefer to have a PlayStation II
> game abort because of a failed assert? How likely is it that debugging the
> assert failure would be more popular than playing the games itself?

You're still missing the point of assert. assert is used to identify
bugs. You do not reduce the number of bugs or the probability that a
user will encounter one just by removing your bug identification tool.
What you change is the outcome *if* a bug is encountered. You seem to
be suggesting:

Option 1: Leave bug identification in and annoy users when it
identifies one.
Option 2: Take bug identification out so that users can continue to
use the software even in the presence of bugs.

That's nonsense. The choice is:

Option 1: Leave bug identification in.
1a. If no bug is encountered, the software continues to work.
1b. If a bug is encountered, the user is made aware that their
software does not work and its behaviour can not be relied upon in to
do what they were trying to do.

Option 2: Take bug identification out.
2a. If no bug is encountered, the software continues to work.
2.b If a bug is encountered, the behaviour of the software is not
reliable but the user may have no way of knowing that and may be
relying on it anyway. That's bad.

When no bug is encountered, whether bug identification is still in
*makes no difference* to the user. The only difference is what happens
when a bug is encountered. Continuing to use the software in the way
they were *is not an option* for the user but if they are not informed
of the bug that might be exactly what they try and do. And the problem
may not manifest itself until some way down the line in whatever
process the use of that software was part of.

That is the advantage of leaving bug identification in. If you decide
that that advantage is appropriate, you *might* also decide that, at
the same time as telling the user that their software is broken, you
will provide information that they could feed back to you to help
diagnose the problem (or you might decide that simply identifying that
a bug has been encountered is sufficient). Having made all those
design decisions, you might find that assert provides the
implementation of bug identification that you need. Or you might need
to implement something else.

Gavin Deane

On Tue, 06 Mar 2007 09:31:56 +0100, "Alf P. Steinbach" wrote:
>The commercial version of MSVC is one commercial compiler (in the price
>range you mention, the 7.1 version with documentation was about 13.000
>NKr) that ships with asserts enabled -- it ICEs regularly.

But ICE doesn't mean that all asserts are turned on in production
code.

>For that matter, even Windows Explorer, the Windows GUI, ships with
>asserts, or an equivalent mechanism, enabled, doing a report-and-restart
>when it crashes.

When it crashes! Again, that doesn't mean at all that asserts are
turned on in production code. Quite the contrary! Probably a signal
handler for SIGSEV is invoked. BTW, people interested in Microsoft's
usage of assert should read Steve Maguire's classic book 'Writing
Solid Code':
http://www.amazon.com/Writing-Solid-.../dp/1556155514


>For an honest and competent developer it's lunacy to turn off asserts.

LoL!

* Roland Pibinger:
> On Tue, 06 Mar 2007 09:31:56 +0100, "Alf P. Steinbach" wrote:
>> The commercial version of MSVC is one commercial compiler (in the price
>> range you mention, the 7.1 version with documentation was about 13.000
>> NKr) that ships with asserts enabled -- it ICEs regularly.
>
> But ICE doesn't mean that all asserts are turned on in production
> code.

Right, it doesn't mean that the moon is gouda-cheese, but so what?

An ICE (Internal Compiler Error) is an assert.

For optimization some small parts of the code will instead (typically)
be very intensively tested. However, that is impractical for the
complete application. The asserts that are left on also serve to
hopefully catch invalid state caused by any remaining errors in the
intensively tested code.


>> For that matter, even Windows Explorer, the Windows GUI, ships with
>> asserts, or an equivalent mechanism, enabled, doing a report-and-restart
>> when it crashes.
>
> When it crashes! Again, that doesn't mean at all that asserts are
> turned on in production code. Quite the contrary! Probably a signal
> handler for SIGSEV is invoked.

Probably not, unless you're talking of a *nix version of Windows Explorer.


> BTW, people interested in Microsoft's
> usage of assert should read Steve Maguire's classic book 'Writing
> Solid Code':
> http://www.amazon.com/Writing-Solid-.../dp/1556155514
>
>
>> For an honest and competent developer it's lunacy to turn off asserts.
>
> LoL!

Hm.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On Mar 6, 9:31 pm, "Alf P. Steinbach" <a...@start.no> wrote:
> For that matter, even Windows Explorer, the Windows GUI, ships with
> asserts, or an equivalent mechanism, enabled, doing a report-and-restart
> when it crashes.

That's a separate background task that detects segfaults and then
takes over.

Chris Theis wrote:
>
> "Alan Johnson" <> wrote in message
> news:. ..
>
> But how do you actually "assert" that the code is correct? Running your
> own tests, extended beta-testing etc. etc. is certainly a mandatory
> thing, but it does not at all guarantee correct code in the sense, that
> it will act correctly under each and every aspect that might come along.

You could always try and build a theorem prover. In university, I was
involved in building one for the Eiffel language. It is pretty
intriguing stuff. Too bad it is far from going main stream.

> IMO the sailing analogy hits the point. Staying with the analogies -
> even those competing in the TDF wear helmets for safety, but not all of
> them. Of course one would disable asserts in time critical parts in the
> production code, but this is not necessarily useful throughout the whole
> program. Especially when implementing complex parser/compiler systems
> they come in extremely handy in code that is already shipped to customers.

This makes sense, but an assert in this case is not very useful when a
customer calls and says, "your programme (he's a Canadian, eh? ) went
down and it is reporting some gibberish on the screen." Even if s/he
gives you the info on the screen, it may not be enough, and usually they
hit ok and don't write down anything.

A good production assert (which I would really like) would be to dump
the call stack in a manner that I could read it (dumped to a file). And
no, I've not have had a good experience with core dumps as they are not
available on all compiled systems, and the ones I have had them on are
junk as I can not find any documentation as to how to read em.

An even better one would describe the state of the system (really
difficult to implement, though if core dumps were a standard and worked
as they ought, I'm sure it would be suitable).


I've even see Windoze apps display stack dumps, but no docs in how to
use them.

What is really needed is a standard way of representing the state of a
failed system.


Adrian

Roland Pibinger wrote:
> On 2 Mar 2007 08:08:55 -0800, "jeffc226@...com" wrote:
> This is a very good explanation (source?). assert is for finding bugs
> in a program. Input validation, error handling, ... is not done with
> asserts. Therefore asserts should never be used in production
> (release) code.

Sure

>> OK I can buy that. But what keeps going unmentioned is that
>> assertions are debug-mode only. Well, it's mentioned, but usually in
>> the context of increased efficiency at runtime since they're compiled
>> out.
>
> Yes, that's their purpose. Actually, assert should be renamed to
> debug_assert.

Sure

>> I understand the idea that even the things you take for granted as
>> being true might not be true. Software has bugs, and today almost
>> every decent sized application uses third party supplements and
>> interfaces. Interfaces change, code versions change, versions of code
>> get mismatched. New permutations of hardware and software mixes are
>> constantly occurring.
>
> Well tested software has so few bugs that is can be smoothly used by
> the client. And what have interface changes and mismatched code to do
> with asserts?

Sure, if you put your foot down and tell your manager that "I don't care
if the deadline is tomorrow, it ain't ready!"

Library interface changes, if done incorrectly could cause a whole whack
of problems. Input interfaces may only be narrowed, never widened.
Output interfaces may be widened, never narrowed. You tell that to some
programmers and they will stare at you with a blank look, or worse argue
with you.

>> And where does all this manifest itself? At the developer's box?
>> Sometimes. But the majority of time in a modern large application
>> with many users, it's very likely for a bug to show itself in the
>> field. And that is exactly where the assertion does not exist.
>
> The bug crashes the program, assert calls abort which crashes the
> program. So?

So, you keep the programme from corrupting persistent data causing a
cascade of other problems afterwards.

>> Even most test departments use release code, not debug code.
>
> Of course, they test the program that is shipped, not a debug version.

Of course.

>> What exactly
>> is the point of checking for "impossible" error situations only at the
>> developer's desk?
>
> To find bugs in the program. Nothing more, nothing less. Together with
> unit tests, functional tests, integration tests, ... it is one step to
> produce a deployable program. Actually, assert can be seen as
> automated test built into code.

Definitely.

>> That just doesn't make sense to me. The code gets
>> executed far too much outside of that environment, in ways the
>> original developer might not even have imagined, for that to be good
>> enough.
>
> That just doesn't make sense to me. You write code that consists of
> (public) interfaces to encapsulated code. You validate the input.
> Since software is (should be) reusable it's no problem (even desired)
> that it is used in ways 'the original developer might not even have
> imagined'. You check the input as part of the contract between your
> code and the caller. When the input is within the allowd range your
> code must work.

Given the set of valid inputs, your system (since you defined the valid
inputs) should work always.

>> I would go so far as to say the original developer's box is precisely
>> where assertions are NOT needed, because that's the only place where a
>> debugger is available. (I see how they can come in handy, and force
>> you to resist making assumptions.) But you really need assertions (or
>> something) in environments where the debugger isn't available.
>
> Using a debugger is the most inefficient activity in programming. It
> is entirely resistant to automation. asserts help you avoid using the
> debugger.

Yeah, well that goes to design and the human factor. If the computer
did everything for us, what would we do?

The debugger, though resistant to automation, is still required, even
when you use asserts since that is the only way to get access to the
system state.

I just wrote the other day a parser with many asserts in it, but trying
to find why the assert failed wouldn't have been possible without the
debugger (and a bunch of debugging classes and functions that I wrote).
Did I tell you I *hate* pointers?

> BTW, have you ever seen a program/library that prints/displays asserts
> in production/release mode? I would be very reluctant to use that
> program because the code quality most probably is very poor.

If the programme or library displays the failed asserts in
"production/release mode", I would be concerned. If they could be
redirected to a file which I could look at postmortem, I would be happy
as I would be able to talk to that company and resolve the issue in a
more timely fashion.

Asserts are good, bad and ugly part of programming. I can't wait till a
theorem prover can be properly build.

Man, this thread spans 4 days. Its interesting, but I'm reading the
rest of it later.


Adrian

Greg Herlihy wrote:
> On Mar 4, 1:33 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:


> ...Leaving asserts
> enabled in a shipping program has the completely opposite effect - the
> asserts make the shipping program less reliable (that is, it is more
> prone to fail), and all but eliminates the chances that the developers
> will have tested the software before it shipped - and not just rely
> on those who use the software to make up the difference.

If the asserts are correct then the programme will not fail. If they
are incorrect, then someone has forgotten something (we are only human
after all) and it should be checked. Having this information may prove
to be invaluable as there are times that something _could_ have been
forgotten. Yes, it shouldn't have happened, but it did. Now the
customer would want to know how long before it is fixed. If you have no
starting point, you may be a long while making the customer even more
frustrated. (Man I could tell you stories...)


Adrian

--
================================================== ======
Adrian Hawryluk BSc. Computer Science
--------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__------------------------------------------------__
-----[blog: http://adrians-musings.blogspot.com/]-----
'------------------------------------------------------'
This content is licensed under the Creative Commons
Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
================================================== =======

Kirit Sælensminde wrote:
> On Mar 5, 4:53 pm, "Gavin Deane" <deane_ga...@hotmail.com> wrote:
>> On 5 Mar, 06:43, "Kirit Sælensminde" <kirit.saelensmi...@gmail.com>
>> wrote:
>>
>>> On Mar 4, 6:36 pm, "GavinDeane" <deane_ga...@hotmail.com> wrote:
>>>> On 4 Mar, 10:29, rpbg...@yahoo.com (Roland Pibinger) wrote:
>>>>> Is a contract violation a bug or an expected runtime scenario? IMO,
>>>>> the latter.
>>>> How do you engineer a reliable product if you expect third party
>>>> components (software or hardware) not to adhere to their interface
>>>> specifications? If you expect them to do that you need to change
>>>> supplier.
>>> Isn't the ability to do just that what we strive to do? To write
>>> reliable software even in the face of the unexpected?
>> There may be a confusion over the meaning of "expected" here. I was
>> responding to Roland Pibinger's phrase "expected runtime scenario"
>> believing he meant that a contract violation by a third party
>> component was a normal ("expected") event and that your program is
>> inherently flawed if correct behaviour relies on third party
>> components not violating their contracts.
>>
>> By definition, the only way[*] it is possible for a component to
>> violate its interface specification is if it has a bug. And you can't
>> build a reliable product if one of the components has a bug. If the
>> bug is in a component you produce, you need to fix the bug. If the bug
>> is in a third party component, you need to change supplier (or get the
>> current supplier to fix their product).
>>
>>[*] Assuming the documentation fully describes the interface. But
>> then, if it doesn't, you don't have the information needed to
>> integrate that component into your product in the first place.
>
> OK. I think I see where you're coming from. It seems you're talking
> about a systematic fault due to a buggy design or implementation,
> rather than a transient fault caused by hardware failure or data
> corruption.

If there is a transient fault, it is the same /unless/ there is a
recovery interface to the device /or/ you are willing to write a
mechanism to shutdown further possible use of that device. Either one
could get quite complex and would require an engineering decision as to
the pros, cons, ability to meet time-lines, etc.

If there is no recovery mechanism in place for the device, then you
/probably/ have lost _reliable_ contact with that device /permanently/.
There are, of course, exceptions to what I have just said, and would
have to be dealt with on a case by case basis.

> Personally I find that I never use assert, but I suspect this has much
> to do with the sorts of system that I build and the historic un-
> availability of any debugger. I do use exceptions for the purposes
> that others use asserts though.

Using exceptions in place of asserts is a more controlled way of
implementing runtime checks like asserts, but in some cases may not buy
you much when some hardware fails and may add a lot of complexity to the
system. However, that depends on many factors and should be dealt with
on a case by case manner.


Adrian

--
================================================== ========
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
================================================== ========