Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #31116

Re: Ftn I/Os documentation best practices

Show all headers | View raw

On 26/06/2022 21:35, Don Y wrote:
> I add a boilerplate to each function definition that
> declares constraints on inputs, expectations of outputs,
> performance issues, etc.  I use this to add invariants
> to the code to detect/enforce these conditions.
> 
> But, there is nothing that ensures that I've done
> this -- other than discipline.
> 
> I'm looking at ways to create an IDL that will allow
> for more specific criteria to be included in the
> declaration that could also drive the IDL compiler
> to add suitable invariants as applicable.
> 
> [This makes RPC much more effective but can also
> benefit traditional ftn invocations]
> 
> Any pointers to similar schemes?  I've been looking
> through CORBA et al. for hints but they seem to
> focus on bigger machines (where there is more tolerance
> over data types and more overhead expected).

What programming language are you using?  If your answer is "C", it's wrong.

If you are just putting these things in comments, then they will get out 
of sync with the code.  The best you can do is writing something like a 
Python script that will read the C code and check for the pattern of 
comments.

If you want something really useful, you need a programming language 
that will let you write the contracts in the language itself - then they 
can be checked and enforced.  Ada, D, and Scala are examples.  C++ has a 
Boost.Contracts library, and language support for contracts is due in 
C++23 (last I heard - but it might be delayed again).

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Ftn I/Os documentation best practices Don Y <blockedofcourse@foo.invalid> - 2022-06-26 12:35 -0700
  Re: Ftn I/Os documentation best practices David Brown <david.brown@hesbynett.no> - 2022-06-27 09:36 +0200
    Re: Ftn I/Os documentation best practices Grant Edwards <invalid@invalid.invalid> - 2022-06-27 15:18 +0000
      Re: Ftn I/Os documentation best practices David Brown <david.brown@hesbynett.no> - 2022-06-27 19:52 +0200
      Re: Ftn I/Os documentation best practices Don Y <blockedofcourse@foo.invalid> - 2022-06-27 14:34 -0700
        Re: Ftn I/Os documentation best practices David Brown <david.brown@hesbynett.no> - 2022-06-28 13:48 +0200
      Re: Ftn I/Os documentation best practices Stephen Pelc <stephen@vfxforth.com> - 2022-06-28 08:30 +0000
        Re: Ftn I/Os documentation best practices Don Y <blockedofcourse@foo.invalid> - 2022-06-28 05:49 -0700
          Re: Ftn I/Os documentation best practices Stephen Pelc <stephen@vfxforth.com> - 2022-06-28 14:35 +0000
            Re: Ftn I/Os documentation best practices Don Y <blockedofcourse@foo.invalid> - 2022-06-28 11:33 -0700
              Re: Ftn I/Os documentation best practices Stephen Pelc <stephen@vfxforth.com> - 2022-06-29 12:36 +0000
                Re: Ftn I/Os documentation best practices Don Y <blockedofcourse@foo.invalid> - 2022-06-29 06:39 -0700

csiph-web