April 16, 2005
In article <d3qovm$2gl3$1@digitaldaemon.com>, zwang says...
>
>Kevin Bealer wrote:
>> GC, auto-init of data, checking of switch defaults, array bounds checking, and especially null checking have been quite valuable to me for reliability.
>> 
>> GC and auto-init in particular are useful, no just because they provide reliability, but because they unclutter the code.  For me a top contender for bug incidence in C++ is simply that so much has to be specified, that the extra syntax provides cover for broken code.
>> 
>> On another note, recently I converted an AI toy program from Java to D, then tightened up the performance (by many orders of magnitude).  I simply renamed the files to ".d", and was amazed to discover that after fixing the syntax errors and implementing a few missing parts, there was only one code error: argc was off by one (language difference).  After that, it -just ran-.
>> 
>> In other words, the syntax is very good at guiding you hand.  In C++ many many things are legal code but don't do what is expected.  The D version caught virtually everything at compile time.
>> 
>> Thanks, Walter.
>> 
>> Kevin
>> 
>> (P.S. If anyone wants a program to solve Sokoban puzzles in D...)
>
>Hi Kevin, I'm interested in the pruning algorithm of your Sokoban solver.

It's an A* search (I would like to do SMA*, but haven't gotten there yet.)  This means that for every board position I need to compute a cost of completion.  The higher number it returns, the better, as long as it never overestimates.  The algorithm produces the optimal solution.

