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

Groups > comp.lang.c > #140261 > unrolled thread

Distributing C as headers.

Back to article view | Back to comp.lang.c

Contents

  Distributing C as headers. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-25 07:23 -0800
    Re: Distributing C as headers. Thiago Adams <thiago.adams@gmail.com> - 2019-01-25 07:31 -0800
      Re: Distributing C as headers. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-25 07:33 -0800
        Re: Distributing C as headers. Mateusz Viste <mateusz@wont.tell> - 2019-01-25 15:42 +0000
        Re: Distributing C as headers. gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-25 17:40 +0000
          Re: Distributing C as headers. Thiago Adams <thiago.adams@gmail.com> - 2019-01-25 09:59 -0800
            Re: Distributing C as headers. Thiago Adams <thiago.adams@gmail.com> - 2019-01-25 10:01 -0800
            Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-25 22:17 +0100
              Re: Distributing C as headers. Bart <bc@freeuk.com> - 2019-01-25 21:33 +0000
          Re: Distributing C as headers. Mateusz Viste <mateusz@wont.tell> - 2019-01-25 18:07 +0000
            Re: Distributing C as headers. gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-25 18:46 +0000
              Re: Distributing C as headers. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-01-25 19:43 -0700
                Re: Distributing C as headers. Mateusz Viste <mateusz@wont.tell> - 2019-01-26 08:13 +0000
                  Re: Distributing C as headers. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-01-26 13:39 -0700
                    Re: Distributing C as headers. Mateusz Viste <mateusz@wont.tell> - 2019-01-26 21:00 +0000
                      Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-26 22:29 +0100
                        Re: Distributing C as headers. nobody@example.org (Scott) - 2019-01-27 04:56 +0000
                          Re: Distributing C as headers. Dan Purgert <dan@djph.net> - 2019-01-27 11:36 +0000
                          Re: Distributing C as headers. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 12:26 -0800
                            Re: Distributing C as headers. "Jason C. McDonald" <indeliblebluepen@gmail.com> - 2019-02-28 19:52 +0000
                              Re: Distributing C as headers. Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-02-28 15:04 -0500
                              Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-28 21:40 +0100
                                Re: Distributing C as headers. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-28 13:57 -0800
                      Re: Distributing C as headers. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-01-27 13:33 +0000
                      Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-27 15:06 +0100
                    Re: Distributing C as headers. luser droog <luser.droog@gmail.com> - 2019-01-26 13:01 -0800
                      Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-26 22:30 +0100
                        Re: Distributing C as headers. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-02 09:27 +0000
                    Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-26 22:23 +0100
                      Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-26 13:39 -0800
                        Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-26 22:47 +0100
                          Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-26 14:33 -0800
                            Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-26 23:37 +0100
                              Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-26 15:09 -0800
                              Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-27 15:11 +0100
                              Re: Distributing C as headers. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-27 16:12 -0500
                                Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-28 00:51 +0100
                                  Re: Distributing C as headers. Bart <bc@freeuk.com> - 2019-01-28 00:06 +0000
                                    Re: Distributing C as headers. Bart <bc@freeuk.com> - 2019-01-28 00:18 +0000
                                      Re: Distributing C as headers. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-28 01:12 +0000
                                        Re: Distributing C as headers. Bart <bc@freeuk.com> - 2019-01-28 01:35 +0000
                                          Re: Distributing C as headers. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-28 02:19 +0000
                                            Re: Distributing C as headers. Bart <bc@freeuk.com> - 2019-01-28 10:40 +0000
                                              Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-28 12:22 +0100
                                            Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-28 12:21 +0100
                                              Re: Distributing C as headers. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-28 04:03 -0800
                                              Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-28 13:23 +0100
                                                Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-28 11:16 -0800
                                                  Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-28 21:08 +0100
                                    Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-28 01:19 +0100
                                      Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-27 16:59 -0800
                                  Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-27 16:33 -0800
                                    Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-28 01:35 +0100
                                      Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-27 17:20 -0800
                                        Re: Distributing C as headers. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-27 22:50 -0500
                                  Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-28 06:52 +0100
                                    Re: Distributing C as headers. Bart <bc@freeuk.com> - 2019-01-28 10:55 +0000
                                      Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-28 12:26 +0100
                                        Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-28 13:27 +0100
                                      Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-28 13:26 +0100
                                        Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-28 14:03 +0100
                                      Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-28 11:12 -0800
                                    Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-28 12:25 +0100
                                      Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-28 13:33 +0100
                                    Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-28 11:20 -0800
                                      Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-28 21:11 +0100
                                        Re: Distributing C as headers. scott@slp53.sl.home (Scott Lurndal) - 2019-01-28 21:12 +0000
                                          Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-28 23:06 +0100
                    Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-27 15:02 +0100
      Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 17:51 +0100
      Re: Distributing C as headers. fir <profesor.fir@gmail.com> - 2019-01-25 14:28 -0800

