Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #402418 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-09-27 10:20 +0200 |
| Last post | 2026-09-28 00:02 +0200 |
| Articles | 20 on this page of 129 — 16 participants |
Back to article view | Back to comp.lang.c
official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-27 10:20 +0200
Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-27 20:04 +0200
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-27 21:38 +0100
Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-27 23:16 +0200
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 00:53 +0100
Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-28 04:31 +0200
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-28 10:25 +0200
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 11:45 +0100
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-28 13:56 +0200
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 14:38 +0100
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-28 16:12 +0200
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 16:52 +0100
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-28 18:49 +0200
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 20:26 +0100
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-29 09:45 +0200
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 12:54 +0100
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-29 15:56 +0200
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 18:15 +0100
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-29 20:24 +0200
Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-09-29 19:41 +0000
Re: official library of tiny functions lacking in c cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-29 21:37 +0000
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 01:33 +0100
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 09:28 +0200
Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 13:41 +0300
Re: official library of tiny functions lacking in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 07:25 -0700
Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-10-01 17:50 +0300
Re: official library of tiny functions lacking in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 09:37 -0700
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 01:19 +0100
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 09:44 +0200
Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-29 16:01 +0200
Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-30 01:00 -0700
Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 13:01 +0200
Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-01 08:52 +0000
Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 01:56 +0000
Re: official library of tiny functions lacking in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 07:15 -0700
Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-29 09:28 +0200
Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 07:10 +0000
Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-28 15:30 -0700
Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-29 09:03 +0200
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 11:11 +0100
Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-09-29 14:38 +0000
Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 07:02 +0200
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 11:35 +0100
Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 14:14 +0200
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 13:45 +0100
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 15:30 +0200
Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 17:14 +0300
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 16:42 +0200
Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 18:02 +0300
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 16:54 +0100
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 18:26 +0200
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 22:12 +0100
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-10-01 09:44 +0200
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-10-01 10:42 +0100
Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-10-01 13:50 +0300
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-10-01 12:29 +0100
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-10-02 09:35 +0200
Re: official library of tiny functions lacking in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-02 04:03 -0700
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-10-02 13:50 +0200
Re: official library of tiny functions lacking in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-02 11:22 -0700
Re: official library of tiny functions lacking in c gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-02 18:33 +0000
Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-10-03 14:30 +0000
Re: official library of tiny functions lacking in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-03 16:37 -0700
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-10-01 13:29 +0200
Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-10-01 14:46 +0000
Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-01 15:37 -0700
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-10-02 08:57 +0200
Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-02 00:37 -0700
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 17:12 +0100
Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 14:09 +0300
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 13:55 +0200
Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 14:31 +0200
Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 16:12 +0300
Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 19:33 +0200
Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-09-30 18:14 +0000
Re: official library of tiny functions lacking in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-01 08:34 -0400
Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 07:08 +0000
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 15:02 +0100
Re: official library of tiny functions lacking in c scott@slp53.sl.home (Scott Lurndal) - 2026-09-29 14:43 +0000
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 16:07 +0100
Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 22:58 +0000
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 00:13 +0100
Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 07:13 +0000
Re: official library of tiny functions lacking in c Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-01 02:41 +0800
Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 14:15 +0300
Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 14:18 +0300
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 13:24 +0100
Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 14:45 +0200
Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 15:56 +0300
Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 22:31 +0000
Re: official library of tiny functions lacking in c Michael S <already5chosen@yahoo.com> - 2026-09-30 14:32 +0300
Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-28 17:22 +0200
Re: official library of tiny functions lacking in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-28 17:24 -0700
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-29 09:54 +0200
Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-29 16:48 -0700
Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-28 14:16 +0200
Re: official library of tiny functions lacking in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-09-28 11:15 -0400
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 16:40 +0100
Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-29 16:50 -0700
Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 06:38 +0000
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 14:36 +0100
Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 22:49 +0000
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-29 23:59 +0100
Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-29 16:51 -0700
Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 01:54 +0000
Re: official library of tiny functions lacking in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-09-29 22:09 -0400
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-30 10:52 +0100
Re: official library of tiny functions lacking in c David Brown <david.brown@hesbynett.no> - 2026-09-30 12:38 +0200
Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-01 08:49 +0000
Re: official library of tiny functions lacking in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-01 08:48 -0400
Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-28 06:45 +0000
Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-28 12:42 +0200
Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 00:58 +0000
Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-29 03:02 +0200
Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 03:16 +0000
Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-29 14:20 +0200
Re: official library of tiny functions lacking in c Paul <nospam@needed.invalid> - 2026-09-29 12:39 -0400
Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 22:50 +0000
Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-30 02:57 +0200
Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 02:00 +0000
Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-30 10:08 +0200
Re: official library of tiny functions lacking in c fir <profesor.fir@gmail.com> - 2026-09-30 13:58 +0200
Re: official library of tiny functions lacking in c bart <bc@freeuk.com> - 2026-09-28 11:43 +0100
Re: official library of tiny functions lacking in c Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 01:00 +0000
Re: official library of tiny functions lacking in c Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-30 07:59 +0200
Re: official library of tiny functions lacking in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-09-28 11:03 -0400
Re: official library of tiny functions lacking in c NOTE fir <profesor.fir@gmail.com> - 2026-09-28 17:50 +0200
Re: official library of tiny functions lacking in c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-30 12:42 -0700
Re: official library of tiny functions lacking in c tTh <tth@none.invalid> - 2026-09-28 00:02 +0200
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-09-29 21:37 +0000 |
| Message-ID | <119hb3e$lm9$1@reader1.panix.com> |
| In reply to | #402515 |
In article <WvUuS.292$M0U7.280@fx10.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >David Brown <david.brown@hesbynett.no> writes: >>On 29/09/2026 19:15, bart wrote: >> > <snip> > >>There is /nothing/ wrong with making a simple "print" function. >> >>There is a lot wrong with making it a special language feature, instead >>of a normal function (or other language construct - object, template, >>generic, whatever) that is defined in the standard library, using the >>language itself. >> >>If you can't make a suitable "print" facility that way, your language is >>weak and limited. It might be okay for some purposes, but not for >>general usage. (And if you /can/ make it part of the standard library, >>you /should/ make it part of the standard library - even if your >>language then imports that library by default.) > >Agreed. >> >>> >>> What other destinations can you think of? Bear in mind that in Linux, >>> most such things seems to be part of the file system, and that is >>> already covered. >>> >> >>Not everything you might want to do in Linux is part of the file system >>- far from it. > >Some examples often used in server code: > > - The host log framework (e.g. syslog) is a common destination > - A network TCP/UDP port > - A custom multiplexer to send the output to multiple destinations To be fair to Bart, I think he was implying that L/Unix systems try to use a uniform interface for IO, modeling endpoints as if they were files, associating those endpoints with small integers that resemble file descriptors, and using those for indirection between the system calls that effect actual IO and a userspace program. So the file descriptors returned by `open` behave an awful lot like the pair allocated to a pipe or socketpair, which bear a striking resemblence to a socket descriptor, and so on; all can be the target of a `write`, or `read`, or `close`. Of course there are some differences as those are different kinds of objects after all. What does `lseek` mean on a pipe? It doesn't; it's a category error, and POSIX defines it thusly. But in terms of general shape of the interface, the analogy is not bad, though it's not the "filesystem" that does this, but rather, the file-related API. Of course, those _system calls_ don't do formatting of their own (modulo a tty layer that might do, say, line end conversions or things like that). >There is a lot to be said for the terseness of *printf formatting, >particularly with compilers that check the type correctness of the printf >varargs list. I'd say the real winning example is `snprintf`, where one can format directly into a character array. It is difficult to understate the utility this; but if `print` were built into the language, you'd lose it, unless you also had a `sprint` builtin. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-30 01:33 +0100 |
| Message-ID | <119hlcc$3pmrh$1@dont-email.me> |
| In reply to | #402516 |
On 29/09/2026 22:37, Dan Cross wrote:
>> There is a lot to be said for the terseness of *printf formatting,
>> particularly with compilers that check the type correctness of the printf
>> varargs list.
>
> I'd say the real winning example is `snprintf`, where one can
> format directly into a character array. It is difficult to
> understate the utility this; but if `print` were built into the
> language, you'd lose it, unless you also had a `sprint` builtin.
Printing to a string works like this:
[300]char str
print @str, a, b, c
In my other language, then `sprint(a, b, c)` will directly return the
string. Both print and sprint are keywords.
In that one, a key part is the 'tostr()' operator that stringifies print
arguments, and which can be invoked directly.
However, I can also choose to just call C's 'sprintf'.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-30 09:28 +0200 |
| Message-ID | <119idn6$3vj3k$1@dont-email.me> |
| In reply to | #402516 |
On 29/09/2026 23:37, Dan Cross wrote: > In article <WvUuS.292$M0U7.280@fx10.iad>, > Scott Lurndal <slp53@pacbell.net> wrote: > >> There is a lot to be said for the terseness of *printf formatting, >> particularly with compilers that check the type correctness of the printf >> varargs list. > > I'd say the real winning example is `snprintf`, where one can > format directly into a character array. It is difficult to > understate the utility this; but if `print` were built into the > language, you'd lose it, unless you also had a `sprint` builtin. > snprintf is the printf family member I use most, and occasionally vsnprintf. Other people will likely make heavy use of fprintf too. And I often use the return value of printf (or rather, snprintf) to see if I've cut the output short. So a special language feature for "print" would have to have either multiple additional special builtins, or a ridiculously complicated one that supports everything in one statement type that differs from all normal functions in the language. And that's just the start. People like to write their own functions "log_printf", or "debug_printf", with varieties of additional features that suit their needs - while still retaining the printf-style formatting and the compiler checks of argument types and number. Extended standard libraries and OS-specific libraries go further, such as having locking systems to avoid mixing output from different threads, or cut-down versions without floating point for small microcontrollers. A quick glance at newlib's documentation shows 34 functions with "printf" in the name. Most people only use a few of them, but all of them are useful to someone.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-30 13:41 +0300 |
| Message-ID | <20260930134100.00004ff0@yahoo.com> |
| In reply to | #402541 |
On Wed, 30 Sep 2026 09:28:38 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 29/09/2026 23:37, Dan Cross wrote: > > In article <WvUuS.292$M0U7.280@fx10.iad>, > > Scott Lurndal <slp53@pacbell.net> wrote: > > > >> There is a lot to be said for the terseness of *printf formatting, > >> particularly with compilers that check the type correctness of the > >> printf varargs list. > > > > I'd say the real winning example is `snprintf`, where one can > > format directly into a character array. It is difficult to > > understate the utility this; but if `print` were built into the > > language, you'd lose it, unless you also had a `sprint` builtin. > > > > snprintf is the printf family member I use most, and occasionally > vsnprintf. > Other people will likely make heavy use of fprintf too. > > And I often use the return value of printf (or rather, snprintf) to > see if I've cut the output short. > As was already discussed here 5 years ago, return value of snprintf does not fit my most common usage pattern, which is to add strings to buffer until it is full and to drop silently the remaining parts after buffer is full. I.e. to produce sequences of format calls that behave similarly to an individual snprintf. Interested reader could still find discussion, including code, by searching comp.lang on Google groups for my_snprintf. Unfortunately, with recent breakage of GG I no longer can provide a working link to either individual article or the thread. > So a special language feature for "print" would have to have either > multiple additional special builtins, or a ridiculously complicated > one that supports everything in one statement type that differs from > all normal functions in the language. > > > And that's just the start. People like to write their own functions > "log_printf", or "debug_printf", with varieties of additional > features that suit their needs - while still retaining the > printf-style formatting and the compiler checks of argument types and > number. Extended standard libraries and OS-specific libraries go > further, such as having locking systems to avoid mixing output from > different threads, or cut-down versions without floating point for > small microcontrollers. A quick glance at newlib's documentation > shows 34 functions with "printf" in the name. Most people only use a > few of them, but all of them are useful to someone. > > >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-01 07:25 -0700 |
| Message-ID | <868q4hpkfu.fsf@linuxsc.com> |
| In reply to | #402549 |
Michael S <already5chosen@yahoo.com> writes: > On Wed, 30 Sep 2026 09:28:38 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 29/09/2026 23:37, Dan Cross wrote: >> >>> In article <WvUuS.292$M0U7.280@fx10.iad>, >>> Scott Lurndal <slp53@pacbell.net> wrote: >>> >>>> There is a lot to be said for the terseness of *printf formatting, >>>> particularly with compilers that check the type correctness of the >>>> printf varargs list. >>> >>> I'd say the real winning example is `snprintf`, where one can >>> format directly into a character array. It is difficult to >>> understate the utility this; but if `print` were built into the >>> language, you'd lose it, unless you also had a `sprint` builtin. >> >> snprintf is the printf family member I use most, and occasionally >> vsnprintf. >> Other people will likely make heavy use of fprintf too. >> >> And I often use the return value of printf (or rather, snprintf) to >> see if I've cut the output short. > > As was already discussed here 5 years ago, return value of snprintf > does not fit my most common usage pattern, which is to add strings to > buffer until it is full and to drop silently the remaining parts after > buffer is full. I.e. to produce sequences of format calls that behave > similarly to an individual snprintf. > > Interested reader could still find discussion, including code, by > searching comp.lang on Google groups for my_snprintf. > Unfortunately, with recent breakage of GG I no longer can provide a > working link to either individual article or the thread. I haven't done any searching, but let me ask: did what you posted have maybe 15 or 20 lines of code plus a typedef or two?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-01 17:50 +0300 |
| Message-ID | <20261001175014.00006ad5@yahoo.com> |
| In reply to | #402620 |
On Thu, 01 Oct 2026 07:25:09 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > > On Wed, 30 Sep 2026 09:28:38 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > > > >> On 29/09/2026 23:37, Dan Cross wrote: > >> > >>> In article <WvUuS.292$M0U7.280@fx10.iad>, > >>> Scott Lurndal <slp53@pacbell.net> wrote: > >>> > >>>> There is a lot to be said for the terseness of *printf > >>>> formatting, particularly with compilers that check the type > >>>> correctness of the printf varargs list. > >>> > >>> I'd say the real winning example is `snprintf`, where one can > >>> format directly into a character array. It is difficult to > >>> understate the utility this; but if `print` were built into the > >>> language, you'd lose it, unless you also had a `sprint` builtin. > >> > >> snprintf is the printf family member I use most, and occasionally > >> vsnprintf. > >> Other people will likely make heavy use of fprintf too. > >> > >> And I often use the return value of printf (or rather, snprintf) to > >> see if I've cut the output short. > > > > As was already discussed here 5 years ago, return value of snprintf > > does not fit my most common usage pattern, which is to add strings > > to buffer until it is full and to drop silently the remaining parts > > after buffer is full. I.e. to produce sequences of format calls > > that behave similarly to an individual snprintf. > > > > Interested reader could still find discussion, including code, by > > searching comp.lang on Google groups for my_snprintf. > > Unfortunately, with recent breakage of GG I no longer can provide a > > working link to either individual article or the thread. > > I haven't done any searching, but let me ask: did what you posted > have maybe 15 or 20 lines of code plus a typedef or two? Lines of code - yes, not counting lines of comments at the beginning. Typedef - I don't recollect typedef. You commented on my code pointing out that an absence of va_end at the end is non-portable. Also you were not happy with my choice of signed type for bufsz argument. Your other suggestion was to provide va_list variant of the function in addition to vararg (i.e. ...) variant.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-01 09:37 -0700 |
| Message-ID | <86v77lnzr2.fsf@linuxsc.com> |
| In reply to | #402622 |
Michael S <already5chosen@yahoo.com> writes: > On Thu, 01 Oct 2026 07:25:09 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> On Wed, 30 Sep 2026 09:28:38 +0200 >>> David Brown <david.brown@hesbynett.no> wrote: >>> >>>> On 29/09/2026 23:37, Dan Cross wrote: >>>> >>>>> In article <WvUuS.292$M0U7.280@fx10.iad>, >>>>> Scott Lurndal <slp53@pacbell.net> wrote: >>>>> >>>>>> There is a lot to be said for the terseness of *printf >>>>>> formatting, particularly with compilers that check the type >>>>>> correctness of the printf varargs list. >>>>> >>>>> I'd say the real winning example is `snprintf`, where one can >>>>> format directly into a character array. It is difficult to >>>>> understate the utility this; but if `print` were built into the >>>>> language, you'd lose it, unless you also had a `sprint` builtin. >>>> >>>> snprintf is the printf family member I use most, and occasionally >>>> vsnprintf. >>>> Other people will likely make heavy use of fprintf too. >>>> >>>> And I often use the return value of printf (or rather, snprintf) to >>>> see if I've cut the output short. >>> >>> As was already discussed here 5 years ago, return value of snprintf >>> does not fit my most common usage pattern, which is to add strings >>> to buffer until it is full and to drop silently the remaining parts >>> after buffer is full. I.e. to produce sequences of format calls >>> that behave similarly to an individual snprintf. >>> >>> Interested reader could still find discussion, including code, by >>> searching comp.lang on Google groups for my_snprintf. >>> Unfortunately, with recent breakage of GG I no longer can provide a >>> working link to either individual article or the thread. >> >> I haven't done any searching, but let me ask: did what you posted >> have maybe 15 or 20 lines of code plus a typedef or two? > > Lines of code - yes, not counting lines of comments at the beginning. > Typedef - I don't recollect typedef. > You commented on my code pointing out that an absence of va_end at the > end is non-portable. [and other comments] Oh so I did. Apparently my memory is getting worse as years go by.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-30 01:19 +0100 |
| Message-ID | <119hki9$3pf9o$1@dont-email.me> |
| In reply to | #402514 |
On 29/09/2026 19:24, David Brown wrote: > On 29/09/2026 19:15, bart wrote: >> On 29/09/2026 14:56, David Brown wrote: >>> On 29/09/2026 13:54, bart wrote: >>>> My claim is that all these tasks can be done with Print, and it is >>>> useful to have it as a built-in feature. >>> >>> Built-in print is great for "Hello, world!" level programs, and a bit >>> beyond that - but it quickly fails for larger needs. >> >> That is nonsense. >> >>>> Such as? Come on, give me a challenge! >>> >>> I gave some already. >>> >>> Other things include formatted output to log files, formatting of >>> different types (not just built-in ones), saving logs in eeprom, >>> using different languages for the fixed parts of the strings. >>> Basically, anything that the toolchain writer and/or language >>> designer didn't think of in the first place. >> And yet some sort of friendlier Print feature is generally provided by >> a language, on top of a set of I/O routines. >> >> For example Lua has print() as well as io.write. I think Python also >> has 'io', and 'sys', and 'os'. >> >> So they recognise that providing the simpler Print feature as well >> adds something. >> >> So do I! I just go further and make it built-in to make even more >> convenient and with nicer syntax. >> > > There is /nothing/ wrong with making a simple "print" function. > > There is a lot wrong with making it a special language feature, instead > of a normal function (or other language construct - object, template, > generic, whatever) that is defined in the standard library, using the > language itself. > > If you can't make a suitable "print" facility that way, your language is > weak and limited. That's your opinion. You like such features, you like DIY languages, and you like lots of moving pieces. In general, you like complexity. I don't like language-building features as they make for a more complicated, harder-to-understand and slower-to-compile language. I also like things self-contained and tidy. My Print works. As for any special tasks, they will be no different from any other; you just write some code like for anything else. > It might be okay for some purposes, but not for > general usage. (And if you /can/ make it part of the standard library, > you /should/ make it part of the standard library - even if your > language then imports that library by default.) Nothing stops anyone writing their own library of print-related routines, even in my language. But if they also want decent ergonomics, then they will need advanced features; they will need to look elsewhere. >> >> What other destinations can you think of? Bear in mind that in Linux, >> most such things seems to be part of the file system, and that is >> already covered. >> > > Not everything you might want to do in Linux is part of the file system > - far from it. And not all programs run on Windows or Linux. > > /I/ am not the one implicitly claiming to know all possible > destinations, uses or combinations so that it's fine to nail it into a > language special feature. But you seem certain that a Print feature like that can't work! I think after some decades of use, I would have noticed. > You class everything that is not part of your beloved language as a > "hack". In the case of C, then I've seen enough system header files to justifiably call them hacks. In fact I'll go further and call them ugly hacks. That's how C seems to work. > You'll forgive me for not taking your opinion or > classifications seriously. That's fine. I don't take your dismissal of built-in Print (and Read) seriously either.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-30 09:44 +0200 |
| Message-ID | <119iekf$3vj3k$2@dont-email.me> |
| In reply to | #402527 |
On 30/09/2026 02:19, bart wrote: > On 29/09/2026 19:24, David Brown wrote: >> On 29/09/2026 19:15, bart wrote: >>> On 29/09/2026 14:56, David Brown wrote: >>>> On 29/09/2026 13:54, bart wrote: >>>>> My claim is that all these tasks can be done with Print, and it is >>>>> useful to have it as a built-in feature. >>>> >>>> Built-in print is great for "Hello, world!" level programs, and a >>>> bit beyond that - but it quickly fails for larger needs. >>> >>> That is nonsense. >>> >>>>> Such as? Come on, give me a challenge! >>>> >>>> I gave some already. >>>> >>>> Other things include formatted output to log files, formatting of >>>> different types (not just built-in ones), saving logs in eeprom, >>>> using different languages for the fixed parts of the strings. >>>> Basically, anything that the toolchain writer and/or language >>>> designer didn't think of in the first place. >>> And yet some sort of friendlier Print feature is generally provided >>> by a language, on top of a set of I/O routines. >>> >>> For example Lua has print() as well as io.write. I think Python also >>> has 'io', and 'sys', and 'os'. >>> >>> So they recognise that providing the simpler Print feature as well >>> adds something. >>> >>> So do I! I just go further and make it built-in to make even more >>> convenient and with nicer syntax. >>> >> >> There is /nothing/ wrong with making a simple "print" function. >> >> There is a lot wrong with making it a special language feature, >> instead of a normal function (or other language construct - object, >> template, generic, whatever) that is defined in the standard library, >> using the language itself. >> >> If you can't make a suitable "print" facility that way, your language >> is weak and limited. > > That's your opinion. You like such features, you like DIY languages, and > you like lots of moving pieces. In general, you like complexity. > Your record for speculation about other people's likes and dislikes is not improving. It is important for a language - a /real/ language used by more than one person - that these things can be library functions written in the language itself. It is not important that they, specifically, implement them - it is important that /someone/ other than the compiler writer can do so. No normal C programmer wants to implement their own "printf" in all its glory and complexity. But many want it to be possible for /library/ implementers to do so. For example, in microcontroller programming you might pick a C library where "printf" does not support floating point, because it is then significantly smaller (especially on processors that do not have hardware floating point). People who have to use a poor quality C compiler like MSVC that does not support C99 can use a third-party implementation of printf that /does/ support C99, and useful POSIX printf extensions. And it is common to write "wrapper" functions for output - functions (or macros) that can take a format string and variadic parameters, use snprintf() or similar to do the hard work, then send the output where they want. You can only do that if your language supports the facilities needed for making your own code in the style of a "print" feature. Once you have that in the language, a built-in feature is basically pointless. Powerful languages don't mean you /have/ to write stuff yourself, or that you have to like writing complex code - it also means you can use great stuff written by other people. And yes, some of the implementation code for these things can be ugly and complex - the "user interface" as seen by most C programmers is the "printf" function, not the implementation of it. > >> You class everything that is not part of your beloved language as a >> "hack". > > In the case of C, then I've seen enough system header files to > justifiably call them hacks. In fact I'll go further and call them ugly > hacks. That's how C seems to work. > >> You'll forgive me for not taking your opinion or classifications >> seriously. > > That's fine. I don't take your dismissal of built-in Print (and Read) > seriously either. > That's entirely fair!
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-29 16:01 +0200 |
| Message-ID | <119ggci$1uuce$5@dont-email.me> |
| In reply to | #402497 |
On 2026-09-29 09:45, David Brown wrote: > On 28/09/2026 21:26, bart wrote: >> On 28/09/2026 17:49, David Brown wrote: >>> On 28/09/2026 17:52, bart wrote: >> >>>> Yes, I know, most languages prefer to have things in libraries >>>> rather than in the core. >>> >>> So perhaps it's a good idea? >> >> IS it a good idea? Or is it just what is commonly done and people go >> along with it? > > Putting functions in standard libraries is commonly done because it is a > good idea. > > Very occasionally, in some field of thought, someone will come along > with a crazy idea that is different from the way everyone else does > things, and their new way is revolutionary and changes the field > forever. [...] Sometimes it's not even a "crazy idea" or "revolutionary"; I recall we "replaced" malloc() and free() by own versions to keep track of memory allocation, and to find unused but unreleased memory chunks. (It's not printf() but these are also central functions of "C".) That was about 35 years ago - meanwhile there's many tools existing. >>> [...] >> >> No, they usually can't. Functions generally take a fixed number of >> parameters, and in a typed language, they are also usually a fixed type. What folly are you emitting again! - printf/scanf, or more general "varargs" in "C", write/ln in Pascal, Awk where you can pass what you like (sort of), the Unix shell, languages that have per design no fixed number of arguments, languages that use clever mechanisms to pass many arguments in the form a single argument sequence, and whatnot. And quite some of those have their mechanisms implemented even type-safe. > > Lots of languages have various methods for doing otherwise. Variadic > functions, typeless parameters, function overloads, generic functions - > these are all common in programming languages. They don't need built- > ins. With greater freedom of use comes less compile-time checking - > that's an inevitable tradeoff to some extent. > [...] > > Yes, BASIC - and your language - are simple for simple programs ]...] > > When I was a teenager, I really enjoyed programming in BASIC, and wrote > a lot of cool little programs on various computers. And there is no > doubt that some things then were a lot simpler than writing the same > thing in C. [...] Interesting. - As teenager I also wrote lots of fancy BASIC programs. But as soon as Pascal was available that was a lot more fun (for me), and a bit step forward! With "C" things degraded, though. (Again, for me.) Janis
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-09-30 01:00 -0700 |
| Message-ID | <119ifjk$1fi0$1@dont-email.me> |
| In reply to | #402507 |
On 9/29/2026 7:01 AM, Janis Papanagnou wrote:
[...]
> Interesting. - As teenager I also wrote lots of fancy BASIC programs.
> But as soon as Pascal was available that was a lot more fun (for me),
> and a bit step forward! With "C" things degraded, though. (Again, for
> me.)
As a kid, I used to love making BASIC programs that would create other
programs that could be run from EXEC in prodos. Fun times.
https://www.facebook.com/share/p/19WtuBnkrX/
Here is a more self-contained version of my generator. It asks you how
many vertices to enter. Builds CTTEST.BAS, then you can just EXEC
CTTEST.BAS to run it. Here is my code. Just for fun. The generated code
draws a bunch of polys using the table LT. Btw, can you get it to work
on your end?
_______________________________
10 REM CREATE NEW PROGRAM FILE
11 INPUT "Enter Polygon Points: "; N$
12 LN = ABS(VAL(N$))
15 PRINT "Generating " + STR$(LN) + "-Gon CTTEST.BAS..."
20 D$ = CHR$(4)
25 PRINT D$; "DELETE CTTEST.BAS"
22 ONERR GOTO 28
28 POKE 216,0
30 PRINT D$; "OPEN CTTEST.BAS"
40 PRINT D$; "WRITE CTTEST.BAS"
50 REM HOME
60 PC = 10
65 PRINT "NEW"
70 P0$ = "REM " + CHR$(34) + "ct_spawn_test" + CHR$(34): GOSUB 5000
80 P0$ = "PRINT " + CHR$(34) + "Chris M. Thomasson Spawn" + CHR$(34):
GOSUB 5000
101 P0$ = "LN = " + STR$(LN): GOSUB 5000
120 AB = ATN(1) * 4
130 SN = (AB * 2) / LN
140 DIM LT(LN, 2)
141 P0$ = "DIM LT(" + STR$(LN) + ", 2)": GOSUB 5000
150 FOR I = 1 TO LN
160 A = I * SN
165 LT(I, 1) = COS(A)
166 LT(I, 2) = SIN(A)
171 P0$ = "LT(" + STR$(I) + ", 1) = " + STR$(COS(A)): GOSUB 5000
181 P0$ = "LT(" + STR$(I) + ", 2) = " + STR$(SIN(A)): GOSUB 5000
290 NEXT I
300 X0 = 292/2: X1 = 292/6: Y0 = 192/2: Y1 = 192/4
301 P0$ = "X0 = " + STR$(X0) + ": X1 = " + STR$(X1): GOSUB 5000
311 P0$ = "Y0 = " + STR$(Y0) + ": Y1 = " + STR$(Y1): GOSUB 5000
321 P0$ = "HGR : HCOLOR = 3": GOSUB 5000
430 P0$ = "DIM C0(5)": GOSUB 5000
441 P0$ = "FOR I = 1 TO LN": GOSUB 5000
442 P0$ = "C0(1) = X0 + LT(I,1) * 24: C0(2) = Y0 + LT(I,2) * 24: C0(3) =
.5 * X1: C0(4) = .5 * Y1 :C0(5) = LN: GOSUB 1000": GOSUB 5000
443 P0$ = "NEXT I": GOSUB 5000
470 P0$ = "END": GOSUB 5000
800 PC = 1000
810 P0$ = "REM PLOT POLY C0(x, y, rx, ry, n)": GOSUB 5000
820 P0$ = "HPLOT C0(1) + LT(1, 1) * C0(3), C0(2) + LT(1, 2) * C0(4)":
GOSUB 5000
830 P0$ = "FOR I0 = 2 TO C0(5)": GOSUB 5000
840 P0$ = " HPLOT TO C0(1) + LT(I0, 1) * C0(3), C0(2) + LT(I0, 2) *
C0(4)": GOSUB 5000
850 P0$ = "NEXT I0": GOSUB 5000
860 P0$ = "HPLOT TO C0(1) + LT(1, 1) * C0(3), C0(2) + LT(1, 2) * C0(4)":
GOSUB 5000
870 P0$ = "RETURN": GOSUB 5000
890 GOTO 6000
5000 REM PUSH LINE
5010 PRINT STR$(PC) + " " + P0$
5020 PC = PC + 10
5030 RETURN
6000 REM CLOSE FILE
6005 PRINT "RUN"
6010 PRINT D$; "CLOSE"
6020 PRINT "Complete! :^)"
6030 END
_______________________________
you can run it here: https://www.scullinsteel.com/apple/e
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-30 13:01 +0200 |
| Message-ID | <119iq5s$3quji$2@dont-email.me> |
| In reply to | #402543 |
On 2026-09-30 10:00, Chris M. Thomasson wrote: > On 9/29/2026 7:01 AM, Janis Papanagnou wrote: >> [...] > As a kid, I used to love making BASIC programs that would create other > programs that could be run from EXEC in prodos. Fun times. Sure. :-) > [...] > > Here is a more self-contained version of my generator. It asks you how > many vertices to enter. Builds CTTEST.BAS, then you can just EXEC > CTTEST.BAS to run it. Here is my code. Just for fun. The generated code > draws a bunch of polys using the table LT. Btw, can you get it to work > on your end? Bear with me that I don't even try. :-) > [ snip BASIC program ] I mentioned before that as soon as I've got a (much) better language (back these days it was Pascal) I (almost) never ever touched BASIC again. The one recent exception was a try to transcribe a Lunar Lander application written in some 1960's BASIC to a more "modern" structured language; in my case it was Algol 68. :-p Let me tell you, that was a pain. All the spaghetti chaos refactoring to sensible code structures, but also the adaption of the old syntax to a new one to be able to use an existing BASIC system to verify correctness of the legacy vs. new output. At the end it was so much effort that it would have been much better to just get the formulas and implement it from scratch instead. Janis
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-01 08:52 +0000 |
| Message-ID | <119l717$10m8m$4@dont-email.me> |
| In reply to | #402543 |
On Wed, 30 Sep 2026 01:00:22 -0700, Chris M. Thomasson wrote: > Here is a more self-contained version of my generator. It asks you > how many vertices to enter. Builds CTTEST.BAS, then you can just > EXEC CTTEST.BAS to run it. Here is my code. Just for fun. The > generated code draws a bunch of polys using the table LT. That’s one way to create dynamic data structures from a language which, on the face of it, has no built-in support for that. Turing-equivalence, after all, is an entirely separate issue from whether the language is actually convenient to use. That’s the difference between mathematicians and computer scientists, as to which of the two they care more about.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-30 01:56 +0000 |
| Message-ID | <119hq88$3r0er$2@dont-email.me> |
| In reply to | #402471 |
On Mon, 28 Sep 2026 20:26:46 +0100, bart wrote: > I always find it odd when people strive to keep a core language to a > few dozen keywords to reduce 'cognitive load', but are fine with > needing to use a library that exports a thousand identifiers, all in > the same namespace. That’s what “modularity” is all about. And why it can be helpful to have selective import, so you only bring in what you need. That is, if you really want to use those names without qualification. Otherwise just import the module name, and qualify all references to its contents with that name. That, too, helps keep namespace pollution under control.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-01 07:15 -0700 |
| Message-ID | <86cxttpkwc.fsf@linuxsc.com> |
| In reply to | #402471 |
bart <bc@freeuk.com> writes: > On 28/09/2026 17:49, David Brown wrote: > >> On 28/09/2026 17:52, bart wrote: >> >>> Yes, I know, most languages prefer to have things in libraries >>> rather than in the core. >> >> So perhaps it's a good idea? > > IS it a good idea? Yes.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-29 09:28 +0200 |
| Message-ID | <119fpap$1uuce$4@dont-email.me> |
| In reply to | #402467 |
On 2026-09-28 18:49, David Brown wrote: > On 28/09/2026 17:52, bart wrote: >> >> But one example where built-in is better is with Print. Otherwise this >> presents challenges to do in user-code: The last "prominent" languages with a built-in 'print' I recall to have used were BASIC, and Awk. (Other languages I used, starting with Pascal, Algol 68, C/C++, Shell, etc. had just predefined functions that are defined in the program environment and that could (whether it makes sense or not) be replaced and shadowed. YMMV. - What modern languages - I'm not asking for any of your irrelevant personal designed languages - have that built-in in the language? I'm curious.) The historically strangest language definition in that respect was IIRC Algol 60, where initially no I/O had been standardized at all; that was defined by the various language implementations independently depending on the platform. > No, "print" is not "better" as a built-in. That's pure bias on your part. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-29 07:10 +0000 |
| Message-ID | <119fo8b$315co$3@dont-email.me> |
| In reply to | #402466 |
On Mon, 28 Sep 2026 16:52:06 +0100, bart wrote: > But one example where built-in is better is with Print. Otherwise > this presents challenges to do in user-code: That’s just a language limitation. Python can do it type-safely. And if you think that’s an unfair example, Algol 68 also worked out a way to implement variadic/polymorphic functions in a type-safe manner.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-09-28 15:30 -0700 |
| Message-ID | <119epqg$2p1fp$1@dont-email.me> |
| In reply to | #402459 |
On 9/28/2026 7:12 AM, David Brown wrote: [...] Fwiw, fun times! :^) https://forums.parallax.com/discussion/147522/dog-leg-hypotenuse-approximation
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-29 09:03 +0200 |
| Message-ID | <119fns9$1uuce$3@dont-email.me> |
| In reply to | #402459 |
On 2026-09-28 16:12, David Brown wrote: > On 28/09/2026 15:38, bart wrote: >> >> - Always available without needing those annoying #includes (and is >> it math.h or float.h? I can never remember). > > Other C programmers manage that without effort. I seem to recall that on his platform there's no man-pages. (Or that he, maybe, dislikes looking into the documentation? Sometime he gives that impression.) > >> (Funny how shadowing or overriding is usually perceived as bad, until >> you want to shadow something like 'sin' then it's a must-have!) Since when is shadowing (or "overriding" in its various forms) "perceived as bad"? - I've always seen it as a useful feature. And never heard anyone complaining about it. In decades I also don't recall that subtile (or obvious) errors had been reported because of that. (Are you, yet again, just making things up for the argument or have you any different observations from your personal coding practice?) Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-29 11:11 +0100 |
| Message-ID | <119g2sh$362up$1@dont-email.me> |
| In reply to | #402493 |
On 29/09/2026 08:03, Janis Papanagnou wrote: > On 2026-09-28 16:12, David Brown wrote: >> On 28/09/2026 15:38, bart wrote: >>> >>> - Always available without needing those annoying #includes (and is >>> it math.h or float.h? I can never remember). >> >> Other C programmers manage that without effort. > > I seem to recall that on his platform there's no man-pages. > (Or that he, maybe, dislikes looking into the documentation? > Sometime he gives that impression.) > >> >>> (Funny how shadowing or overriding is usually perceived as bad, until >>> you want to shadow something like 'sin' then it's a must-have!) > > Since when is shadowing (or "overriding" in its various forms) > "perceived as bad"? - I've always seen it as a useful feature. > And never heard anyone complaining about it. It can be useful, it can also introduce subtle bugs if done inadvertently. For example you are using a global name inside a function but also happen to define a local of that name, so the global one is hidden. Of you forget to define a local variable and accidentally overwrite, or just use, the global version. You can see the same thing in file systems: in older Windows shells, it will first look up a file ABC in the current directory. In newer ones and on Linux, that is not allowed, you have to do ./ABC or .\ABC to explicitly refer to the local version. Why? The older Windows approach is convenient, but some obviously think it is bad. > In decades I also > don't recall that subtile (or obvious) errors had been reported > because of that. (Are you, yet again, just making things up for > the argument or have you any different observations from your > personal coding practice?) You know, I'd been reading a series of posts by Lawrence D'Oliveiro, and assumed this was yet another. Until I got to the insults, which is uncharacteristic of him. And sure enough, I then noticed your name.
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web