Pruning was originally done by checking for "stuck boxes".  Now I compute a table of the the minimal costs from every location to every other location, using only legal "pushes" (boxes cannot move in N unless the player can stand on the square to the south of the box.).  This is done once at the beginning for the entire board (it's a quick computation).

"Pruning" only happens in two ways.  First, boxes will not be pushed onto squares that have infinite-cost (in the above table) to all target squares.

Secondly, because positions are expanded in least-cost-first order (using the cost calculation function + existing costs), the first time you see a position is essentially the lowest cost to get the board into that state.  So once I see expand a board position, I never expand it again.  I keep a hash of all previously seen board positions.

There are also several ways to relax the optimality requirement, to find a solution sequence faster.

Kevin



April 16, 2005
On Wed, 13 Apr 2005 12:46:36 +0200, xs0 wrote:


[snip]
> I fail to see what the big difference is between
> 
> assert(a!==null)
> 
> and
> 
> if (a is null)
>      throw new IllegalArgumentException()
> 
> They both prevent the code that follows from running in the case where the supplied parameter is null, so you can't run it with invalid parameters, which is the whole purpose of those two statements.

The first is designed to detect mistakes made by the *programmer*, and the second is designed to detect mistakes in the (user-provided) data.

> Why is it so hard for you to admit that it is possible to have CP errors in code that cannot corrupt your app?

It could be just a matter of interpretation, but Contract Programming is a technique whose purpose is to detect mistakes made by the programmer rather than mistakes made outside of the program - such as invalid data or environmental constraints (e.g. out of RAM).

> I mean, if you give a plugin what is basically a read-only view of your data, it shouldn't be able to corrupt it. Sure it can, if it wants to, but that has nothing to do with CP, exceptions, errors or whatever.
> 
> 
>> It is only the case when a contract violation has occured, because only that is a signal from the code's designer to the code's user (or rather the runtime) that the plug-in is now invalid.
> 
> That's true. However, if I have a plugin that displays tooltips on some objects, I totally don't care if it encountered a CP violation or not, if it works, great, if it doesn't, too bad, no tooltips anymore in this session, I'll restart when I want to. But I really don't see a case for forcing the app, which otherwise works perfectly, to shut down.

I've gotten confused a bit by your use of application and plug-in. I would have thought that if a plug-in fails (CP error) then *only* the plug-in should fail and not the application that is hosting it.


[snip]

>> So, looking back at your para "If the code of the app is able to disable the plugin without shutting down" applies to Exceptions (and Exhaustions), whereas "if it is not clear whether the app is in a consistent state, I agree shutting down completely is the best thing to do" applies to Errors. These two things hold, of course, since they are the definitions of Exceptions and Errors.
> 
> Well, who are you to decide that a CP error means an inconsistent state? Sure, it does in many cases, but not necessarily always. All I'm saying is that one should have a choice.

Who should have the choice? The user of the application or the designer of the application? If the designer says "if such-and-such occurs then the application must stop", then why should the user always have the right to override the design?

> 
>> CP violations are never tolerated, which means they get fixed _very_ quickly.
> 
> Great, I just don't think everybody should be forced to work that way.
> 

Let's pretend that a bridge designer has placed a detection mechanism in the bridge such that it reports an error if the load on the bridge before a vehicle crosses is different from the load after the vehicle crosses. If it then reports such an error, should you as a user of the bridge, have the right to disregard the warning of a possibly unsafe bridge, or should you be forced to wait until the bridge is declared safe again?

>>>>>I mean, when I do something like inspect a value in a debugger, and the value is 150MB and the debugger runs out of memory, I don't want it to stop, just because it can't show me a var (which can just as easily manifest as an assertion error or whatever)...
>>>>
>>>>Out of memory is not an error, it's an exception, so that's just not an issue.
>>>
>>>Like I said, out of memory can just as well manifest itself later as a broken contract or whatever.
>> 
>> 
>> No, it cannot.
> 
> Sure it can:
> 
> int[] allocIfYouCan(int size)
> {
>      try {
>          return new int[size];
>      } catch (OutOfMemory ignored) {
>          return null;
>      }
> }
> 
> void doSomething(int[] arr)
> {
>     assert(arr!==null);
> }
> 
> doSomething(allocIfYouCan(10000000));
> 
> Obviously, allocIfYouCan() is not a good idea, but it can still happen.

But by using the 'assert', the designer/coder is saying that at *anytime* a null is returned then the application is broken and thus needs to be fixed before it can be used.

If the coder does not mean that, then the coder needs to avoid using 'assert' in this type of situation. Use a simple runtime 'if' statement instead.

[snip]

>>  [snip]
>  > So (hopefully) you see that it is impossible to ever state
>  > (with even practical certainty) that "a faulty part of the
>  > application should not be taken as if the whole application
>  > is faulty".
> 
> No, I don't.. There are parts and there are parts. You're saying that even the tiniest error (but only if it was specified in a contract) should abort the app, I'm just saying that in some cases it's possible for that to be overreacting.
> 

Yes, it may be possible for an application to continue running to the
user's satisfaction after a program contract has been broken. However, one
can never be absolutely sure in every case. And because it is a broken
program contract, it means that the designer of the application *wants* the
program to stop. It is her program after all ;-)

>>>OK, it is obviously desired in some cases, so I agree it should be supported by the language, BUT, none of the built-in exceptions should then be unrecoverable.
>> 
>> Well again, I get the feeling that you think I've implied that a wide range of things should be unrecoverable. I have not, and perhaps I should say so explicitly now: AFAIK, only contract violations should be Errors (i.e. unrecoverable), since only they are a message from the author(s) of the code to say when it's become invalid.
> 
> How has the code become invalid exactly? The code doesn't change when it violates a contract.

Because the designer said that if such a situation ever happens, then it is because the programmer has made a mistake. And thus, the rest of the program may contain errors that are not so obvious. It is a red-flag that says that the application is suspect and needs to be corrected or at least re-validated before continuing.


-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
17/04/2005 8:50:45 AM
April 16, 2005
>> Why is it so hard for you to admit that it is possible to have CP errors in code that cannot corrupt your app?
>
>    In principle it is not so.
>    In practice it often is (albeit you cannot know).
>
> I've said that a hundred times.
>
> If you want me to say that, in principle, there are CP errors that cannot corrupt your app, then I won't because it ain't so. There's a beguiling thought that preconditions can be classed in that way, but it doesn't pan out. (And I'm not going to blather on about that because I think everyone's heartily sick of the debate by now. I know I am <g>)