Page 1 of 4  [1] 2 3 4  Next page →

#140261 — Distributing C as headers.

Here's a site for C header only libraries.
(You use a hash define to toggle compilation of the executable code,
so the same file is both header and implementation)

The one file rule is certainly handy.

https://github.com/vurtun/mmx

[toc] | [next] | [standalone]

#140262

On Friday, January 25, 2019 at 1:23:16 PM UTC-2, Malcolm McLean wrote:
> Here's a site for C header only libraries.
> (You use a hash define to toggle compilation of the executable code,
> so the same file is both header and implementation)
> 
> The one file rule is certainly handy.
> 
> https://github.com/vurtun/mmx

I think header only makes sense for C++ templates and some 
inline functions.

For C, I think a pair .c and .h makes more sense.

[toc] | [prev] | [next] | [standalone]

#140264

On Friday, 25 January 2019 15:31:54 UTC, Thiago Adams  wrote:
> On Friday, January 25, 2019 at 1:23:16 PM UTC-2, Malcolm McLean wrote:
> > Here's a site for C header only libraries.
> > (You use a hash define to toggle compilation of the executable code,
> > so the same file is both header and implementation)
> > 
> > The one file rule is certainly handy.
> > 
> > https://github.com/vurtun/mmx
> 
> I think header only makes sense for C++ templates and some 
> inline functions.
> 
> For C, I think a pair .c and .h makes more sense.
>
But then you've got to wrap them in a zip to distribute as a single entity. 

[toc] | [prev] | [next] | [standalone]

#140265

On Fri, 25 Jan 2019 07:33:52 -0800, Malcolm McLean wrote:
> But then you've got to wrap them in a zip to distribute as a single
> entity.

You should anyway, code compresses very well. Plus, you benefit from the 
CRC32 check.

Mateusz

[toc] | [prev] | [next] | [standalone]

#140269

In article <dbefaf2e-6e7a-4390-9260-09f5254a801f@googlegroups.com>,
Malcolm McLean  <malcolm.arthur.mclean@gmail.com> wrote:
>On Friday, 25 January 2019 15:31:54 UTC, Thiago Adams  wrote:
>> On Friday, January 25, 2019 at 1:23:16 PM UTC-2, Malcolm McLean wrote:
>> > Here's a site for C header only libraries.
>> > (You use a hash define to toggle compilation of the executable code,
>> > so the same file is both header and implementation)
>> > 
>> > The one file rule is certainly handy.
>> > 
>> > https://github.com/vurtun/mmx
>> 
>> I think header only makes sense for C++ templates and some 
>> inline functions.
>> 
>> For C, I think a pair .c and .h makes more sense.

To Thiago: Of course conservatives will say this (*), but the point is that
it doesn't mean anything for you to assert it unless you give reasons.

(*) This newsgroup (and the net in general) is full of people who just
pooh-pooh any/all new ideas.  That's why we call them "conservatives".

>But then you've got to wrap them in a zip to distribute as a single entity. 

To Malcolm: I like the idea (the single file idea), but I should point out
that it should be wrapped up in a zip file (or similar "container" format)
regardless.

BTW, the main point in favor of this method is ease of maintenance.
Everything's in one file, so if you change, say, a function signature, you
don't have to go find the other file to update it.  Having stuff spread
over more than one file always makes maintenance just that much harder.

-- 
The Trump playbook.  Every action by Trump or his supporters can be categorized as
one (or more) of:
    outrageous, incompetent, or mentally ill.

[toc] | [prev] | [next] | [standalone]

#140271

