Re: Order of evaluation and better declaration of functions

From: Bhushit Joshipura (bhushit_at_hotmail.com)
Date: 01/06/04 

Date: 5 Jan 2004 16:11:07 -0800

I have re-posted the question to comp.std.c and comp.std.c++ . Thanks
for showing me correct group. I am posting this last message, with
comments embedded, in this thread to provide a continuum to take the
debate there.

[snip]

> >(int *) B::f (
> > int i { //document here and assert at run time
> > i > 0 && i < INT_MAX
> > },
> > int j = i + 1 {
> > j > i || j < 0
> > },
> > int *k {
> > k != NULL && k!= some_global
> > }
> > ) // end of argument documented assertion now return value's
> >turn
> > (
> > != NULL
> > );
>
> Yuk yuk. Do you really think that's better than:
>
> int* B::f (int i, int j, int* k)
> {
> assert(i > 0 && i < INT_MAX);
> assert(j > i || j < 0);
> assert(k != NULL && k!= some_global);
> }
 
1. How many of your users see your .cpp file?
2. How many of your users see your .h file?
3. Why burden documentation when code can communicate the same?
4. What about maintenance? Which of the following is easier?
a. modify .cpp, modify the incode documentation, modify design
documents, modify user documents versus
b. modify .h file (and let automatic code generator do the rest)

  
> >[I feel shy of suggesting a "default return value" for a function.]
>
> !
>
> >This scheme has three advantages:
> >1. It facilitates communicating pre-conditions, post-conditions very
> >clearly (BIG plus)
>
> I disagree.

I hope now you see the point. It is not just functionality, it is
communication to human beings also. Pelting two birds with the same
stone.

> >2. It makes definition of function f clearer
>
> I disagree. Adding design-by-contract to the language isn't such a bad
> idea, but the language is too complex already. The syntax you've
> chosen is terrible.

OK. Please suggest alternative syntax. I am no good writer of syntax.
At present I am trying to generate an opinion only. If we all agree,
syntax can be worked out later.

[snip]

> >5. Function calls within assertions may become nasty. [At the worst,
> >we can disallow function calls there.]
>
> That's not a problem. Side effects must of course be avoided.

Later, I realized that it is call of the function within its own
assertion may cause a problem. I have not analysed recursion in such a
case in detail.

> The big problem is that is doesn't solve any problem that C++ has, but
> rather adds further problems.

Will you please elaborate with examples? I think this "assertive
declaration" is not a complete solution of one problem but a partial
solution of many.

[snip]