I'm not sure how to differentiate principle and practice. For example
  int return1(){ return 0; } // written by an intern
  void user_code() {
    int x = return1();
    assert( x == 1 );
    printf("I got a 1.\n");
  }
Now the code above will assert every time and obviously no real code would
look exactly like that but it's not uncommon to see asserts check something
that if it fails can be easily recovered from. Is returning 0 from a
function that says it returns 1 a contract violation? yes. Is it a big deal?
it depends.


April 17, 2005

Derek Parnell wrote:
> On Wed, 13 Apr 2005 12:46:36 +0200, xs0 wrote:
> 
> 
> [snip]
> 
>>I fail to see what the big difference is between
>>
>>assert(a!==null)
>>
>>and
>>
>>if (a is null)
>>     throw new IllegalArgumentException()
>>
>>They both prevent the code that follows from running in the case where the supplied parameter is null, so you can't run it with invalid parameters, which is the whole purpose of those two statements.
> 
> 
> The first is designed to detect mistakes made by the *programmer*, and the
> second is designed to detect mistakes in the (user-provided) data.

Hmm, I'd disagree. If a function does such a check, I'd say its contract is obviously that it doesn't work with nulls. It doesn't matter whether that's in the in block or start of body, and it doesn't matter whether it's an assert or an if(). So, both are mistakes by the programmer, because the function shouldn't be called with null..


>>Why is it so hard for you to admit that it is possible to have CP errors in code that cannot corrupt your app? 
> 
> It could be just a matter of interpretation, but Contract Programming is a
> technique whose purpose is to detect mistakes made by the programmer rather
> than mistakes made outside of the program - such as invalid data or
> environmental constraints (e.g. out of RAM).

I agree with that, I just don't agree that in case of _any_ contract violation, the app should be forced to terminate (which is what Matthew wants).

> I've gotten confused a bit by your use of application and plug-in. I would
> have thought that if a plug-in fails (CP error) then *only* the plug-in
> should fail and not the application that is hosting it.

Me too, that's my whole point :) But Matthew seems to think otherwise..


>>>So, looking back at your para "If the code of the app is able to disable the plugin without shutting down" applies to Exceptions (and Exhaustions), whereas "if it is not clear whether the app is in a consistent state, I agree shutting down completely is the best thing to do" applies to Errors. These two things hold, of course, since they are the definitions of Exceptions and Errors.
>>
>>Well, who are you to decide that a CP error means an inconsistent state? Sure, it does in many cases, but not necessarily always. All I'm saying is that one should have a choice.
> 
> Who should have the choice? The user of the application or the designer of
> the application? If the designer says "if such-and-such occurs then the
> application must stop", then why should the user always have the right to
> override the design?

Hmm, now I see how that sentence can be confusing :) "you" refers to Matthew, while "one" refers to "any coder". The answer is definitely designer.


> Let's pretend that a bridge designer has placed a detection mechanism in
> the bridge such that it reports an error if the load on the bridge before a
> vehicle crosses is different from the load after the vehicle crosses. If it
> then reports such an error, should you as a user of the bridge, have the
> right to disregard the warning of a possibly unsafe bridge, or should you
> be forced to wait until the bridge is declared safe again?