On Friday, January 25, 2019 at 3:40:12 PM UTC-2, Kenny McCormack wrote:
> In article <dbefaf2e-6e7a-4390-9260-09f5254a801f@googlegroups.com>,
> Malcolm McLean  <malcolm.arthur.mclean@gmail.com> wrote:
> >On Friday, 25 January 2019 15:31:54 UTC, Thiago Adams  wrote:
> >> On Friday, January 25, 2019 at 1:23:16 PM UTC-2, Malcolm McLean wrote:
> >> > Here's a site for C header only libraries.
> >> > (You use a hash define to toggle compilation of the executable code,
> >> > so the same file is both header and implementation)
> >> > 
> >> > The one file rule is certainly handy.
> >> > 
> >> > https://github.com/vurtun/mmx
> >> 
> >> I think header only makes sense for C++ templates and some 
> >> inline functions.
> >> 
> >> For C, I think a pair .c and .h makes more sense.
> 
> To Thiago: Of course conservatives will say this (*), but the point is that
> it doesn't mean anything for you to assert it unless you give reasons.
> 
> (*) This newsgroup (and the net in general) is full of people who just
> pooh-pooh any/all new ideas.  That's why we call them "conservatives".

Looking in more detail, the file have a flag to include implementation.
This is something different from C++ header-only libraries and I think
this the main point here but I had to open the file to see. Considering 
this flag option my previous comments can be ignored.

"QUICK:
    To use this file do:
    #define LEXER_IMPLEMENTATION
    before you include this file in *one* C or C++ file to create the implementation
"

I am happy with two files as well . (amalgamated version)

[toc] | [prev] | [next] | [standalone]

#140272

On Friday, January 25, 2019 at 3:59:36 PM UTC-2, Thiago Adams wrote:
[...]
> Looking in more detail, the file have a flag to include implementation.
> This is something different from C++ header-only libraries and I think
> this the main point here but I had to open the file to see. Considering 
> this flag option my previous comments can be ignored.

I missed the "hash define" point. 
Initially I read it as another thing... sorry.

[toc] | [prev] | [next] | [standalone]

#140284

On 25/01/2019 18:59, Thiago Adams wrote:
> On Friday, January 25, 2019 at 3:40:12 PM UTC-2, Kenny McCormack wrote:
>> In article <dbefaf2e-6e7a-4390-9260-09f5254a801f@googlegroups.com>,
>> Malcolm McLean  <malcolm.arthur.mclean@gmail.com> wrote:
>>> On Friday, 25 January 2019 15:31:54 UTC, Thiago Adams  wrote:
>>>> On Friday, January 25, 2019 at 1:23:16 PM UTC-2, Malcolm McLean wrote:
>>>>> Here's a site for C header only libraries.
>>>>> (You use a hash define to toggle compilation of the executable code,
>>>>> so the same file is both header and implementation)
>>>>>
>>>>> The one file rule is certainly handy.
>>>>>
>>>>> https://github.com/vurtun/mmx
>>>>
>>>> I think header only makes sense for C++ templates and some
>>>> inline functions.
>>>>
>>>> For C, I think a pair .c and .h makes more sense.
>>
>> To Thiago: Of course conservatives will say this (*), but the point is that
>> it doesn't mean anything for you to assert it unless you give reasons.
>>
>> (*) This newsgroup (and the net in general) is full of people who just
>> pooh-pooh any/all new ideas.  That's why we call them "conservatives".
> 
> Looking in more detail, the file have a flag to include implementation.
> This is something different from C++ header-only libraries and I think
> this the main point here but I had to open the file to see. Considering
> this flag option my previous comments can be ignored.
> 
> "QUICK:
>      To use this file do:
>      #define LEXER_IMPLEMENTATION
>      before you include this file in *one* C or C++ file to create the implementation
> "
> 
> I am happy with two files as well . (amalgamated version)
> 

So really, it is two files - a .c and a .h pair - packed together in one 
file, with a preprocessing #ifdef to choose between them?  Call me a 
conservative, but I prefer them to be separate files - that would suit 
my coding style and development practices a lot better.  But I can see 
why other people could find it convenient.

[toc] | [prev] | [next] | [standalone]

#140287

On 25/01/2019 21:17, David Brown wrote:
> On 25/01/2019 18:59, Thiago Adams wrote:

