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 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-27 10:20 +0200 |
| Subject | official library of tiny functions lacking in c |
| Message-ID | <119ajku$15pve$1@dont-email.me> |
you know there are a lacking tiny functions in c-lib (by c-lib i mean those standard c includes all know) AND if people use many maybe there is a need to standarize it byslef? if you need some could be ggood candidates for standarisation maybe write it here (i mean whole body of such function) we could and should discuss them
[toc] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-27 20:04 +0200 |
| Message-ID | <119blrr$1ka68$1@dont-email.me> |
| In reply to | #402418 |
fir pisze:
> you know there are a lacking tiny functions in c-lib
> (by c-lib i mean those standard c includes all know)
>
> AND if people use many maybe there is a need to standarize it
> byslef? if you need some could be ggood candidates for standarisation
> maybe write it here (i mean whole body of such function)
>
> we could and should discuss them
maybe something liek this?
int mini(int a,int b) { return a<b?a:b; }
int maxi(int a,int b) { return a>b?a:b; }
float minf(float a,float b) { return a<b?a:b; }
float maxf(float a,float b) { return a>b?a:b; }
int absi(int x) { return x<0?-x:x; }
float absf(float x) { return x<0?-x:x; }
float signf(float x) { return x>0?1:x<0?-1:0; }
int signi(int x) { return x>0?1:x<0?-1:0; }
//above controversial?
int clampi(int x,int a,int b) { return x<a?a:x>b?b:x; }
float clampf(float x,float a,float b) { return x<a?a:x>b?b:x; }
int betweeni(int x,int a,int b) { return x>=a && x<=b; }
float lerp(float a,float b,float t) { return a+(b-a)*t; }
float inv_lerp(float a,float b,float x) { return (x-a)/(b-a); }
float remap(float x,float a,float b,float c,float d) { return
c+(x-a)*(d-c)/(b-a); }
float rad(float x) { return x*PI/180.0f; }
float deg(float x) { return x*180.0f/PI; }
//thise above i dont quite use
float dist2_square(float x1,float y1,float x2,float y2) { float
x=x2-x1,y=y2-y1; return x*x+y*y; }
float dist2(float x1,float y1,float x2,float y2) { return
sqrtf(dist2(x1,y1,x2,y2));}
float len2_square(float x,float y) { return x*x+y*y; }
float len2(float x,float y) { return sqrtf(x*x+y*y);}
float dot2(float ax,float ay,float bx,float by){ return ax*bx+ay*by;}
float cross2(float ax,float ay,float bx,float by){ return ax*by-ay*bx;}
void norm2(float *x,float *y) { float d=sqrtf(*x**x+*y**y); if(d>0)
{ *x/=d; *y/=d; }}
float dist2_to_line(float px,float py,float ax,float ay,float bx,float
by){ return fabsf(cross2(bx-ax,by-ay,px-ax,py-ay))
/sqrtf(dist2_square(ax,ay,bx,by));}
// hare names may be controversial
the fact is imo though people should generallu decide and use one set of
such names imo
there is also more functions to put here
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-27 21:38 +0100 |
| Message-ID | <119busj$1no9s$1@dont-email.me> |
| In reply to | #402430 |
On 27/09/2026 19:04, fir wrote:
> fir pisze:
>> you know there are a lacking tiny functions in c-lib
>> (by c-lib i mean those standard c includes all know)
>>
>> AND if people use many maybe there is a need to standarize it
>> byslef? if you need some could be ggood candidates for standarisation
>> maybe write it here (i mean whole body of such function)
>>
>> we could and should discuss them
>
>
> maybe something liek this?
>
>
> int mini(int a,int b) { return a<b?a:b; }
> int maxi(int a,int b) { return a>b?a:b; }
> float minf(float a,float b) { return a<b?a:b; }
> float maxf(float a,float b) { return a>b?a:b; }
> int absi(int x) { return x<0?-x:x; }
> float absf(float x) { return x<0?-x:x; }
> float signf(float x) { return x>0?1:x<0?-1:0; }
> int signi(int x) { return x>0?1:x<0?-1:0; }
>
> //above controversial?
>
> int clampi(int x,int a,int b) { return x<a?a:x>b?b:x; }
> float clampf(float x,float a,float b) { return x<a?a:x>b?b:x; }
> int betweeni(int x,int a,int b) { return x>=a && x<=b; }
My systems language has these as built-ins. That means they are
overloaded for all numeric types.
Here, a, b, c are signed or unsigned 64-bit ints, and x,y,z can be 32-
or 64-bit floats:
min(a, b)
min(x, y)
max(x, y)
max(x, y)
abs(a)
abs(x)
sign(a)
sign(x)
clamp(a, b, c)
clamp(x, y, z)
a in b..c # or:
b <= a <= c
x <= y <= z
I wouldn't have a problem with these being part of standard C. But since
they will be functions (they will never be added to the core), you will
need versions for:
i32 u32 i64 u64 f32 f64
You might get away having only 64-bit versions, but on 32-targets that
would be inefficient.
Note that abs, labs, llabs, fabs, fabsf already exist in the standard
library. Notice that 'abs' has 3 integer versions, so it is possible it
can get even uglier than I said; you might need versions for:
int, long, long long, i32 i64
unsigned int, unsigned long, unsigned long long, u32 u64
to cover both 'classic' int types and ones from stdint.h.
(abs() will only need signed; but anything involving comparisons needs
both.)
>
> float lerp(float a,float b,float t) { return a+(b-a)*t; }
> float inv_lerp(float a,float b,float x) { return (x-a)/(b-a); }
> float remap(float x,float a,float b,float c,float d) { return c+(x-
> a)*(d-c)/(b-a); }
I've never heard of these.
> float rad(float x) { return x*PI/180.0f; }
> float deg(float x) { return x*180.0f/PI; }
>
> //thise above i dont quite use
>
> float dist2_square(float x1,float y1,float x2,float y2) { float x=x2-
> x1,y=y2-y1; return x*x+y*y; }
> float dist2(float x1,float y1,float x2,float y2) { return
> sqrtf(dist2(x1,y1,x2,y2));}
> float len2_square(float x,float y) { return x*x+y*y; }
> float len2(float x,float y) { return sqrtf(x*x+y*y);}
> float dot2(float ax,float ay,float bx,float by){ return ax*bx+ay*by;}
> float cross2(float ax,float ay,float bx,float by){ return ax*by-ay*bx;}
> void norm2(float *x,float *y) { float d=sqrtf(*x**x+*y**y); if(d>0)
> { *x/=d; *y/=d; }}
> float dist2_to_line(float px,float py,float ax,float ay,float bx,float
> by){ return fabsf(cross2(bx-ax,by-ay,px-ax,py-ay)) /
> sqrtf(dist2_square(ax,ay,bx,by));}
>
This will be application-specific and don't really belong in a language
like C. They can be in a third-party library.
(I used to have many of these in my first scripting language, but that
was part of my 3D graphics apps. It was a sort of DSL. My current
scripting language doesn't have them.)
But if such a library is created, it needs to have a lot more. Like
supporting 3D for a start. Beyond that it would again depend on
application.)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-27 23:16 +0200 |
| Message-ID | <119c14p$1ohra$1@dont-email.me> |
| In reply to | #402432 |
bart pisze:
> On 27/09/2026 19:04, fir wrote:
>> fir pisze:
>>> you know there are a lacking tiny functions in c-lib
>>> (by c-lib i mean those standard c includes all know)
>>>
>>> AND if people use many maybe there is a need to standarize it
>>> byslef? if you need some could be ggood candidates for standarisation
>>> maybe write it here (i mean whole body of such function)
>>>
>>> we could and should discuss them
>>
>>
>> maybe something liek this?
>>
>>
>> int mini(int a,int b) { return a<b?a:b; }
>> int maxi(int a,int b) { return a>b?a:b; }
>> float minf(float a,float b) { return a<b?a:b; }
>> float maxf(float a,float b) { return a>b?a:b; }
>> int absi(int x) { return x<0?-x:x; }
>> float absf(float x) { return x<0?-x:x; }
>> float signf(float x) { return x>0?1:x<0?-1:0; }
>> int signi(int x) { return x>0?1:x<0?-1:0; }
>>
>> //above controversial?
>>
>> int clampi(int x,int a,int b) { return x<a?a:x>b?b:x; }
>> float clampf(float x,float a,float b) { return x<a?a:x>b?b:x; }
>> int betweeni(int x,int a,int b) { return x>=a && x<=b; }
>
>
> My systems language has these as built-ins. That means they are
> overloaded for all numeric types.
>
> Here, a, b, c are signed or unsigned 64-bit ints, and x,y,z can be 32-
> or 64-bit floats:
>
> min(a, b)
> min(x, y)
> max(x, y)
> max(x, y)
> abs(a)
> abs(x)
> sign(a)
> sign(x)
> clamp(a, b, c)
> clamp(x, y, z)
> a in b..c # or:
> b <= a <= c
> x <= y <= z
>
> I wouldn't have a problem with these being part of standard C. But since
> they will be functions (they will never be added to the core), you will
> need versions for:
>
> i32 u32 i64 u64 f32 f64
>
> You might get away having only 64-bit versions, but on 32-targets that
> would be inefficient.
>
> Note that abs, labs, llabs, fabs, fabsf already exist in the standard
> library. Notice that 'abs' has 3 integer versions, so it is possible it
> can get even uglier than I said; you might need versions for:
>
> int, long, long long, i32 i64
> unsigned int, unsigned long, unsigned long long, u32 u64
>
> to cover both 'classic' int types and ones from stdint.h.
>
> (abs() will only need signed; but anything involving comparisons needs
> both.)
>
>
>>
>> float lerp(float a,float b,float t) { return a+(b-a)*t; }
>> float inv_lerp(float a,float b,float x) { return (x-a)/(b-a); }
>> float remap(float x,float a,float b,float c,float d) { return c+(x-
>> a)*(d-c)/(b-a); }
>
> I've never heard of these.
>
>> float rad(float x) { return x*PI/180.0f; }
>> float deg(float x) { return x*180.0f/PI; }
>>
>> //thise above i dont quite use
>>
>> float dist2_square(float x1,float y1,float x2,float y2) { float
>> x=x2- x1,y=y2-y1; return x*x+y*y; }
>> float dist2(float x1,float y1,float x2,float y2) { return
>> sqrtf(dist2(x1,y1,x2,y2));}
>> float len2_square(float x,float y) { return x*x+y*y; }
>> float len2(float x,float y) { return sqrtf(x*x+y*y);}
>> float dot2(float ax,float ay,float bx,float by){ return ax*bx+ay*by;}
>> float cross2(float ax,float ay,float bx,float by){ return
>> ax*by-ay*bx;}
>> void norm2(float *x,float *y) { float d=sqrtf(*x**x+*y**y);
>> if(d>0) { *x/=d; *y/=d; }}
>> float dist2_to_line(float px,float py,float ax,float ay,float bx,float
>> by){ return fabsf(cross2(bx-ax,by-ay,px-ax,py-ay)) /
>> sqrtf(dist2_square(ax,ay,bx,by));}
>>
> This will be application-specific and don't really belong in a language
> like C. They can be in a third-party library.
>
> (I used to have many of these in my first scripting language, but that
> was part of my 3D graphics apps. It was a sort of DSL. My current
> scripting language doesn't have them.)
>
> But if such a library is created, it needs to have a lot more. Like
> supporting 3D for a start. Beyond that it would again depend on
> application.)
>
>
i not quite understood why most of it cant be added (?)
literally i forgot there is fabs and fmin fmax - it is all mess that
some are some not.. imo it should be standarised just to not various
names be used for same thing of various thing for same name
(lask of this standarisatio is also another c annoyance imo)
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-28 00:53 +0100 |
| Message-ID | <119ca96$1sr2q$1@dont-email.me> |
| In reply to | #402433 |
On 27/09/2026 22:16, fir wrote:
> bart pisze:
>> On 27/09/2026 19:04, fir wrote:
>>> fir pisze:
>>>> you know there are a lacking tiny functions in c-lib
>>>> (by c-lib i mean those standard c includes all know)
>>>>
>>>> AND if people use many maybe there is a need to standarize it
>>>> byslef? if you need some could be ggood candidates for
>>>> standarisation maybe write it here (i mean whole body of such function)
>>>>
>>>> we could and should discuss them
>>>
>>>
>>> maybe something liek this?
>>>
>>>
>>> int mini(int a,int b) { return a<b?a:b; }
>>> int maxi(int a,int b) { return a>b?a:b; }
>>> float minf(float a,float b) { return a<b?a:b; }
>>> float maxf(float a,float b) { return a>b?a:b; }
>>> int absi(int x) { return x<0?-x:x; }
>>> float absf(float x) { return x<0?-x:x; }
>>> float signf(float x) { return x>0?1:x<0?-1:0; }
>>> int signi(int x) { return x>0?1:x<0?-1:0; }
>>>
>>> //above controversial?
>>>
>>> int clampi(int x,int a,int b) { return x<a?a:x>b?b:x; }
>>> float clampf(float x,float a,float b) { return x<a?a:x>b?b:x; }
>>> int betweeni(int x,int a,int b) { return x>=a && x<=b; }
>>
>>
>> My systems language has these as built-ins. That means they are
>> overloaded for all numeric types.
>>
>> Here, a, b, c are signed or unsigned 64-bit ints, and x,y,z can be 32-
>> or 64-bit floats:
>>
>> min(a, b)
>> min(x, y)
>> max(x, y)
>> max(x, y)
>> abs(a)
>> abs(x)
>> sign(a)
>> sign(x)
>> clamp(a, b, c)
>> clamp(x, y, z)
>> a in b..c # or:
>> b <= a <= c
>> x <= y <= z
>>
>> I wouldn't have a problem with these being part of standard C. But
>> since they will be functions (they will never be added to the core),
>> you will need versions for:
>>
>> i32 u32 i64 u64 f32 f64
>>
>> You might get away having only 64-bit versions, but on 32-targets that
>> would be inefficient.
>>
>> Note that abs, labs, llabs, fabs, fabsf already exist in the standard
>> library. Notice that 'abs' has 3 integer versions, so it is possible
>> it can get even uglier than I said; you might need versions for:
>>
>> int, long, long long, i32 i64
>> unsigned int, unsigned long, unsigned long long, u32 u64
>>
>> to cover both 'classic' int types and ones from stdint.h.
>>
>> (abs() will only need signed; but anything involving comparisons needs
>> both.)
>>
>>
>>>
>>> float lerp(float a,float b,float t) { return a+(b-a)*t; }
>>> float inv_lerp(float a,float b,float x) { return (x-a)/(b-a); }
>>> float remap(float x,float a,float b,float c,float d) { return c+(x-
>>> a)*(d-c)/(b-a); }
>>
>> I've never heard of these.
>>
>>> float rad(float x) { return x*PI/180.0f; }
>>> float deg(float x) { return x*180.0f/PI; }
>>>
>>> //thise above i dont quite use
>>>
>>> float dist2_square(float x1,float y1,float x2,float y2) { float
>>> x=x2- x1,y=y2-y1; return x*x+y*y; }
>>> float dist2(float x1,float y1,float x2,float y2) { return
>>> sqrtf(dist2(x1,y1,x2,y2));}
>>> float len2_square(float x,float y) { return x*x+y*y; }
>>> float len2(float x,float y) { return sqrtf(x*x+y*y);}
>>> float dot2(float ax,float ay,float bx,float by){ return ax*bx+ay*by;}
>>> float cross2(float ax,float ay,float bx,float by){ return ax*by-
>>> ay*bx;}
>>> void norm2(float *x,float *y) { float d=sqrtf(*x**x+*y**y); if(d>0)
>>> { *x/=d; *y/=d; }}
>>> float dist2_to_line(float px,float py,float ax,float ay,float
>>> bx,float by){ return fabsf(cross2(bx-ax,by-ay,px-ax,py-ay)) /
>>> sqrtf(dist2_square(ax,ay,bx,by));}
>>>
>> This will be application-specific and don't really belong in a
>> language like C. They can be in a third-party library.
>>
>> (I used to have many of these in my first scripting language, but that
>> was part of my 3D graphics apps. It was a sort of DSL. My current
>> scripting language doesn't have them.)
>>
>> But if such a library is created, it needs to have a lot more. Like
>> supporting 3D for a start. Beyond that it would again depend on
>> application.)
>>
>>
>
> i not quite understood why most of it cant be added (?)
Because it is application-specific as I said.
Ones like MIN(x, y) can be considered fundamental, but not the length of
a 2D vector which takes discrete X, Y float arguments.
It is just too specific, and the requirements in real applications will
be too diverse.
And also, where do you stop; why not a string library and a million
other things?
I'm sure there are plenty of such libraries about. They don't need to be
core language features at this level.
> literally i forgot there is fabs and fmin fmax - it is all mess that
> some are some not.. imo it should be standarised just to not various
> names be used for same thing of various thing for same name
I wasn't aware of fmin etc. But they can't use the same name as there
needs to be one function for each type.
Unless fminl/fmaxl, which take 'long double', also deal with float and
double, but it can mean expensive conversions.
> (lask of this standarisatio is also another c annoyance imo)
>
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-28 04:31 +0200 |
| Message-ID | <119cjiu$1v986$1@dont-email.me> |
| In reply to | #402437 |
bart pisze:
> On 27/09/2026 22:16, fir wrote:
>> bart pisze:
>>> On 27/09/2026 19:04, fir wrote:
>>>> fir pisze:
>>>>> you know there are a lacking tiny functions in c-lib
>>>>> (by c-lib i mean those standard c includes all know)
>>>>>
>>>>> AND if people use many maybe there is a need to standarize it
>>>>> byslef? if you need some could be ggood candidates for
>>>>> standarisation maybe write it here (i mean whole body of such
>>>>> function)
>>>>>
>>>>> we could and should discuss them
>>>>
>>>>
>>>> maybe something liek this?
>>>>
>>>>
>>>> int mini(int a,int b) { return a<b?a:b; }
>>>> int maxi(int a,int b) { return a>b?a:b; }
>>>> float minf(float a,float b) { return a<b?a:b; }
>>>> float maxf(float a,float b) { return a>b?a:b; }
>>>> int absi(int x) { return x<0?-x:x; }
>>>> float absf(float x) { return x<0?-x:x; }
>>>> float signf(float x) { return x>0?1:x<0?-1:0; }
>>>> int signi(int x) { return x>0?1:x<0?-1:0; }
>>>>
>>>> //above controversial?
>>>>
>>>> int clampi(int x,int a,int b) { return x<a?a:x>b?b:x; }
>>>> float clampf(float x,float a,float b) { return x<a?a:x>b?b:x; }
>>>> int betweeni(int x,int a,int b) { return x>=a && x<=b; }
>>>
>>>
>>> My systems language has these as built-ins. That means they are
>>> overloaded for all numeric types.
>>>
>>> Here, a, b, c are signed or unsigned 64-bit ints, and x,y,z can be
>>> 32- or 64-bit floats:
>>>
>>> min(a, b)
>>> min(x, y)
>>> max(x, y)
>>> max(x, y)
>>> abs(a)
>>> abs(x)
>>> sign(a)
>>> sign(x)
>>> clamp(a, b, c)
>>> clamp(x, y, z)
>>> a in b..c # or:
>>> b <= a <= c
>>> x <= y <= z
>>>
>>> I wouldn't have a problem with these being part of standard C. But
>>> since they will be functions (they will never be added to the core),
>>> you will need versions for:
>>>
>>> i32 u32 i64 u64 f32 f64
>>>
>>> You might get away having only 64-bit versions, but on 32-targets
>>> that would be inefficient.
>>>
>>> Note that abs, labs, llabs, fabs, fabsf already exist in the standard
>>> library. Notice that 'abs' has 3 integer versions, so it is possible
>>> it can get even uglier than I said; you might need versions for:
>>>
>>> int, long, long long, i32 i64
>>> unsigned int, unsigned long, unsigned long long, u32 u64
>>>
>>> to cover both 'classic' int types and ones from stdint.h.
>>>
>>> (abs() will only need signed; but anything involving comparisons
>>> needs both.)
>>>
>>>
>>>>
>>>> float lerp(float a,float b,float t) { return a+(b-a)*t; }
>>>> float inv_lerp(float a,float b,float x) { return (x-a)/(b-a); }
>>>> float remap(float x,float a,float b,float c,float d) { return c+(x-
>>>> a)*(d-c)/(b-a); }
>>>
>>> I've never heard of these.
>>>
>>>> float rad(float x) { return x*PI/180.0f; }
>>>> float deg(float x) { return x*180.0f/PI; }
>>>>
>>>> //thise above i dont quite use
>>>>
>>>> float dist2_square(float x1,float y1,float x2,float y2) { float
>>>> x=x2- x1,y=y2-y1; return x*x+y*y; }
>>>> float dist2(float x1,float y1,float x2,float y2) { return
>>>> sqrtf(dist2(x1,y1,x2,y2));}
>>>> float len2_square(float x,float y) { return x*x+y*y; }
>>>> float len2(float x,float y) { return sqrtf(x*x+y*y);}
>>>> float dot2(float ax,float ay,float bx,float by){ return ax*bx+ay*by;}
>>>> float cross2(float ax,float ay,float bx,float by){ return ax*by-
>>>> ay*bx;}
>>>> void norm2(float *x,float *y) { float d=sqrtf(*x**x+*y**y);
>>>> if(d>0) { *x/=d; *y/=d; }}
>>>> float dist2_to_line(float px,float py,float ax,float ay,float
>>>> bx,float by){ return fabsf(cross2(bx-ax,by-ay,px-ax,py-ay)) /
>>>> sqrtf(dist2_square(ax,ay,bx,by));}
>>>>
>>> This will be application-specific and don't really belong in a
>>> language like C. They can be in a third-party library.
>>>
>>> (I used to have many of these in my first scripting language, but
>>> that was part of my 3D graphics apps. It was a sort of DSL. My
>>> current scripting language doesn't have them.)
>>>
>>> But if such a library is created, it needs to have a lot more. Like
>>> supporting 3D for a start. Beyond that it would again depend on
>>> application.)
>>>
>>>
>>
>> i not quite understood why most of it cant be added (?)
>
> Because it is application-specific as I said.
>
> Ones like MIN(x, y) can be considered fundamental, but not the length of
> a 2D vector which takes discrete X, Y float arguments.
>
> It is just too specific, and the requirements in real applications will
> be too diverse.
>
how specyfic? i dont understand this
where to stop? imo the ones that are commo usage should be standarised
it doesnt even mean they need to be implemented in library but there
should be common naming (and the same work at least in the same
ciricumstances)
> And also, where do you stop; why not a string library and a million
> other things?
>
string library is for ery rare use imo, except printing texts and
numbers...most problems are with that simple math related functions..
alos maybe color realated and simple 2d graphics could be standarised
> I'm sure there are plenty of such libraries about. They don't need to be
> core language features at this level.
>
>
>> literally i forgot there is fabs and fmin fmax - it is all mess that
>> some are some not.. imo it should be standarised just to not various
>> names be used for same thing of various thing for same name
>
> I wasn't aware of fmin etc. But they can't use the same name as there
> needs to be one function for each type.
>
> Unless fminl/fmaxl, which take 'long double', also deal with float and
> double, but it can mean expensive conversions.
>
>> (lask of this standarisatio is also another c annoyance imo)
>>
>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-28 10:25 +0200 |
| Message-ID | <119d88u$23bo0$2@dont-email.me> |
| In reply to | #402437 |
On 28/09/2026 01:53, bart wrote: > > Ones like MIN(x, y) can be considered fundamental, but not the length of > a 2D vector which takes discrete X, Y float arguments. > The C standard library has a several floating point "minimum" and "maximum" functions, with different treatment of signed zeros and NaNs. In floating point, "a < b ? a : b" is often not sufficient, so these functions are needed for users that care about the precise details. For integers, "a < b ? a : b" works fine. There is no "min" in the C standard library - I suppose the combination of it being easy to write in user code, and the common usage of "min" as an identifier meant that it could never be added to the C standard library without a somewhat artificial name like "iminimum". Maybe one day C will get namespaces (there are proposals in the works) and then it will be fine to add stdc::min. It also has a "hypot" function that returns, approximately, sqrt(x*x + y*y). But again, the actual implementation is not as simple so that it correctly handles rounding, avoids unnecessary overflow or underflow, and can conform to IEEE standards and/or take advantage of hardware acceleration. > It is just too specific, and the requirements in real applications will > be too diverse. > > And also, where do you stop; why not a string library and a million > other things? > C has a string library. It's not very high level, compared to the support found in many other languages. > I'm sure there are plenty of such libraries about. They don't need to be > core language features at this level. > Agreed. Things like "min", "abs", trig functions, etc., should normally not be core language features in any language unless the language is dedicated to numerical calculations. Lots can be part of a standard library, however. There's no rule where the line should be drawn between standard libraries and additional libraries - that depends on the language. Since we are in c.l.c., the C standards show where the line is drawn in C. > >> literally i forgot there is fabs and fmin fmax - it is all mess that >> some are some not.. imo it should be standarised just to not various >> names be used for same thing of various thing for same name > > I wasn't aware of fmin etc. But they can't use the same name as there > needs to be one function for each type. C has had type-generic maths macros since C99 - if you use #include <tgmath.h> and write "fabs(x)", then the appropriate real or complex floating point fabs, fabsf, fabsl, cabs, cabsf, cabsl function will be called. Since C11, you can write such macros yourself. New functions added to the C standard library, such as the <stdbit.h> functions in C23, come in both fixed-type function and type-generic macro form. > > Unless fminl/fmaxl, which take 'long double', also deal with float and > double, but it can mean expensive conversions. > Many of the functions Fir wanted are already in the C standard library. Many of the features you wanted are already in the language and library. You would both benefit from looking at the standards or a good reference website before bemoaning missing features and functions.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-28 11:45 +0100 |
| Message-ID | <119dgg0$28if0$2@dont-email.me> |
| In reply to | #402444 |
On 28/09/2026 09:25, David Brown wrote:
> On 28/09/2026 01:53, bart wrote:
>>
>> Ones like MIN(x, y) can be considered fundamental, but not the length
>> of a 2D vector which takes discrete X, Y float arguments.
> It also has a "hypot" function that returns, approximately, sqrt(x*x +
> y*y).
fir's len2 function was one of a suite of functions familiar to me from
3D graphics.
If C's obscure 'hypot' function does that job, then great. My point was
that that set of functions was too specific for a general purpose
language at this level.
But then, MSVCRT.DLL exports over 1300 functions, about the same number
as SDL3!
> C has a string library.
OK. I meant a higher level one!
> It's not very high level, compared to the
> support found in many other languages.
>
>> I'm sure there are plenty of such libraries about. They don't need to
>> be core language features at this level.
>>
>
> Agreed. Things like "min", "abs", trig functions, etc., should normally
> not be core language features in any language unless the language is
> dedicated to numerical calculations.
Many of these are available as machine instructions, so they are
considered fundamental there. Some are available on my Casio.
You think a cheap calculator should have sin() but not a programming
language?
Having them via user-functions in standard library is just about
acceptable, but it's not ideal - see below for the machinations that are
needed when you need to overload.
One of fir's points, with which I agree, is that how C does it is a mess.
> Lots can be part of a standard
> library, however. There's no rule where the line should be drawn
> between standard libraries and additional libraries - that depends on
> the language. Since we are in c.l.c., the C standards show where the
> line is drawn in C.
So why was hypot() ever added? Somebody thought it was a good idea at
one time to add a such a one-line function?
But then a one-line function is also trivial to write in user-code,
compared to your own cos() for example.
>> I wasn't aware of fmin etc. But they can't use the same name as there
>> needs to be one function for each type.
>
> C has had type-generic maths macros since C99 - if you use #include
> <tgmath.h> and write "fabs(x)", then the appropriate real or complex
> floating point fabs, fabsf, fabsl, cabs, cabsf, cabsl function will be
> called.
OK. I don't have tgmath.h in bcc, and tcc doesn't have it either. But
I've looked at how it works in those that do. If I try this program:
ly = sin(lx); // long double
dy = sin(dx); // double
fy = sin(fx); // float
then lccwin32 preprocesses it to:
ly = __sin(lx);
dy = __sin(dx);
fy = __sin(fx);
Clang does:
ly = __tg_sin((__typeof__(__tg_promote((lx))))(lx));
dy = __tg_sin((__typeof__(__tg_promote((dx))))(dx));
fy = __tg_sin((__typeof__(__tg_promote((fx))))(fx));
And Gcc does:
__builtin_tgmath (sinf, sin, sinl, csinf, csin, csinl, (lx))
__builtin_tgmath (sinf, sin, sinl, csinf, csin, csinl, (dx))
__builtin_tgmath (sinf, sin, sinl, csinf, csin, csinl, (fx))
So it's not clear how the mechanism works. Compiler magic?
With lccwin32 at least, it seems it implements an actual overloaded
sin() in the form of __sin(), to distinguish from the underlying sin()
in C which uses 'double'.
But in practice, tgmath is used so rarely in open source code I've seen,
that I've forgotten it existed.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-28 13:56 +0200 |
| Message-ID | <119dkku$27s5h$1@dont-email.me> |
| In reply to | #402448 |
On 28/09/2026 12:45, bart wrote: > On 28/09/2026 09:25, David Brown wrote: >> On 28/09/2026 01:53, bart wrote: >>> >>> Ones like MIN(x, y) can be considered fundamental, but not the length >>> of a 2D vector which takes discrete X, Y float arguments. > >> It also has a "hypot" function that returns, approximately, sqrt(x*x + >> y*y). > > fir's len2 function was one of a suite of functions familiar to me from > 3D graphics. > > If C's obscure 'hypot' function does that job, then great. My point was > that that set of functions was too specific for a general purpose > language at this level. > "hypot" - short for "hypotenuse" but easier to spell - is not obscure. It is a common name and part of the IEEE 754 standard. It makes a lot of sense for a language that is often used with code that requires conformance to that standard, to have support for the standard's required and recommended functions in its standard library. As Lawrence showed, proper implementations of such functions is not just a matter of copying the pure mathematical formula. But Fir could well have included other functions that are not likely to make sense in a standard library for a general-purpose programming language - and to have omitted many that should be there. > But then, MSVCRT.DLL exports over 1300 functions, about the same number > as SDL3! > > > >> C has a string library. > > OK. I meant a higher level one! Standard C does not have a higher level string library than the string library C has in its standard library. No arguments there :-) More seriously - yes, C's string support is quite low-level. > >> It's not very high level, compared to the support found in many other >> languages. >> >>> I'm sure there are plenty of such libraries about. They don't need to >>> be core language features at this level. >>> >> >> Agreed. Things like "min", "abs", trig functions, etc., should >> normally not be core language features in any language unless the >> language is dedicated to numerical calculations. > > Many of these are available as machine instructions, so they are > considered fundamental there. Some are available on my Casio. The majority of programming languages are defined in terms of an abstract machine - they are higher level than the processors that run them. So a function "sqrt" might be a single instruction on one target and a function call on another. It might depend on compiler flags too - some targets have such instruction for "normal" floating point numbers but need a library function to deal with denormals, NaNs, etc. It is up to the compiler and library implementation to handle all this correctly and efficiently. But the choice of supported instructions on a given processor should in no way be seen as a guide to what functions or operations are "fundamental", or what should be part of the core language (as keywords), or what should be part of a language standard library. > > You think a cheap calculator should have sin() but not a programming > language? Of course. It is common to have "sin" as a standard library function in languages, but not as part of the core language itself. It is pointless having such functions in core language, taking up limited identifier space with a keyword that the solid majority of programs will never need. Put it in the library. > > Having them via user-functions in standard library is just about > acceptable, but it's not ideal - see below for the machinations that are > needed when you need to overload. I've had my own "sin" function in C programs. I do not remember that any complications were involved. > > One of fir's points, with which I agree, is that how C does it is a mess. > >> Lots can be part of a standard library, however. There's no rule >> where the line should be drawn between standard libraries and >> additional libraries - that depends on the language. Since we are in >> c.l.c., the C standards show where the line is drawn in C. > > So why was hypot() ever added? Somebody thought it was a good idea at > one time to add a such a one-line function? It is not a one-line function. Did you fail to read that bit of my post? My guess is that it was added to C (I have no idea when) because it is a recommended function for IEEE 754 floating point. It was probably added to the IEEE 754 standard because people thought it would be useful, and having it as a function defined as it is makes it more useful over a wider range, and with greater repeatability across platforms. > > But then a one-line function is also trivial to write in user-code, > compared to your own cos() for example. > >>> I wasn't aware of fmin etc. But they can't use the same name as there >>> needs to be one function for each type. >> >> C has had type-generic maths macros since C99 - if you use #include >> <tgmath.h> and write "fabs(x)", then the appropriate real or complex >> floating point fabs, fabsf, fabsl, cabs, cabsf, cabsl function will be >> called. > > OK. I don't have tgmath.h in bcc, and tcc doesn't have it either. But > I've looked at how it works in those that do. If I try this program: > > ly = sin(lx); // long double > dy = sin(dx); // double > fy = sin(fx); // float > > then lccwin32 preprocesses it to: > > ly = __sin(lx); > dy = __sin(dx); > fy = __sin(fx); > > Clang does: > > ly = __tg_sin((__typeof__(__tg_promote((lx))))(lx)); > dy = __tg_sin((__typeof__(__tg_promote((dx))))(dx)); > fy = __tg_sin((__typeof__(__tg_promote((fx))))(fx)); > > And Gcc does: > > __builtin_tgmath (sinf, sin, sinl, csinf, csin, csinl, (lx)) > __builtin_tgmath (sinf, sin, sinl, csinf, csin, csinl, (dx)) > __builtin_tgmath (sinf, sin, sinl, csinf, csin, csinl, (fx)) > > So it's not clear how the mechanism works. Compiler magic? The C standard says what is to be done, not how it is to be done. Until C11 there was no standard way to implement this kind of thing - so it was usually done with compiler extensions. The only requirement is that they are macros (letting people use #undef or #ifdef on them if they want). So a simple implementation would be : #define sin(x) sin(x) If "long double" is the same size and resolution as "double" on the platform, and it does not support complex numbers, that will work fine - albeit without any kind of speed gains for lower resolution. A C11 implementation might be : #define sin(x) \ _Generic((x), \ float : sinf, \ double : sin, \ long double : sinl, \ float complex : csinf, \ double complex : csin, \ long double complex : csinl \ )(x) The C99 <tgmath.h> header predates _Generic, so compiler extensions were used by more advanced compilers and libraries. I doubt if there is anything to be gained by changing existing libraries now, but a new implementation would probably use _Generic rather than inventing a compiler extension. > > With lccwin32 at least, it seems it implements an actual overloaded > sin() in the form of __sin(), to distinguish from the underlying sin() > in C which uses 'double'. With only the information you posted to go on, it looks more like a direct use of a single "__sin" function, but it is entirely possible that the compiler has some extensions that are not visible here. I don't know the details of lccwin32 - it is not a toolchain of interest to me. > > But in practice, tgmath is used so rarely in open source code I've seen, > that I've forgotten it existed. > Whether it is used or not in the code you have looked at is immaterial to its existence in the C standard, and how it provides a convenient and flexible form of "overloading" for such functions. It is your choice to implement it, or not, and to use it, or not - but it is silly to complain about multiple function names when the mechanism to avoid it is there and ready to use.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-28 14:38 +0100 |
| Message-ID | <119dqk0$2cj9m$1@dont-email.me> |
| In reply to | #402450 |
On 28/09/2026 12:56, David Brown wrote: > On 28/09/2026 12:45, bart wrote: >> On 28/09/2026 09:25, David Brown wrote: >>> On 28/09/2026 01:53, bart wrote: >>>> >>>> Ones like MIN(x, y) can be considered fundamental, but not the >>>> length of a 2D vector which takes discrete X, Y float arguments. >> >>> It also has a "hypot" function that returns, approximately, sqrt(x*x >>> + y*y). >> >> fir's len2 function was one of a suite of functions familiar to me >> from 3D graphics. >> >> If C's obscure 'hypot' function does that job, then great. My point >> was that that set of functions was too specific for a general purpose >> language at this level. >> > > "hypot" - short for "hypotenuse" but easier to spell - is not obscure. > It is a common name and part of the IEEE 754 standard. It makes a lot > of sense for a language that is often used with code that requires > conformance to that standard, to have support for the standard's > required and recommended functions in its standard library. As Lawrence > showed, proper implementations of such functions is not just a matter of > copying the pure mathematical formula. He showed a way to avoid overflowing (with inputs above 10**19) if you can't be bothered to use a more appropriate type. However everywhere there is x*x in a program, or even x*y and x/y, there can be floating point overflow for certain values of x and y. You just have to be aware of what you are doing and know the limitations. > It is common to have "sin" as a standard library function in languages, > but not as part of the core language itself. It is pointless having > such functions in core language, taking up limited identifier space with > a keyword that the solid majority of programs will never need. Put it > in the library. Disagree. Make it part of the core language and you get benefits: - Easier for a simple compiler to optimise for example - Easier to overload across numeric types - Always available without needing those annoying #includes (and is it math.h or float.h? I can never remember). - Not possible to override (in Python you can do math.sin = 342, in C it possible to either shadow or write a private 'sin') Downsides might be in not being able to create a function reference; it all depends on how the language works. > taking up limited identifier space with See my last point - you don't /want/ user programs to use 'sin'! As for limited identifier space, AFAICS that is essentially unlimited. > I've had my own "sin" function in C programs. I do not remember that > any complications were involved. The usual approach for a custom version is to use a slightly different name. I dislike overriding or shadowing built-ins. (Funny how shadowing or overriding is usually perceived as bad, until you want to shadow something like 'sin' then it's a must-have!) >> >> One of fir's points, with which I agree, is that how C does it is a mess. >> >>> Lots can be part of a standard library, however. There's no rule >>> where the line should be drawn between standard libraries and >>> additional libraries - that depends on the language. Since we are in >>> c.l.c., the C standards show where the line is drawn in C. >> >> So why was hypot() ever added? Somebody thought it was a good idea at >> one time to add a such a one-line function? > > It is not a one-line function. Did you fail to read that bit of my > post? I did then I misremembered it as being from LD'O's post which I replied to. I just tried a test program that compared the official hypot() to a one-line version using random floats, and I have yet to detect a difference across 100 million tests. (Float ranges were 0.0 to 10**150 approx using f64 type. However this would be MSVCRT's hypot() so maybe it is also simple.) >> With lccwin32 at least, it seems it implements an actual overloaded >> sin() in the form of __sin(), to distinguish from the underlying sin() >> in C which uses 'double'. > > With only the information you posted to go on, it looks more like a > direct use of a single "__sin" function, but it is entirely possible > that the compiler has some extensions that are not visible here. I > don't know the details of lccwin32 - it is not a toolchain of interest > to me. It seems that __sin is nothing special: it is implemented using x86's 'fsin' hardware instruction. That means f32 types have to be widened and the result then narrowed as needed.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-28 16:12 +0200 |
| Message-ID | <119dsk4$27s5h$3@dont-email.me> |
| In reply to | #402458 |
On 28/09/2026 15:38, bart wrote: > On 28/09/2026 12:56, David Brown wrote: >> On 28/09/2026 12:45, bart wrote: >>> On 28/09/2026 09:25, David Brown wrote: >>>> On 28/09/2026 01:53, bart wrote: >>>>> >>>>> Ones like MIN(x, y) can be considered fundamental, but not the >>>>> length of a 2D vector which takes discrete X, Y float arguments. >>> >>>> It also has a "hypot" function that returns, approximately, sqrt(x*x >>>> + y*y). >>> >>> fir's len2 function was one of a suite of functions familiar to me >>> from 3D graphics. >>> >>> If C's obscure 'hypot' function does that job, then great. My point >>> was that that set of functions was too specific for a general purpose >>> language at this level. >>> >> >> "hypot" - short for "hypotenuse" but easier to spell - is not obscure. >> It is a common name and part of the IEEE 754 standard. It makes a lot >> of sense for a language that is often used with code that requires >> conformance to that standard, to have support for the standard's >> required and recommended functions in its standard library. As >> Lawrence showed, proper implementations of such functions is not just >> a matter of copying the pure mathematical formula. > > He showed a way to avoid overflowing (with inputs above 10**19) if you > can't be bothered to use a more appropriate type. He showed that the way to avoid overflowing is to use the standard library "hypot" function instead of an amateur version. It applies to all floating point types. And there may be other issues that it gets right, such as rounding or treatment of NaNs which are relevant. People who care about the quality of their floating point work care about this sort of thing - it means they don't lose as much accuracy when doing lots of calculations. If you don't care, that's okay (I have never been particularly bothered for my own code), but it is important to many other programmers. > > However everywhere there is x*x in a program, or even x*y and x/y, there > can be floating point overflow for certain values of x and y. > > You just have to be aware of what you are doing and know the limitations. > It is more complicated than that for floating point. Numerical stability, portability and repeatability is not an easy matter. For simpler uses, it is often just a matter of making sure you have types that fit for the ranges and accuracy you need at the time. But for standard library functions, you have to do a lot better, because not all uses are simple. >> It is common to have "sin" as a standard library function in >> languages, but not as part of the core language itself. It is >> pointless having such functions in core language, taking up limited >> identifier space with a keyword that the solid majority of programs >> will never need. Put it in the library. > > Disagree. Make it part of the core language and you get benefits: > > - Easier for a simple compiler to optimise for example Serious C compilers don't have a problem there. The effort involved for compiler writers is considered a very minor priority in defining languages and libraries. > > - Easier to overload across numeric types C manages it without trouble. > > - 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. > > - Not possible to override (in Python you can do math.sin = 342, > in C it possible to either shadow or write a private 'sin') > This is a good thing. C programmers can (though most don't bother) choose different standard libraries for different balances of features like size and speed. Individual library functions can be replaced. > Downsides might be in not being able to create a function reference; it > all depends on how the language works. > > > taking up limited identifier space with > > See my last point - you don't /want/ user programs to use 'sin'! Other people /do/ want to be able to make their own "sin" function. And there are /lots/ of functions in the C standard libraries. There are plenty of real-world programs where program identifiers match some standard library identifiers - and more so, as new functions are added. Your technique might be acceptable for a small, limited language that is never going to change - but not for a more serious language where the language and library needs to be able to grow while minimising conflicts with existing code. > > As for limited identifier space, AFAICS that is essentially unlimited. > Don't be silly. >> I've had my own "sin" function in C programs. I do not remember that >> any complications were involved. > > The usual approach for a custom version is to use a slightly different > name. I dislike overriding or shadowing built-ins. > Your "usual approach" and what you like or dislike is no indication of what other people may do. There are reasons why I would sometimes pick a name that is different from the standard library name, and reasons while I would sometimes pick the same name. > (Funny how shadowing or overriding is usually perceived as bad, until > you want to shadow something like 'sin' then it's a must-have!) > It is not a "must-have", it is a convenience. Of course it's possible to work in a language where "sin" is a built-in function that is fixed in the language. But it usually has no benefit, and just disadvantages compared to using a standard library. That's why few languages since BASIC have gone your route. Anyway, this is C - "sin" is never going to be part of the language, it is always going to be in the standard library. And people can use it for any floating point type, with as much efficiency as the library can muster. >>> >>> One of fir's points, with which I agree, is that how C does it is a >>> mess. >>> >>>> Lots can be part of a standard library, however. There's no rule >>>> where the line should be drawn between standard libraries and >>>> additional libraries - that depends on the language. Since we are >>>> in c.l.c., the C standards show where the line is drawn in C. >>> >>> So why was hypot() ever added? Somebody thought it was a good idea at >>> one time to add a such a one-line function? >> >> It is not a one-line function. Did you fail to read that bit of my post? > > I did then I misremembered it as being from LD'O's post which I replied to. > OK.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-28 16:52 +0100 |
| Message-ID | <119e2f5$2fr80$1@dont-email.me> |
| In reply to | #402459 |
On 28/09/2026 15:12, David Brown wrote: > On 28/09/2026 15:38, bart wrote: >> As for limited identifier space, AFAICS that is essentially unlimited. >> > > Don't be silly. But you brought it up! >>> I've had my own "sin" function in C programs. I do not remember that >>> any complications were involved. >> >> The usual approach for a custom version is to use a slightly different >> name. I dislike overriding or shadowing built-ins. >> > > Your "usual approach" and what you like or dislike is no indication of > what other people may do. There are reasons why I would sometimes pick > a name that is different from the standard library name, and reasons > while I would sometimes pick the same name. > >> (Funny how shadowing or overriding is usually perceived as bad, until >> you want to shadow something like 'sin' then it's a must-have!) >> > > It is not a "must-have", it is a convenience. Of course it's possible > to work in a language where "sin" is a built-in function that is fixed > in the language. But it usually has no benefit, and just disadvantages > compared to using a standard library. That's why few languages since > BASIC have gone your route. Yes, I know, most languages prefer to have things in libraries rather than in the core. Some even want to have basics such as statements in libraries (Clisp was mentioned but this stuff is popular in esolangs). But one example where built-in is better is with Print. Otherwise this presents challenges to do in user-code: * Variable-length set of arguments * Mixed argument types * Optional per-item information * Optional per-print information (eg. destination) * Less than ideal syntax In C, this meant several things: * Needing to add stdio.h each time * Having to introduce variadic functions (possibly just for this reason) * Less type safety * Using format codes to import type information Other languages have their own problems in fitting those requirements to standard functions
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-28 18:49 +0200 |
| Message-ID | <119e5ri$2h3ep$1@dont-email.me> |
| In reply to | #402466 |
On 28/09/2026 17:52, bart wrote: > On 28/09/2026 15:12, David Brown wrote: >> On 28/09/2026 15:38, bart wrote: > >>> As for limited identifier space, AFAICS that is essentially unlimited. >>> >> >> Don't be silly. > > But you brought it up! The global name space for "easy" names like "sin" or "min" is limited. Conflicts are likely if the language claims them for itself. That's obvious. The global name space for names of any kind is not limited. That's equally obvious. >>>> I've had my own "sin" function in C programs. I do not remember >>>> that any complications were involved. >>> >>> The usual approach for a custom version is to use a slightly >>> different name. I dislike overriding or shadowing built-ins. >>> >> >> Your "usual approach" and what you like or dislike is no indication of >> what other people may do. There are reasons why I would sometimes >> pick a name that is different from the standard library name, and >> reasons while I would sometimes pick the same name. >> >>> (Funny how shadowing or overriding is usually perceived as bad, until >>> you want to shadow something like 'sin' then it's a must-have!) >>> >> >> It is not a "must-have", it is a convenience. Of course it's possible >> to work in a language where "sin" is a built-in function that is fixed >> in the language. But it usually has no benefit, and just >> disadvantages compared to using a standard library. That's why few >> languages since BASIC have gone your route. > > Yes, I know, most languages prefer to have things in libraries rather > than in the core. So perhaps it's a good idea? > > Some even want to have basics such as statements in libraries (Clisp was > mentioned but this stuff is popular in esolangs). I am not sure what you mean by "having statements in libraries". In some languages, it is possible to define control structures in the language itself. It is natural to use the language - and therefore a standard library - for things that can be written in the language, as long as there are no efficiency issues. > > But one example where built-in is better is with Print. Otherwise this > presents challenges to do in user-code: No, "print" is not "better" as a built-in. That's pure bias on your part. Lots of programs have little or no use for "print", or they need something significantly different (showing messages in a dialog box, printing them to logs or serial ports, etc.). Making it special is not a good idea. > > * Variable-length set of arguments > > * Mixed argument types > > * Optional per-item information > > * Optional per-print information (eg. destination) > > * Less than ideal syntax > These can all be handled in a language-definable function, and do not need special handling. Different systems have their pros and cons, of course. > > In C, this meant several things: > > * Needing to add stdio.h each time > > * Having to introduce variadic functions (possibly just for this reason) > > * Less type safety > > * Using format codes to import type information > > Other languages have their own problems in fitting those requirements to > standard functions > If you want something complex, it is complex. All you do by having it as a special built-in feature of the language is limited its usefulness, and mean that people have to re-invent it anyway. I understand your style of thinking - it's the way people thought about programming language forty-odd years ago.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-28 20:26 +0100 |
| Message-ID | <119ef1m$2l27o$1@dont-email.me> |
| In reply to | #402467 |
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?
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.
>> But one example where built-in is better is with Print. Otherwise this
>> presents challenges to do in user-code:
>
> No, "print" is not "better" as a built-in. That's pure bias on your part.
The examples below suggest otherwise.
> Lots of programs have little or no use for "print", or they need
> something significantly different (showing messages in a dialog box,
> printing them to logs or serial ports, etc.
So they /are/ using Print, which still has a variety of uses:
* To send output to such log files
* To format data
* To write such data to strings, perhaps might then be displayed in a
GUI
* To turn binary data into text or stringify in general
* To write line-based text files in general
* To print to actual printers (eg. narrow receipt printers which i have
used extensively)
Such things are still very much needed.
> These can all be handled in a language-definable function, and do not
> need special handling.
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.
Here is a task that prints an integer 'i', and its square root, followed
by a newline, to the console, in several languages:
Zig: std.debug.print("{} {}\n",.{i,@sqrt(@as(f64,@floatFromInt(i)))});
C: printf("%d %f\n", i, sqrt(i));
C++: std::cout << i << " " << sqrt(i) << std::endl;
M: println i, sqrt i
BASIC: 10 PRINT I, SQR(I)
The first three all need prerequisites to make it work. The last two
need nothing, not even variadic functions.
Maybe it's a coincidence that both have Print and Sqrt as built-ins.
>> Other languages have their own problems in fitting those requirements
>> to standard functions
>>
> If you want something complex, it is complex.
>
> All you do by having it as a special built-in feature of the language is
> limited its usefulness, and mean that people have to re-invent it anyway.
>
> I understand your style of thinking - it's the way people thought about
> programming language forty-odd years ago.
More like 50 years. But yes, when things were simple: see my examples
above. So what the hell happened?
Here's another example that current languages suck at: wait for a line
of input and read 3 numbers from it:
readln a, b, c
I can't show you the C - I'd have to go and look it up! And I'd have to
ensure the behaviour was line-based rather than stream-based.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-29 09:45 +0200 |
| Message-ID | <119fqat$31nv1$1@dont-email.me> |
| In reply to | #402471 |
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. When Alfred Wegener proposed his theory of plate tectonics,
all the other geologists laughed at him and said he was being
ridiculous. It turned out he was right.
Most of the time, when one person thinks differently from everyone else,
that one person is wrong. They have misunderstood the situation, or are
thinking only of a very limited case.
And here you are not coming with new ideas. You are coming with ideas
that were used in the early days of programming language design - things
other language designers knew about and grew out of, things that they
had to use when computers were small and space was tight but that they
could put behind them once they had the resources to make better languages.
Keeping everything in a core language still has its place, in small
teaching languages, macro languages, and limited domain-specific languages.
You have a small, limited domain-specific language - the domain is one
language designer, one toolchain developer, one toolchain user. That is
very niche, and gives the very special situation that the cost of adding
a function to the application code, standard library, or language and
toolchain is all the same. If that works for you, that's fine - enjoy
yourself. But you need to realise that it is not applicable outside
such a very specific situation.
>
> 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.
It can seem odd because you have misunderstood - you are wrong on all
counts here.
First, keeping a core language small has many purposes - lower cognitive
load to learn it may or may not be one of them. Many languages have
complex cores with lots of features, but still have as much as possible
pushed over to standard libraries.
Secondly, people do not need to learn everything in the language's
standard libraries. I do not know all the details of more than a small
part of the functions and macros in the C standard library. And that
fraction is tiny for languages with bigger libraries, like C++ or Python.
Thirdly, modern languages do not put all the identifiers in the same
namespace. C is older and does not have namespaces, but even there you
have some control by choosing which headers to include or not.
>
>
>>> But one example where built-in is better is with Print. Otherwise
>>> this presents challenges to do in user-code:
>>
>> No, "print" is not "better" as a built-in. That's pure bias on your
>> part.
> The examples below suggest otherwise.
>
No. You are extrapolating your own needs and preferences and assuming
that they apply everywhere.
>
>
>> Lots of programs have little or no use for "print", or they need
>> something significantly different (showing messages in a dialog box,
>> printing them to logs or serial ports, etc.
>
> So they /are/ using Print, which still has a variety of uses:
>
No, they are not.
They are doing /related/ tasks, but not the kind of thing you get from a
"print" statement in BASIC.
If "print" is a fixed, special built-in feature of the language, then it
is not flexible enough to handle different situations. If instead you
make the core language powerful enough to write "print" as a function
(which you can then put in the standard library for convenience), then
people needing different related tools can make their own.
>> These can all be handled in a language-definable function, and do not
>> need special handling.
>
> 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.
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.
>
> Here is a task that prints an integer 'i', and its square root, followed
> by a newline, to the console, in several languages:
>
> Zig: std.debug.print("{} {}\n",.{i,@sqrt(@as(f64,@floatFromInt(i)))});
>
> C: printf("%d %f\n", i, sqrt(i));
>
> C++: std::cout << i << " " << sqrt(i) << std::endl;
>
> M: println i, sqrt i
>
> BASIC: 10 PRINT I, SQR(I)
>
> The first three all need prerequisites to make it work. The last two
> need nothing, not even variadic functions.
>
> Maybe it's a coincidence that both have Print and Sqrt as built-ins.
BASIC is made to be simple to learn for beginners, and not for large,
serious, long-term programs. And it's great for its task. But it is
inflexible and not scalable.
Oh, and modern C++ provides :
import std;
std::println("i = {}, √i = {}", i, std::sqrt(i));
With C11, I can write my own print/println macros so that I can write :
println("i = ", i, ", √i = ", sqrt(i));
These are all type-safe, by the way.
And with the C++ version, when you make "i" a complex number, it works
the same. When you make a square matrix class and make "i" a matrix,
you can write formatters (for the "cout" and "print/println/format"
versions) for printing out your matrices. You can write a "sqrt"
function for your matrices. (The C11 macros are less flexible - you
need to know the types when the macros are defined.)
Yes, BASIC - and your language - are simple for simple programs in
specific use-cases and specific environments. And you will have added
particular features as you needed them for your bigger programs. But
they are not realistic for a wide audience and wide use-cases. There
are good reasons that there are many different programs available.
>
>>> Other languages have their own problems in fitting those requirements
>>> to standard functions
>>>
>> If you want something complex, it is complex.
>>
>> All you do by having it as a special built-in feature of the language
>> is limited its usefulness, and mean that people have to re-invent it
>> anyway.
>>
>> I understand your style of thinking - it's the way people thought
>> about programming language forty-odd years ago.
>
> More like 50 years. But yes, when things were simple: see my examples
> above. So what the hell happened?
The world moved on, and you didn't.
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. But the language and tools are totally unsuitable to work I
do now. I don't use C for things that are hard to write in C - I use C
for things that are best written in C. If another language is better
for the task, I use that. ("Better" here includes being familiar with
the language.)
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-29 12:54 +0100 |
| Message-ID | <119g8t8$38c73$1@dont-email.me> |
| In reply to | #402497 |
On 29/09/2026 08:45, David Brown wrote:
> On 28/09/2026 21:26, bart wrote:
>> On 28/09/2026 17:49, David Brown wrote:
>>> Lots of programs have little or no use for "print", or they need
>>> something significantly different (showing messages in a dialog box,
>>> printing them to logs or serial ports, etc.
>>
>> So they /are/ using Print, which still has a variety of uses:
>>
>
> No, they are not.
>
> They are doing /related/ tasks, but not the kind of thing you get from a
> "print" statement in BASIC.
Well, BASIC has some other limitations (like no functions). But one of
its purposes was for use from a terminal, and there PRINT is simple to use.
(My SQRT example actually came from the first program I'd ever seen,
which was in 1975. I was being shown around a college and I asked what
some piece of computer equipment to do.
My guide went to the nearest terminal (an ASR33) and typed in a program
like this:
10 FOR I=1, 20
20 PRINT I, SQR(I)
30 NEXT T
He ran it and it printed, on the same paper, a table of square roots.
(This BASIC printed numbers within a fixed-width field so it was nicely
tabulated.))
My claim is that all these tasks can be done with Print, and it is
useful to have it as a built-in feature.
> If "print" is a fixed, special built-in feature of the language, then it
> is not flexible enough to handle different situations.
Such as? Come on, give me a challenge!
My first scripting language has Print with an option 'dev' like this:
print #dev, items..
'dev' could refer to the console, an open file, an LPT port, a COM port,
a graphics window, an image, or a string.
Yes, you can do all this a lot more awkwardly via functions, but so
what? I can also do arithmetic via functions:
a = ADD(b, MUL(c, c));
This can also be a lot more powerful and flexible (eg. you have
references to ADD or MUL and pass them to other functions), and they can
implemented in libraries that people can override etc, but again so what?
Most people prefer to have them somewhat less flexible and built-in so
that they can do this:
a = b + c * d;
Here the language also takes care of overloads. I happen to think that
Print is as fundamental as this.
> If instead you
> make the core language powerful enough to write "print" as a function
> (which you can then put in the standard library for convenience), then
> people needing different related tools can make their own.
They can make their own anyway; I'm not stopping them. If stuck, they
can always call 'printf' functions from a C library. This is a working
program from my scripting language:
a := i64.min
b := "bart"
println =a, =b
printf("A=%lld, B=%s\n", a, b)
Both print lines produce the same output. But the printf is more typing
(at least I don't need a semicolon!), and it needs a precise format code
which here I happened to know.
But mine is 6 tokens while the printf version is 18 tokens (counting
those inside the string), so why can't I prefer the compact version?
Some people use Print a lot more than you!
> BASIC is made to be simple to learn for beginners, and not for large,
> serious, long-term programs. And it's great for its task. But it is
> inflexible and not scalable.
Yes. But there are things to be learnt from it too. Can a language be as
simple and clear as that, while also being more advanced?
It seems many people think a language syntax has to be as abstruse as
C++ in order to be taken seriously.
> Oh, and modern C++ provides :
>
> import std;
> std::println("i = {}, √i = {}", i, std::sqrt(i));
So you agree that that "<<" business was an anomaly?
> With C11, I can write my own print/println macros so that I can write :
>
> println("i = ", i, ", √i = ", sqrt(i));
>
> These are all type-safe, by the way.
>
> And with the C++ version, when you make "i" a complex number, it works
> the same. When you make a square matrix class and make "i" a matrix,
> you can write formatters (for the "cout" and "print/println/format"
> versions) for printing out your matrices. You can write a "sqrt"
> function for your matrices. (The C11 macros are less flexible - you
> need to know the types when the macros are defined.)
OK, that's getting there. But how many advanced, complex (and
inefficient-to-compile) language features are needed to arrive at this
point?
>
> Yes, BASIC - and your language - are simple for simple programs in
> specific use-cases and specific environments.
There are about 250 different Basics now - some will be OK used at scale
(eg. the latest VB).
While I can't see why my product, and my form of Print, can't scale either.
I did ask above for a challenge. Don't forget it is possible to use
other language features to create strings which are then submitted to
Print! Or sometime they be output directly. The flexibility exists.
>> More like 50 years. But yes, when things were simple: see my examples
>> above. So what the hell happened?
>
> The world moved on, and you didn't.
Well, I used to think that was a problem (and why I retired in 1999).
Now I don't.
I bet a lot of people are wishing the world hadn't moved on so much, and
it's barely got going.
I mean, it seems few people are going to doing much hands-on programming
in the future so the question of whether Print is built-in or not will
be moot.
However, it is still relevant to me.
>
> 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. But the language and tools are totally unsuitable to work I
> do now.
My experience was different: thrown in at the deep end into
microprocessors, hardware and low-level work. My degree was CS not EE,
but that job as test engineer from a small ad in the local paper was all
I could find.
So I used my background to create languages and tools to excel in my
job, to apply them to the commercial software I later did, and which
have now involved into what I have now.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-29 15:56 +0200 |
| Message-ID | <119gg2o$3b848$1@dont-email.me> |
| In reply to | #402500 |
On 29/09/2026 13:54, bart wrote:
> On 29/09/2026 08:45, David Brown wrote:
>> On 28/09/2026 21:26, bart wrote:
>>> On 28/09/2026 17:49, David Brown wrote:
>
>>>> Lots of programs have little or no use for "print", or they need
>>>> something significantly different (showing messages in a dialog box,
>>>> printing them to logs or serial ports, etc.
>>>
>>> So they /are/ using Print, which still has a variety of uses:
>>>
>>
>> No, they are not.
>>
>> They are doing /related/ tasks, but not the kind of thing you get from
>> a "print" statement in BASIC.
>
> Well, BASIC has some other limitations (like no functions). But one of
> its purposes was for use from a terminal, and there PRINT is simple to use.
That depends on the BASIC variant. In general, BASIC's were tuned to
simple and specific environments. There's nothing wrong with that in
itself, but they are not useful as wide-usage general purpose languages.
> 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.
>
>> If "print" is a fixed, special built-in feature of the language, then
>> it is not flexible enough to handle different situations.
>
> 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.
>
> My first scripting language has Print with an option 'dev' like this:
>
> print #dev, items..
>
> 'dev' could refer to the console, an open file, an LPT port, a COM port,
> a graphics window, an image, or a string.
That's only the things /you/ thought about at the time. It doesn't
cover what other people think of later. And it means the language is
burdened with this stuff even if it is not relevant to the user.
(That's less of an issue with a scripting language than a compiled
language.)
>
> Yes, you can do all this a lot more awkwardly via functions, but so
> what? I can also do arithmetic via functions:
>
> a = ADD(b, MUL(c, c));
>
> This can also be a lot more powerful and flexible (eg. you have
> references to ADD or MUL and pass them to other functions), and they can
> implemented in libraries that people can override etc, but again so what?
>
> Most people prefer to have them somewhat less flexible and built-in so
> that they can do this:
>
> a = b + c * d;
>
For basic arithmetic, it's easy to specify the main operations. There
is a bit of decision making for things like power operators, but it's
mostly all there. Printing is not like that.
And more advanced languages let you override operators for different
types, precisely so that you don't have to use prefix function notation
for your application or library types.
> Here the language also takes care of overloads. I happen to think that
> Print is as fundamental as this.
>
In your limited bubble, that's maybe fine. I'm not saying it is a bad
choice for /your/ language - it's a bad choice for most scalable
general-purpose languages.
>> If instead you make the core language powerful enough to write
>> "print" as a function (which you can then put in the standard library
>> for convenience), then people needing different related tools can make
>> their own.
>
>
>> Oh, and modern C++ provides :
>>
>> import std;
>> std::println("i = {}, √i = {}", i, std::sqrt(i));
>
> So you agree that that "<<" business was an anomaly?
I did not say anything of the sort. I said that modern C++ provides a
different way of doing this - with different pros and cons.
There are things I dislike about iostreams in C++, but it is a solution
that can be very convenient for some uses. The same applies to every
"print" system I have ever seen. That's why it is so important for
serious languages to make them library features.
The C++ language features required to make the std::println() system
work well did not exist when the "cout << " system was developed. The
effort demanded of compilers would have been too much at that time.
Computers are faster and have more resources, so a new more powerful
solution can be made that is type-safe and generates efficient object
code. (The effort needed by compilers is irrelevant in comparison.)
>
>> With C11, I can write my own print/println macros so that I can write :
>>
>> println("i = ", i, ", √i = ", sqrt(i));
>>
>> These are all type-safe, by the way.
>>
>> And with the C++ version, when you make "i" a complex number, it works
>> the same. When you make a square matrix class and make "i" a matrix,
>> you can write formatters (for the "cout" and "print/println/format"
>> versions) for printing out your matrices. You can write a "sqrt"
>> function for your matrices. (The C11 macros are less flexible - you
>> need to know the types when the macros are defined.)
>
> OK, that's getting there. But how many advanced, complex (and
> inefficient-to-compile) language features are needed to arrive at this
> point?
It needs _Generic, and variadic macros.
>
>>
>> Yes, BASIC - and your language - are simple for simple programs in
>> specific use-cases and specific environments.
>
> There are about 250 different Basics now - some will be OK used at scale
> (eg. the latest VB).
VB is a zombie - no matter how hard people try, it is impossible to kill
it off entirely. In VB, printing was not done with a built-in statement
- you used function calls (or methods on labels, dialog boxes, etc.).
>> The world moved on, and you didn't.
>
> Well, I used to think that was a problem (and why I retired in 1999).
> Now I don't.
>
> I bet a lot of people are wishing the world hadn't moved on so much, and
> it's barely got going.
Maybe. Everyone has things that they miss from "the good old days".
Usually their memories are clouded and biased, but there will be some
truth in it.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-29 18:15 +0100 |
| Message-ID | <119gro2$3g678$1@dont-email.me> |
| In reply to | #402506 |
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. > formatting of different types (not just built-in ones) This is a separate requirement. If you mean being able to use standard Print on a user-type so that it invokes a user-defined stringify routine, then C has some trouble here too. (I have it in my dynamic language, achieved by overloading the 'tostr' operator that Print usually applies implicitly. Print is built-in.) >, using > different languages for the fixed parts of the strings. This is that weird ordering thing of printf? You do know you can apply other language features to expressions before submitting the results to Print? You can also not use Print in this case. I use Print for convenience and during development. >> My first scripting language has Print with an option 'dev' like this: >> >> print #dev, items.. >> >> 'dev' could refer to the console, an open file, an LPT port, a COM >> port, a graphics window, an image, or a string. > > That's only the things /you/ thought about at the time. It doesn't > cover what other people think of later. 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. >> Here the language also takes care of overloads. I happen to think that >> Print is as fundamental as this. >> > > In your limited bubble, that's maybe fine. I'm not saying it is a bad > choice for /your/ language - it's a bad choice for most scalable > general-purpose languages. You do know you can have both built-in Print /and/ an I/O library? This point was made above. >>> And with the C++ version, when you make "i" a complex number, it >> OK, that's getting there. But how many advanced, complex (and >> inefficient-to-compile) language features are needed to arrive at this >> point? > > It needs _Generic, and variadic macros. I was thinking of C++. But _Generic and variadic macros in C (add them to variadic functions) I would class as a hack.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-29 20:24 +0200 |
| Message-ID | <119gvoa$3h56b$1@dont-email.me> |
| In reply to | #402513 |
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. 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.) > > 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. > >>>> And with the C++ version, when you make "i" a complex number, it > >>> OK, that's getting there. But how many advanced, complex (and >>> inefficient-to-compile) language features are needed to arrive at >>> this point? >> >> It needs _Generic, and variadic macros. > > I was thinking of C++. But _Generic and variadic macros in C (add them > to variadic functions) I would class as a hack. > You class everything that is not part of your beloved language as a "hack". You'll forgive me for not taking your opinion or classifications seriously. For C++, basically all that was needed for "cout << x" was overloaded operators for user-defined (or library-defined, it's the same thing) types. For the newer "std::print" and "std::format" functions, more powerful compile-time evaluation was needed. Guaranteed compile-time of functions is a useful feature of newer C++, as it gives more efficient object code while letting you be flexible in your source code without having to pre-calculate things. The "format" library combines this with variadic templates and functions to get fully static type-checking of the formats. The implementation of these things is complicated - no question about it. But it uses features that are already in the language and useful for a great many purposes - it did not need special language features added just to be able to write "std::format" or "std::print".
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-29 19:41 +0000 |
| Message-ID | <WvUuS.292$M0U7.280@fx10.iad> |
| In reply to | #402514 |
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 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.
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web