Perhaps I should be, but if everybody was forced to stay off it (for example, by some shield from Star Trek, so you really can't get on), how will they ever fix it? :)


>>int[] allocIfYouCan(int size)
>>{
>>     try {
>>         return new int[size];
>>     } catch (OutOfMemory ignored) {
>>         return null;
>>     }
>>}
>>
>>void doSomething(int[] arr)
>>{
>>    assert(arr!==null);
>>}
>>
>>doSomething(allocIfYouCan(10000000));
>>
>>Obviously, allocIfYouCan() is not a good idea, but it can still happen.
> 
> 
> But by using the 'assert', the designer/coder is saying that at *anytime* a
> null is returned then the application is broken and thus needs to be fixed
> before it can be used.

I don't think all asserts assert that the application is broken. For example:

Image i=ImageLoader.load("c:\\foo.tif");
assert(i);
processImage(i);

I'd say that the assertion is not "if i is ever null, kill the whole application", it's just "if i is ever null, I don't want to continue".


But that was not the point. I tried to make the point, that not all CP violations should mean that the application should be forced to terminate. A consequence, if one agrees, is that assert should not throw exceptions that cannot be "quenched", because all CP support in D depends on assert. OTOH, I totally support critical_assert, a new type of exception, or whatever, to make the apps, that actually do require unquenchable exceptions, implementable.



> If the coder does not mean that, then the coder needs to avoid using
> 'assert' in this type of situation. Use a simple runtime 'if' statement
> instead.

Perhaps, but like I said, I don't see any difference between assert(a) and if(!a) throw.. Obviously, they will throw different exceptions, but both should be quenchable.


>>No, I don't.. There are parts and there are parts. You're saying that even the tiniest error (but only if it was specified in a contract) should abort the app, I'm just saying that in some cases it's possible for that to be overreacting.
> 
> Yes, it may be possible for an application to continue running to the
> user's satisfaction after a program contract has been broken. However, one
> can never be absolutely sure in every case. And because it is a broken
> program contract, it means that the designer of the application *wants* the
> program to stop. It is her program after all ;-)

If the designer wants the app to stop, that's ok. It's also ok if she doesn't want the app to stop. Matthew says it's never ok to not stop, and I disagree..


>>How has the code become invalid exactly? The code doesn't change when it violates a contract.
> 
> 
> Because the designer said that if such a situation ever happens, then it is
> because the programmer has made a mistake. And thus, the rest of the
> program may contain errors that are not so obvious. It is a red-flag that
> says that the application is suspect and needs to be corrected or at least
> re-validated before continuing.