>> Looking in more detail, the file have a flag to include implementation.
>> This is something different from C++ header-only libraries and I think
>> this the main point here but I had to open the file to see. Considering
>> this flag option my previous comments can be ignored.
>>
>> "QUICK:
>>      To use this file do:
>>      #define LEXER_IMPLEMENTATION
>>      before you include this file in *one* C or C++ file to create the 
>> implementation
>> "
>>
>> I am happy with two files as well . (amalgamated version)
>>
> 
> So really, it is two files - a .c and a .h pair - packed together in one 
> file, with a preprocessing #ifdef to choose between them?  Call me a 
> conservative, but I prefer them to be separate files - that would suit 
> my coding style and development practices a lot better.  But I can see 
> why other people could find it convenient.
> 

I used to have a directive 'endinclude' in one script language, that was 
used like this:

     exported declarations...
     endinclude
     local declarations
     function definitions

When included in another module, processing stopped at 'endinclude', and 
the declarations were treated as external. Otherwise the endinclude was 
ignored.

But this was just one file, with the same extension as any other. A 
crude module system.

C can try to emulate this, but it's easy to end up compiling two 
implementations. Or none.

However the scheme used is workable, and I've used a couple of such 
libraries.

[toc] | [prev] | [next] | [standalone]

#140273

On Fri, 25 Jan 2019 17:40:00 +0000, Kenny McCormack wrote:
> BTW, the main point in favor of this method is ease of maintenance.
> Everything's in one file, so if you change, say, a function signature,
> you don't have to go find the other file to update it.  Having stuff
> spread over more than one file always makes maintenance just that much
> harder.

I really don't think having stuff in two files instead of one makes 
anything that much easier... It does limit visibility however - when I 
get a library, the first thing I do is read headers to get an idea of 
available functions, their parameters and possibly custom types. The 
header is excellent in this regard, as it provides exactly this, and only 
this (possibly with some nice comments). Getting a "one file library" 
means that I will get to look at some messy things that I am not 
interested in, instead of getting right to the point.

Mateusz

[toc] | [prev] | [next] | [standalone]

#140279

In article <5c4b5064$0$21586$426a74cc@news.free.fr>,
Mateusz Viste  <mateusz@wont.tell> wrote:
>On Fri, 25 Jan 2019 17:40:00 +0000, Kenny McCormack wrote:
>> BTW, the main point in favor of this method is ease of maintenance.
>> Everything's in one file, so if you change, say, a function signature,
>> you don't have to go find the other file to update it.  Having stuff
>> spread over more than one file always makes maintenance just that much
>> harder.
>
>I really don't think having stuff in two files instead of one makes 
>anything that much easier... It does limit visibility however - when I 
>get a library, the first thing I do is read headers to get an idea of 
>available functions, their parameters and possibly custom types. The 
>header is excellent in this regard, as it provides exactly this, and only 
>this (possibly with some nice comments). Getting a "one file library" 
>means that I will get to look at some messy things that I am not 
>interested in, instead of getting right to the point.

As Keith will tell you, users (that means you) aren't supposed to read
header files.  They are supposed to read documentaiton.

-- 
To my knowledge, Jacob Navia is not a Christian.

    - Rick C Hodgin -

[toc] | [prev] | [next] | [standalone]

#140300

gazelle@shell.xmission.com (Kenny McCormack) writes:

> In article <5c4b5064$0$21586$426a74cc@news.free.fr>,
> Mateusz Viste  <mateusz@wont.tell> wrote:
>>On Fri, 25 Jan 2019 17:40:00 +0000, Kenny McCormack wrote:
>>> BTW, the main point in favor of this method is ease of maintenance.
>>> Everything's in one file, so if you change, say, a function signature,
>>> you don't have to go find the other file to update it.  Having stuff
>>> spread over more than one file always makes maintenance just that much
>>> harder.
>>
>>I really don't think having stuff in two files instead of one makes 
>>anything that much easier... It does limit visibility however - when I 
>>get a library, the first thing I do is read headers to get an idea of 
>>available functions, their parameters and possibly custom types. The 
>>header is excellent in this regard, as it provides exactly this, and only 
>>this (possibly with some nice comments). Getting a "one file library" 
>>means that I will get to look at some messy things that I am not 
>>interested in, instead of getting right to the point.
>
> As Keith will tell you, users (that means you) aren't supposed to read
> header files.  They are supposed to read documentaiton.

When I have a need to actually read a header file, things have already
gone completely egg-shaped.  That's only one step away from using the
dreaded -E flag to gcc.

[toc] | [prev] | [next] | [standalone]

#140301

On Fri, 25 Jan 2019 19:43:44 -0700, Joe Pfeiffer wrote:
> When I have a need to actually read a header file, things have already
> gone completely egg-shaped.  That's only one step away from using the
> dreaded -E flag to gcc.

Well, if you had read the headers before playing with the library, 
perhaps things wouldn't go egg-shaped in the first place.
Documentation is cool of course, but it's often incomplete, not up to 
date, or entirely missing. Source code is the reference. And source code 
functions are declared through headers.

Mateusz

[toc] | [prev] | [next] | [standalone]

#140305

Mateusz Viste <mateusz@wont.tell> writes:

> On Fri, 25 Jan 2019 19:43:44 -0700, Joe Pfeiffer wrote:
>> When I have a need to actually read a header file, things have already
>> gone completely egg-shaped.  That's only one step away from using the
>> dreaded -E flag to gcc.
>
> Well, if you had read the headers before playing with the library, 
> perhaps things wouldn't go egg-shaped in the first place.
> Documentation is cool of course, but it's often incomplete, not up to 
> date, or entirely missing. Source code is the reference. And source code 
> functions are declared through headers.

You really think

/* Copy SRC to DEST.  */
extern char *strcpy (char *__restrict __dest, const char *__restrict __src)
     __THROW __nonnull ((1, 2));

is going to tell me more about strcpy than looking at the man page?

Yes, the documentation may be out of date, inaccurate, or missing.  But
you're going to get a lot farther by starting with the assumption that
it's right and working with that assumption until you find something
that isn't working than by reading headers with their terse at best
comments in order to try to guess how to use a library.

[toc] | [prev] | [next] | [standalone]

#140306

On Sat, 26 Jan 2019 13:39:34 -0700, Joe Pfeiffer wrote:
> You really think
> 
> /* Copy SRC to DEST.  */
> extern char *strcpy (char *__restrict __dest, const char *__restrict
> __src)
>      __THROW __nonnull ((1, 2));
> 
> is going to tell me more about strcpy than looking at the man page?

You picked a specific example. The libc documentation is awesomely 
accurate, and declarations tend to be messy. For such obviously standard 
things, documentation is the way to go. For anything less ubiquitous, 
looking at the header may provide very useful knowledge. This, for 
example, is an extract from the header file of the tinf library:

/**
 * Decompress `sourceLen` bytes of deflate data from `source` to `dest`.
 *
 * The variable `destLen` points to must contain the size of `dest` on
 * entry, and will be set to the size of the decompressed data on success.
 *
 * Reads at most `sourceLen` bytes from `source`.
 * Writes at most `*destLen` bytes to `dest`.
 *
 * @param dest pointer to where to place decompressed data
 * @param destLen pointer to variable containing size of `dest`
 * @param source pointer to compressed data
 * @param sourceLen size of compressed data
 * @return `TINF_OK` on success, error code on error
 */
int TINFCC tinf_uncompress(void *dest, unsigned int *destLen,
const void *source, unsigned int sourceLen);

Isn't it delicious?
With proper headers, documentation becomes useless.

Mateusz

[toc] | [prev] | [next] | [standalone]

#140309

Mateusz Viste <mateusz@wont.tell> writes:

> On Sat, 26 Jan 2019 13:39:34 -0700, Joe Pfeiffer wrote:
>> You really think
>> 
>> /* Copy SRC to DEST.  */
>> extern char *strcpy (char *__restrict __dest, const char *__restrict
>> __src)
>>      __THROW __nonnull ((1, 2));
>> 
>> is going to tell me more about strcpy than looking at the man page?
>
> You picked a specific example. The libc documentation is awesomely 
> accurate, and declarations tend to be messy. For such obviously standard 
> things, documentation is the way to go. For anything less ubiquitous, 
> looking at the header may provide very useful knowledge. This, for 
> example, is an extract from the header file of the tinf library:
>
> /**
>  * Decompress `sourceLen` bytes of deflate data from `source` to `dest`.
>  *
>  * The variable `destLen` points to must contain the size of `dest` on
>  * entry, and will be set to the size of the decompressed data on success.
>  *
>  * Reads at most `sourceLen` bytes from `source`.
>  * Writes at most `*destLen` bytes to `dest`.
>  *
>  * @param dest pointer to where to place decompressed data
>  * @param destLen pointer to variable containing size of `dest`
>  * @param source pointer to compressed data
>  * @param sourceLen size of compressed data
>  * @return `TINF_OK` on success, error code on error
>  */
> int TINFCC tinf_uncompress(void *dest, unsigned int *destLen,
> const void *source, unsigned int sourceLen);
>
> Isn't it delicious?
> With proper headers, documentation becomes useless.