It may or it may not contain errors. Sometimes you don't know, but sometimes you also do. Especially when dealing with user data (which is almost always :), it's often hard to predict all the ways that data can be wrong (I work in GIS; you wouldn't believe how many _different_ types of errors 600 million polygons can contain :). If that principle is acknowledged throughout the code (by making data structures robust, updating transactionally, always handling exceptions, and whatnot), one can implement the app so that it is totally able to recover from any 'error' it detects later on. Now, I don't see why such an app should be forced to terminate, if someone decided to assert (a<100000000) somewhere and that happens to not be true every now and then?


xs0
April 17, 2005
On Sun, 17 Apr 2005 07:36:44 +0200, xs0 wrote:

> Derek Parnell wrote:
>> On Wed, 13 Apr 2005 12:46:36 +0200, xs0 wrote:
>> 
>> 
>> [snip]
>> 
>>>I fail to see what the big difference is between
>>>
>>>assert(a!==null)
>>>
>>>and
>>>
>>>if (a is null)
>>>     throw new IllegalArgumentException()
>>>
>>>They both prevent the code that follows from running in the case where the supplied parameter is null, so you can't run it with invalid parameters, which is the whole purpose of those two statements.
>> 
>> 
>> The first is designed to detect mistakes made by the *programmer*, and the second is designed to detect mistakes in the (user-provided) data.
> 
> Hmm, I'd disagree.

So let's see if I got it straight. You disagree that the purpose of the 'assert' mechanism is detect mistakes made by the programmer, as opposed to detecting bad data.

>If a function does such a check, I'd say its contract
> is obviously that it doesn't work with nulls. It doesn't matter whether that's in the in block or start of body, and it doesn't matter whether it's an assert or an if(). So, both are mistakes by the programmer, because the function shouldn't be called with null..

It may be true that the function should never be called with a null. However, if that is the case then assert should also not be used as the detection/reporting mechanism. This is because, as a general rule, assert should be used on output data rather than on input data. Assert should be used to detect errors in *logic* rather than errors in *data*.

Assert should be used to validate that the programmer's implementation of an algorithm is correct. Argument validation is looking at the inputs to an algorithm and not its results.

I say 'assert' should be used because if there is a logic error then the program should shutdown as safely as it can and not continue, and the 'assert' is one such mechanism that has that behaviour.

> 
>>>Why is it so hard for you to admit that it is possible to have CP errors in code that cannot corrupt your app?
>> 
>> It could be just a matter of interpretation, but Contract Programming is a technique whose purpose is to detect mistakes made by the programmer rather than mistakes made outside of the program - such as invalid data or environmental constraints (e.g. out of RAM).
> 
> I agree with that, I just don't agree that in case of _any_ contract violation, the app should be forced to terminate (which is what Matthew wants).

By definition, a contract failure means that we have a situation in which
somebody needs to revalidate things. I suggest that you have seen evidence
of people using contracts when contracts ought not to have been used.
Instead, a run-time test other than a contract should have been used.

>> I've gotten confused a bit by your use of application and plug-in. I would have thought that if a plug-in fails (CP error) then *only* the plug-in should fail and not the application that is hosting it.
> 
> Me too, that's my whole point :) But Matthew seems to think otherwise..
> 
I believe that Matthew was saying that if a plug-in fails in such a manner that one cannot guarantee that the hosting application is untouched, then the application should shutdown too.

>>>>So, looking back at your para "If the code of the app is able to disable the plugin without shutting down" applies to Exceptions (and Exhaustions), whereas "if it is not clear whether the app is in a consistent state, I agree shutting down completely is the best thing to do" applies to Errors. These two things hold, of course, since they are the definitions of Exceptions and Errors.
>>>
>>>Well, who are you to decide that a CP error means an inconsistent state? Sure, it does in many cases, but not necessarily always. All I'm saying is that one should have a choice.
>> 
>> Who should have the choice? The user of the application or the designer of the application? If the designer says "if such-and-such occurs then the application must stop", then why should the user always have the right to override the design?
> 
> Hmm, now I see how that sentence can be confusing :) "you" refers to Matthew, while "one" refers to "any coder". The answer is definitely designer.
> 
In which case, the assert should shutdown the application unconditionally.