You are considering proper header = comment + declarations.

This is a problem, because the compiler cannot validate the comments.

It would be better if the declarations alone would let you write a
program that can run without crashing.

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#140318

On Sat, 26 Jan 2019 22:29:12 +0100, "Pascal J. Bourguignon"
<pjb@informatimago.com> wrote:

>Mateusz Viste <mateusz@wont.tell> writes:
>> Isn't it delicious?
>> With proper headers, documentation becomes useless.
>
>You are considering proper header = comment + declarations.
>
>This is a problem, because the compiler cannot validate the comments.
>
>It would be better if the declarations alone would let you write a
>program that can run without crashing.

We need a new programming language that is inherently
self-documenting, using simple (dare I say, common?) verbiage, perhaps
at first oriented towards business computing.

Whatever would we call it?

[n.b. my wish list has "self-documenting code" right up there with
"world peace" and "flying cars". Any minute now.]

[toc] | [prev] | [next] | [standalone]

#140319

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Scott wrote:
> On Sat, 26 Jan 2019 22:29:12 +0100, "Pascal J. Bourguignon"
><pjb@informatimago.com> wrote:
>
>>Mateusz Viste <mateusz@wont.tell> writes:
>>> Isn't it delicious?
>>> With proper headers, documentation becomes useless.
>>
>>You are considering proper header = comment + declarations.
>>
>>This is a problem, because the compiler cannot validate the comments.
>>
>>It would be better if the declarations alone would let you write a
>>program that can run without crashing.
>
> We need a new programming language that is inherently
> self-documenting, using simple (dare I say, common?) verbiage, perhaps
> at first oriented towards business computing.
>
> Whatever would we call it?

Common Users' Simplified Programming ?

... oh, business.  Who would ever write a Common Business Oriented
Language, anyway?

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAlxNl7kACgkQjhHd8xJ5
ooEpbwf/bvj6Xh+DKD6I0VwdPEkZriWNYkCMRhtPba1Vqn3dJ1oDXTIlSyQ7TXhb
3La3Vu83x2A8xWfXtQNdALNjELQZD2+9fkP5o4e/7HUApcZyPtdD+7aRag1I8nBd
/RVE27h0m3ozm3HDubXBFlJtdnV/p6dFzYBXnNM2kDNfhFYOnRbRGCq1g1DVAWWI
iTO2AhaxugouPhwa6SzcQZSLAocE2XgqBHieoRv0Oi9pQxeLmtG/k4Tmcdrn9i5Q
4kimmzKOGI/QVhh3t1MCbXpRaT4EACByk+Ks2D14PPxPyT5HNMNinQb+duLXEc+t
vTYX/a80lm4ecmGS2h/rWAwxp3yCSg==
=W1Cd
-----END PGP SIGNATURE-----

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#141356

nobody@example.org (Scott) writes:

> On Sat, 26 Jan 2019 22:29:12 +0100, "Pascal J. Bourguignon"
> <pjb@informatimago.com> wrote:
>
>> Mateusz Viste <mateusz@wont.tell> writes:
>>
>>> Isn't it delicious?
>>> With proper headers, documentation becomes useless.
>>
>> You are considering proper header = comment + declarations.
>>
>> This is a problem, because the compiler cannot validate the comments.
>>
>> It would be better if the declarations alone would let you write a
>> program that can run without crashing.
>
> We need a new programming language that is inherently
> self-documenting, using simple (dare I say, common?) verbiage, perhaps
> at first oriented towards business computing.
>
> Whatever would we call it?

Hmmm...  how about Administrative Programming Language?

[toc] | [prev] | [next] | [standalone]

#141507

nobody@example.org (Scott) writes:
 
> On Sat, 26 Jan 2019 22:29:12 +0100, "Pascal J. Bourguignon"
> <pjb@informatimago.com> wrote:
>
> We need a new programming language that is inherently self-documenting,
> using simple (dare I say, common?) verbiage, perhaps at first oriented
> towards business computing.

Wasn't that the entire purpose of Donald Knuth's CWEB? Mind you, I've 
never actually used it. I'm not afraid of writing documentation.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web