>> Let's pretend that a bridge designer has placed a detection mechanism in the bridge such that it reports an error if the load on the bridge before a vehicle crosses is different from the load after the vehicle crosses. If it then reports such an error, should you as a user of the bridge, have the right to disregard the warning of a possibly unsafe bridge, or should you be forced to wait until the bridge is declared safe again?
> 
> Perhaps I should be, but if everybody was forced to stay off it (for example, by some shield from Star Trek, so you really can't get on), how will they ever fix it? :)

I don't know as that is not my field, but I guess they won't be asking you either.

>>>int[] allocIfYouCan(int size)
>>>{
>>>     try {
>>>         return new int[size];
>>>     } catch (OutOfMemory ignored) {
>>>         return null;
>>>     }
>>>}
>>>
>>>void doSomething(int[] arr)
>>>{
>>>    assert(arr!==null);
>>>}
>>>
>>>doSomething(allocIfYouCan(10000000));
>>>
>>>Obviously, allocIfYouCan() is not a good idea, but it can still happen.
>> 
>> 
>> But by using the 'assert', the designer/coder is saying that at *anytime* a null is returned then the application is broken and thus needs to be fixed before it can be used.
> 
> I don't think all asserts assert that the application is broken. For example:
> 
> Image i=ImageLoader.load("c:\\foo.tif");
> assert(i);
> processImage(i);
> 
> I'd say that the assertion is not "if i is ever null, kill the whole application", it's just "if i is ever null, I don't want to continue".
> 
Then don't use an 'assert' then! This is really a simple thing, honestly.

** If you want to shutdown an application when you detect an error in logic, use an assert.

** If you do not want to shutdown an application when you detect an error (of any sort), do not use an assert.

> But that was not the point. I tried to make the point, that not all CP violations should mean that the application should be forced to terminate.  A consequence, if one agrees, is that assert should not throw exceptions that cannot be "quenched", because all CP support in D depends on assert. OTOH, I totally support critical_assert, a new type of exception, or whatever, to make the apps, that actually do require unquenchable exceptions, implementable.
> 

> 
>> If the coder does not mean that, then the coder needs to avoid using 'assert' in this type of situation. Use a simple runtime 'if' statement instead.
> 
> Perhaps, but like I said, I don't see any difference between assert(a) and if(!a) throw.. Obviously, they will throw different exceptions, but both should be quenchable.

Using D today, how would you code something to throw an unquenchable exception?

> 
>>>No, I don't.. There are parts and there are parts. You're saying that even the tiniest error (but only if it was specified in a contract) should abort the app, I'm just saying that in some cases it's possible for that to be overreacting.
>> 
>> Yes, it may be possible for an application to continue running to the user's satisfaction after a program contract has been broken. However, one can never be absolutely sure in every case. And because it is a broken program contract, it means that the designer of the application *wants* the program to stop. It is her program after all ;-)
> 
> If the designer wants the app to stop, that's ok. It's also ok if she doesn't want the app to stop. Matthew says it's never ok to not stop, and I disagree..

If the designer wants it to stop, she uses an assert. If she allows the possibility of it continuing, then she does not use an assert.

>>>How has the code become invalid exactly? The code doesn't change when it violates a contract.
>> 
>> 
>> Because the designer said that if such a situation ever happens, then it is because the programmer has made a mistake. And thus, the rest of the program may contain errors that are not so obvious. It is a red-flag that says that the application is suspect and needs to be corrected or at least re-validated before continuing.
> 
> It may or it may not contain errors. Sometimes you don't know, but sometimes you also do. Especially when dealing with user data (which is almost always :), it's often hard to predict all the ways that data can be wrong (I work in GIS; you wouldn't believe how many _different_ types of errors 600 million polygons can contain :). If that principle is acknowledged throughout the code (by making data structures robust, updating transactionally, always handling exceptions, and whatnot), one can implement the app so that it is totally able to recover from any 'error' it detects later on. Now, I don't see why such an app should be forced to terminate, if someone decided to assert (a<100000000) somewhere and that happens to not be true every now and then?

Don't use an assert then. Use a different mechanism.

-- 
Derek Parnell
Melbourne, Australia
17/04/2005 4:09:39 PM
April 17, 2005
> [snip, summary:]
> Then don't use an 'assert' then! This is really a simple thing, honestly.
> 
> ** If you want to shutdown an application when you detect an error in
> logic, use an assert.
> 
> ** If you do not want to shutdown an application when you detect an error
> (of any sort), do not use an assert.
> 
>> [snip]
>
> Don't use an assert then. Use a different mechanism.

But I want to use assert, even if perhaps my examples were not the best cases for using it (if nothing else, "assert(a)" is far less characters than any sort of "if(a) throw ...", and it also leaves no doubt on what is and isn't expected). I just fail to see why using assert would have to mean that my app needs to shut down whenever one fails.

I mean, if you want to shutdown, you can do it easily - don't quench assertion failures, how hard is that?

OTOH, if assert was unquenchable, there would be no way not to shutdown, and I'm always pro-choice :)

BTW, why shouldn't assert be used to check data? If you look at
http://www.digitalmars.com/d/dbc.html
it would seem that I'm not the only one that thinks it's ok to do so (and to catch those errors, too).. I mean, an error in data somewhere means an error in logic somewhere else, anyway..


xs0
April 17, 2005
xs0 wrote:
>> Don't use an assert then. Use a different mechanism.
> 
> But I want to use assert, even if 

Assert exists for the very purpose of halting the entire program when the assertion fails.

One might even say that "assert" is a concept. And that concept is then implemented in quite a few languages.

D should not be the one language which destroys the entire concept.
April 17, 2005
On Sun, 17 Apr 2005 11:24:21 +0200, xs0 wrote:

>  > [snip, summary:]
>> Then don't use an 'assert' then! This is really a simple thing, honestly.
>> 
>> ** If you want to shutdown an application when you detect an error in logic, use an assert.
>> 
>> ** If you do not want to shutdown an application when you detect an error (of any sort), do not use an assert.
>> 
>  >> [snip]
>  >
>> Don't use an assert then. Use a different mechanism.
> 
> But I want to use assert

Well that's a shame then.

>, even if perhaps my examples were not the best
> cases for using it (if nothing else, "assert(a)" is far less characters than any sort of "if(a) throw ...", and it also leaves no doubt on what is and isn't expected). I just fail to see why using assert would have to mean that my app needs to shut down whenever one fails.

Hang around a bit longer, it'll come to you eventually.

> I mean, if you want to shutdown, you can do it easily - don't quench assertion failures, how hard is that?
> 
> OTOH, if assert was unquenchable, there would be no way not to shutdown,

Exactly!  Now you're getting it.

> and I'm always pro-choice :)

Like ... fclose() shouldn't always close the file if I don't want it to?
     ... sometimes I might not want function X to return any value but
sometimes I might?

The purpose of assert, the reason it exists, is to shutdown programs when the programmer chooses to.

> BTW, why shouldn't assert be used to check data? If you look at
> http://www.digitalmars.com/d/dbc.html
> it would seem that I'm not the only one that thinks it's ok to do so
> (and to catch those errors, too).. I mean, an error in data somewhere
> means an error in logic somewhere else, anyway..

Duh?! Of course it checks data, but it ought to check *output* data and not *input* data. The output data is a result of *your* coding and you need to check to see if you implemented the algorithm correctly. That is what assert is designed for. The input data may or may not have come from your code. It could have come from external sources such as users of your program. You shouldn't crash a program with assert if the input data is bad. You may crash it by some other mechanism though. Assert is a debugging mechanism; that is, it is used to find bugs (specifically your coding errors) before people get to use your program. A production program, one compiled with the -release switch, will not execute any assert statements in your code.

/me shakes head and walks away.

-- 
Derek Parnell
Melbourne, Australia
17/04/2005 9:03:07 PM
April 17, 2005
In article <d3q20d$1oag$1@digitaldaemon.com>, Matthew says...
>
>The only area of doubt as to the viability of this solution is what would happen with heterogeneous mixes of dynamically merged link units. That is, what happens if a CP process loads a (violating) non-CP plug-in? It just crashes without invoking the graceful shutdown / logging stuff, I guess. Conversely, if a non-CP process loads a (violating) CP plug-in? Same thing happens, I guess. I'm interested in people's thoughts on this.

Perhaps it would be worthwhile to have some metadata built into libraries?  It might be useful to be able to query this kind of thing at load-time.


Sean


April 17, 2005
In article <d3qn6o$2fbf$1@digitaldaemon.com>, Walter says...
>
>"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:d3qdtc$23js$1@digitaldaemon.com...
>> GC, auto-init of data, checking of switch defaults, array bounds checking,
>and
>> especially null checking have been quite valuable to me for reliability.
>>
>> GC and auto-init in particular are useful, no just because they provide reliability, but because they unclutter the code.  For me a top contender
>for
>> bug incidence in C++ is simply that so much has to be specified, that the
>extra
>> syntax provides cover for broken code.
>
>Yes. For example, most declarations in C++ have to be done twice. Differences can inadvertently creep in. This is not what one would expect to see in a modern language. Just being able to express directly what you want to be done improves the reliability of the code, as you wrote.

Related question.  Would you suggest relying on the default initializers when the default value is acceptable or is always initializing variables the preferred method?  I ask this because of comments you've made in the past that you'd prefer if variables were all default initialized to trap values rather than "usable" values.  Basically, I'm finding myself beginning to rely on integral variables default initializing to 0 and not bothering to explicitly initialize them, and I don't want to fall into this habit if there's any chance of the default values changing.


Sean