Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #91879 > unrolled thread
| Started by | Real Troll <real.troll@trolls.com> |
|---|---|
| First post | 2016-08-07 17:59 -0400 |
| Last post | 2016-08-10 15:00 -0500 |
| Articles | 20 on this page of 123 — 23 participants |
Back to article view | Back to comp.lang.c
Float Vs Double Real Troll <real.troll@trolls.com> - 2016-08-07 17:59 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-07 23:38 +0100
Re: Float Vs Double Real Troll <real.troll@trolls.com> - 2016-08-07 18:55 -0400
Re: Float Vs Double jameskuyper@verizon.net - 2016-08-07 16:43 -0700
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-07 19:36 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 04:05 +0100
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-07 20:41 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 11:41 +0100
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 04:23 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 23:45 +0100
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-10 03:26 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 01:00 +0100
Re: Float Vs Double jameskuyper@verizon.net - 2016-08-08 08:52 -0700
Re: Float Vs Double James Kuyper <jameskuyper@verizon.net> - 2016-08-08 11:58 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 10:06 -0700
Re: Float Vs Double "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-08 19:46 -0400
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 21:29 -0400
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 14:04 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 09:00 -0400
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 18:43 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 14:34 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 12:00 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 16:42 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 14:04 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-09 08:48 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-10 03:22 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-21 18:31 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-08-22 08:39 -0700
Re: Float Vs Double Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-22 19:29 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-22 19:24 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 01:01 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-22 21:58 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-23 09:38 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 08:15 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-23 15:07 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 09:40 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 15:14 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 10:38 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 17:18 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 15:47 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-23 16:39 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 11:45 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-23 21:42 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 15:52 -0400
Re: Float Vs Double Ian Collins <ian-news@hotmail.com> - 2016-08-24 08:36 +1200
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-24 09:39 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 11:31 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 10:48 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 08:17 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-23 06:01 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 09:44 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-23 07:19 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 10:39 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-23 08:18 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 14:47 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 10:40 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-24 01:31 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 20:53 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-08-23 23:20 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 11:32 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-24 09:46 +0200
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-24 14:53 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 11:35 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-24 08:57 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-24 17:36 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 12:50 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-24 17:26 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 12:51 -0400
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 11:33 -0400
Re: Float Vs Double Robert Wessel <robertwessel2@yahoo.com> - 2016-08-28 02:33 -0500
Re: Float Vs Double antispam@math.uni.wroc.pl - 2016-08-31 22:36 +0000
Re: Float Vs Double supercat@casperkitty.com - 2016-08-31 15:51 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 22:42 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-09-01 08:32 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 15:00 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-09-01 13:45 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 20:50 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-09-02 08:11 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 12:25 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-09-02 20:42 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 16:25 -0400
Re: Float Vs Double Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-03 08:43 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 10:48 -0400
Re: Float Vs Double Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-03 19:43 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 18:16 -0400
Re: Float Vs Double asetofsymbols@gmail.com - 2016-09-08 11:18 -0700
Re: Float Vs Double Robert Wessel <robertwessel2@yahoo.com> - 2016-09-07 19:59 -0500
Re: Float Vs Double supercat@casperkitty.com - 2016-09-08 08:13 -0700
Re: Float Vs Double Robert Wessel <robertwessel2@yahoo.com> - 2016-09-08 19:34 -0500
Re: Float Vs Double supercat@casperkitty.com - 2016-09-09 07:50 -0700
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-02 23:40 -0700
Re: Float Vs Double Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-03 09:06 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 10:52 -0400
Re: Float Vs Double Rosario19 <Ros@invalid.invalid> - 2016-08-24 08:57 +0200
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-24 01:04 -0700
Re: Float Vs Double Ike Naar <ike@iceland.freeshell.org> - 2016-08-08 06:44 +0000
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-08 00:16 -0700
Re: Float Vs Double Richard Damon <Richard@Damon-Family.org> - 2016-08-08 23:29 -0400
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 14:03 +0200
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-08 05:14 -0700
Re: Float Vs Double BGB <cr88192@hotmail.com> - 2016-08-09 19:53 -0500
Re: Float Vs Double "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-07 18:47 -0400
Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 17:04 -0700
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-08 05:49 -0700
Re: Float Vs Double Nobody <nobody@nowhere.invalid> - 2016-08-10 03:26 +0100
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-09 20:15 -0700
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-10 06:07 -0700
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-10 06:13 -0700
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-10 16:43 +0200
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-10 07:56 -0700
Re: Float Vs Double supercat@casperkitty.com - 2016-08-10 08:39 -0700
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-10 09:56 -0700
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-10 10:04 -0700
Re: Float Vs Double Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-11 07:08 -0700
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-11 07:15 -0700
Re: Float Vs Double Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-12 08:11 -0700
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-10 20:38 +0200
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-10 12:20 -0700
Re: Float Vs Double supercat@casperkitty.com - 2016-08-10 12:17 -0700
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-10 21:48 +0200
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-10 13:40 -0700
Re: Float Vs Double Ian Collins <ian-news@hotmail.com> - 2016-08-12 08:01 +1200
Re: Float Vs Double BGB <cr88192@hotmail.com> - 2016-08-10 15:00 -0500
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2016-08-09 19:53 -0500 |
| Message-ID | <nodtub$6g6$1@news.albasani.net> |
| In reply to | #91950 |
On 8/8/2016 7:14 AM, Rick C. Hodgin wrote: > On Monday, August 8, 2016 at 8:03:45 AM UTC-4, jacobnavia wrote: >> Le 08/08/2016 à 00:55, Real Troll a écrit : >>> So how do you perform scientific calculations which have to be as >>> precise as possible? what changes one has to make to get 22 or more >>> decimal places (see the program I gave before). To give you a trivial >>> example, PI can be written as infinite decimal places so how do you >>> accommodate this? >> >> Use the lcc-win compiler system! >> >> lcc-win offers >> >> 1) Real long double (80 bits) support with approx 19 decimal digits > > Awesome. Many old compilers used to support those, but dropped > support over time to be compatible with other architectures that > did not have them. > > Do you have a native type name for them (rather than "long double")? > CAlive plans f32, f64, and f80 for CPU-supported types. > one of my older compilers supported long-double, but padded it to 128 bits (to make it easier to move around with SSE operations). internally, it was also used as a fallback for implementing unsupported float128 ops, given it is fairly straightforward to convert between float80 and float128 (in the typical case where float80 is normalized, though at least theoretically it is possible to have denormalized long-double numbers). the drawback is that in recent processors, x87 ops are slower than SSE ops, so SSE2 scalar ops are generally preferable here. however, these only directly support 32 and 64 bit floating point types. >> 2) 128 bit IEEE double precision with around 30 decimal digits > > Where does lcc get support for this? From a source like the double-double > and quad-double libraries? Or did you write your own? > > Double-double, Quad-double, using hardware for higher precision: > http://web.mit.edu/tabbott/Public/quaddouble-debian/qd-2.3.4-old/docs/qd.pdf > at least in my case, I have generally written my own. it isn't really all that hard, and most other operations can be done with a few core operations. however, it does help to have 128 bit integer operations in place first, as these are generally pretty useful in implementing the FP ops. the older compiler fell back to float80 for reciprocal, but a newer implementation does this as well. for the 128-bit integer ops, edge cases exist internally where one either needs wide ops (where the operation works on pairs of 128 bit values), split high/low ops, or full 256 bit integer ops. in my case, I did some wide ops and a few split ops, noting that this was more convenient than dealing with a dedicated 256-bit type. by implication, 128 bit floating-point types tend to be pretty slow vs native 32/64 bit types. >> 3) Qfloat numbers with approx 130 (!!!) digits precision > > What are Qfloats? And how do they get 130 digits of precision? > a quick estimate implies a 480 bit mantissa with a 32 bit exponent, which would have enough bits for this many digits. >> All those types are supported by printf > > An impressive assemblage of floating point power, Jacob. > in my case, I haven't gone quite so far with it, rarely having much use for types quite this large. in my case, I much more often have reason to make use of 16-bit half-floats.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-07 18:47 -0400 |
| Message-ID | <951b303a-4819-29c1-4f78-135d3ffa24ed@verizon.net> |
| In reply to | #91879 |
On 08/07/2016 06:26 PM, Stefan Ram wrote: > Real Troll <real.troll@trolls.com> writes: >> Any reasons why the default precision value is still 6 since the bad old >> days? For example the result I get is this: > > There is no »default precision value« in C. "If the precision is missing, it is taken as 6" (7.21.6.1p8), describing the f and F conversion specifiers. "if the precision is missing, it is taken as 6" - describing the e and E conversion specifiers. "Let P equal the precision if nonzero, 6 if the precision is omitted, or 1 if the precision is zero." - describing the g and G conversion specifiers.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-07 17:04 -0700 |
| Message-ID | <8a7a94a5-fb11-40a4-b7f7-c0d59859a581@googlegroups.com> |
| In reply to | #91879 |
Real Troll wrote:
> printf("x=%f\n", x);
> printf("z=%f\n", z);
> printf("x=%20.18f\n", x);
> printf("z=%20.18f\n", z);
Shouldn't doubles use %lf?
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-08 05:49 -0700 |
| Message-ID | <09418171-b259-440e-ba7e-9f3120d6d1cb@googlegroups.com> |
| In reply to | #91898 |
On Sunday, August 7, 2016 at 8:05:08 PM UTC-4, Rick C. Hodgin wrote:
> Real Troll wrote:
> > printf("x=%f\n", x);
> > printf("z=%f\n", z);
> > printf("x=%20.18f\n", x);
> > printf("z=%20.18f\n", z);
>
> Shouldn't doubles use %lf?
In a test in Microsoft's C Compiler with Visual Studio 2015, changing
the double values to use %lf provides the full accuracy.
It is likely the parameters are being loaded in their float our double
form into ST0, passed to the function, which then, because it's only %f,
does not extract the full digits accurately.
If you generate an assembly listing and post that code, Real Troll, I
can tell you for sure.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.invalid> |
|---|---|
| Date | 2016-08-10 03:26 +0100 |
| Message-ID | <pan.2016.08.10.02.26.28.604000@nowhere.invalid> |
| In reply to | #91898 |
On Sun, 07 Aug 2016 17:04:54 -0700, Rick C. Hodgin wrote:
>> printf("x=%f\n", x);
>> printf("z=%f\n", z);
>> printf("x=%20.18f\n", x);
>> printf("z=%20.18f\n", z);
>
> Shouldn't doubles use %lf?
The "l" modifier has no effect for floating-point conversions.
7.19.6.1p7:
l (ell) Specifies that a following d, i, o, u, x, or X
conversion specifier applies to a long int or
unsigned long int argument; that a following n
conversion specifier applies to a pointer to a
long int argument; that a following c
conversion specifier applies to a wint_t
argument; that a following s conversion
specifier applies to a pointer to a wchar_t
argument; or has no effect on a following a, A,
e, E, f, F, g, or G conversion specifier.
A float will automatically be promoted to double when passed as an
argument whose type isn't specified by a function prototype (i.e. if
there's no prototype in scope, or if the function is variadic and the
argument corresponds to the ellipsis rather than to a specified parameter).
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-09 20:15 -0700 |
| Message-ID | <05fdbeec-4dc4-4643-a380-a7491446ff3a@googlegroups.com> |
| In reply to | #92043 |
Nobody wrote:
> On Sun, 07 Aug 2016 17:04:54 -0700, Rick C. Hodgin wrote:
> > > printf("x=%f\n", x);
> > > printf("z=%f\n", z);
> > > printf("x=%20.18f\n", x);
> > > printf("z=%20.18f\n", z);
> > Shouldn't doubles use %lf?
>
> The "l" modifier has no effect for floating-point conversions.
There is evidence to the contrary in Visual Studio 2015. I'll
double check tomorrow.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-10 06:07 -0700 |
| Message-ID | <672cb084-e954-483d-b5ec-8a1280f0b202@googlegroups.com> |
| In reply to | #92044 |
On Tuesday, August 9, 2016 at 11:15:33 PM UTC-4, Rick C. Hodgin wrote:
> Nobody wrote:
> > On Sun, 07 Aug 2016 17:04:54 -0700, Rick C. Hodgin wrote:
> > > > printf("x=%f\n", x);
> > > > printf("z=%f\n", z);
> > > > printf("x=%20.18f\n", x);
> > > > printf("z=%20.18f\n", z);
> > > Shouldn't doubles use %lf?
> >
> > The "l" modifier has no effect for floating-point conversions.
>
> There is evidence to the contrary in Visual Studio 2015. I'll
> double check tomorrow.
I stand corrected. The use of %lf or %f makes no difference.
Output:
3.141592653589793238 ==> Actual value
f32 %f = 3.141593
f64 %f = 3.141593
f64 %lf = 3.141593
f32 %f = 3.141592741012573242
f64 %f = 3.141592653589793116
f64 %lf = 3.141592653589793116
Storage size for float : 4
Storage size for double: 8
Minimum float value: 1.175494E-38
Maximum float value: 3.402823E+38
Precision value: 6
Source file:
#include <stdio.h>
#include <stdlib.h>
#include <float.h>
int main(void)
{
float x = 3.141592653589793238;
double z = 3.141592653589793238;
printf("3.141592653589793238 ==> Actual value\n");
printf("f32 %%f = %f\n", x);
printf("f64 %%f = %f\n", z);
printf("f64 %%lf = %lf\n", z);
printf("f32 %%f = %20.18f\n", x);
printf("f64 %%f = %20.18f\n", z);
printf("f64 %%lf = %20.18lf\n\n", z);
printf("Storage size for float : %d \n", sizeof(float));
printf("Storage size for double: %d \n", sizeof(double));
printf("Minimum float value: %E\n", FLT_MIN);
printf("Maximum float value: %E\n", FLT_MAX);
printf("Precision value: %d\n", FLT_DIG);
return 0;
}
I misread the OP's output to read incorrectly on the z line with %f.
I read it as not having the full significant digits.
My mistake all around.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-10 06:13 -0700 |
| Message-ID | <bda0694a-a0e5-4c92-97fa-05a6575fafe7@googlegroups.com> |
| In reply to | #92043 |
On Tuesday, August 9, 2016 at 10:26:37 PM UTC-4, Nobody wrote:
> On Sun, 07 Aug 2016 17:04:54 -0700, Rick C. Hodgin wrote:
>
> >> printf("x=%f\n", x);
> >> printf("z=%f\n", z);
> >> printf("x=%20.18f\n", x);
> >> printf("z=%20.18f\n", z);
> >
> > Shouldn't doubles use %lf?
>
> The "l" modifier has no effect for floating-point conversions.
>
> 7.19.6.1p7:
>
> l (ell) Specifies that a following d, i, o, u, x, or X
> conversion specifier applies to a long int or
> unsigned long int argument; that a following n
> conversion specifier applies to a pointer to a
> long int argument; that a following c
> conversion specifier applies to a wint_t
> argument; that a following s conversion
> specifier applies to a pointer to a wchar_t
> argument; or has no effect on a following a, A,
> e, E, f, F, g, or G conversion specifier.
>
> A float will automatically be promoted to double when passed as an
> argument whose type isn't specified by a function prototype (i.e. if
> there's no prototype in scope, or if the function is variadic and the
> argument corresponds to the ellipsis rather than to a specified parameter).
FWIW, CAlive would've gotten that wrong (with regards to C). I would've
passed a 32-bit quantity for float, and a 64-bit quantity for double, and
would've required use of %f and %lf to access them properly.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-10 16:43 +0200 |
| Message-ID | <nofehm$68q$1@dont-email.me> |
| In reply to | #92064 |
On 10/08/16 15:13, Rick C. Hodgin wrote:
> On Tuesday, August 9, 2016 at 10:26:37 PM UTC-4, Nobody wrote:
>> On Sun, 07 Aug 2016 17:04:54 -0700, Rick C. Hodgin wrote:
>>
>>>> printf("x=%f\n", x);
>>>> printf("z=%f\n", z);
>>>> printf("x=%20.18f\n", x);
>>>> printf("z=%20.18f\n", z);
>>>
>>> Shouldn't doubles use %lf?
>>
>> The "l" modifier has no effect for floating-point conversions.
>>
>> 7.19.6.1p7:
>>
>> l (ell) Specifies that a following d, i, o, u, x, or X
>> conversion specifier applies to a long int or
>> unsigned long int argument; that a following n
>> conversion specifier applies to a pointer to a
>> long int argument; that a following c
>> conversion specifier applies to a wint_t
>> argument; that a following s conversion
>> specifier applies to a pointer to a wchar_t
>> argument; or has no effect on a following a, A,
>> e, E, f, F, g, or G conversion specifier.
>>
>> A float will automatically be promoted to double when passed as an
>> argument whose type isn't specified by a function prototype (i.e. if
>> there's no prototype in scope, or if the function is variadic and the
>> argument corresponds to the ellipsis rather than to a specified parameter).
>
> FWIW, CAlive would've gotten that wrong (with regards to C). I would've
> passed a 32-bit quantity for float, and a 64-bit quantity for double, and
> would've required use of %f and %lf to access them properly.
>
Does CAlive have variable argument functions like printf? If I were
making a new language, I'd drop such functions - they are error prone,
hard to implement well, and difficult for compile-time checking or
typing. In Windows, the 64-bit ABI for function calls is crippled to
give every function call significantly bigger run-time and stack space
overhead than necessary simply to support variable argument functions.
Support for higher level data structures such as tuples or lists would
make variable argument functions unnecessary.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-10 07:56 -0700 |
| Message-ID | <714a9d5d-e72d-4fe5-ae29-2f89a960df68@googlegroups.com> |
| In reply to | #92068 |
On Wednesday, August 10, 2016 at 10:43:15 AM UTC-4, David Brown wrote:
> On 10/08/16 15:13, Rick C. Hodgin wrote:
> > On Tuesday, August 9, 2016 at 10:26:37 PM UTC-4, Nobody wrote:
> >> On Sun, 07 Aug 2016 17:04:54 -0700, Rick C. Hodgin wrote:
> >>
> >>>> printf("x=%f\n", x);
> >>>> printf("z=%f\n", z);
> >>>> printf("x=%20.18f\n", x);
> >>>> printf("z=%20.18f\n", z);
> >>>
> >>> Shouldn't doubles use %lf?
> >>
> >> The "l" modifier has no effect for floating-point conversions.
> >>
> >> 7.19.6.1p7:
> >>
> >> l (ell) Specifies that a following d, i, o, u, x, or X
> >> conversion specifier applies to a long int or
> >> unsigned long int argument; that a following n
> >> conversion specifier applies to a pointer to a
> >> long int argument; that a following c
> >> conversion specifier applies to a wint_t
> >> argument; that a following s conversion
> >> specifier applies to a pointer to a wchar_t
> >> argument; or has no effect on a following a, A,
> >> e, E, f, F, g, or G conversion specifier.
> >>
> >> A float will automatically be promoted to double when passed as an
> >> argument whose type isn't specified by a function prototype (i.e. if
> >> there's no prototype in scope, or if the function is variadic and the
> >> argument corresponds to the ellipsis rather than to a specified parameter).
> >
> > FWIW, CAlive would've gotten that wrong (with regards to C). I would've
> > passed a 32-bit quantity for float, and a 64-bit quantity for double, and
> > would've required use of %f and %lf to access them properly.
> >
>
> Does CAlive have variable argument functions like printf?
Yes. In both native (va_args mode), and a new format I created which
I call an "allow" type, which gives the passed parameter list a token
name to access elements through with [n] references, and dot tags:
https://groups.google.com/forum/#!topic/caliveprogramminglanguage/b52U0R5-gEQ
-----
The allow type is used in lieu of "..." to indicate there are additional
parameters. It conveys a name through which additional parameters can
be accessed at runtime, without requiring a va_args solution (Note:
va_args is still supported).
To access each element in an allow, use its name[n] reference beginning
at n=1. n=0 is reserved for the allow parameter count, as in name[0].
In addition, dot tags are available which provide typing information for
each parameter. Use of name[n].type, for example, returns an integer
which follows back to a litany of _LIVECODE_ALLOW_TYPE_* constants,
which resolve to back to their fundamental types (including any* for
constructed types of class* or struct*)...
-----
As such, each item can be accessed through iteration, and it's basically
an array of pointers to the real data, along with fundamental typing
information. It can also be copied, have elements appended to it,
inserted in it at arbitrary locations, deleted from it at arbitrary
locations, etc.
> If I were
> making a new language, I'd drop such functions - they are error prone,
> hard to implement well, and difficult for compile-time checking or
> typing. In Windows, the 64-bit ABI for function calls is crippled to
> give every function call significantly bigger run-time and stack space
> overhead than necessary simply to support variable argument functions.
>
> Support for higher level data structures such as tuples or lists would
> make variable argument functions unnecessary.
I have also defined a new calling convention that doesn't use the stack
in its traditional sense for passing all parameters, but rather it is
used to hold a pointer, and for its return address, along with any
allocated local variable space. CAlive will use this convention for
all internal calls. When interfacing with the outside world, it will
honor whatever the remote calling convention is.
CAlive essentially creates a custom struct for each function, which it
populates in local variable space (on the stack), which contains both
return parameters, and input parameters, of which there can be zero or
more (up to 10 return parameters, up to 26 I think input parameters).
The structs are created conceptually, and may or may not physically
exist due to optimizations.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-10 08:39 -0700 |
| Message-ID | <0bae28e0-b651-41ba-b195-d5623c70eb18@googlegroups.com> |
| In reply to | #92068 |
On Wednesday, August 10, 2016 at 9:43:15 AM UTC-5, David Brown wrote:
> Does CAlive have variable argument functions like printf? If I were
> making a new language, I'd drop such functions - they are error prone,
> hard to implement well, and difficult for compile-time checking or
> typing.
If I were designing a language, I'd include two kinds of variadic functions
(with a requirement that a prototype identifying the calling convention be in
scope before the call):
1. For functions that use a fixed type, I'd have a declaration that would
cause a sequence of arguments to be stored in a temporary array and
have the caller receive the address of the array and its length. On
most implementations, creating the array on the stack would take the
same amount of work as pushing arguments individually, so the only
extra work would be passing the pointer and the length, but the called
function would then be guaranteed to have an actual array, and it would
also be callable with an array.
2. For functions that use mixed types, I'd have the caller push a
void* identifying a structure whose first member was a pointer to
a function to fetch primitive or pointer arguments into a discriminated
union type. For systems with linkers that support weak declarations
(needed to make "inline" work) the compiler would include a "fetching"
function with a name that depended upon how it expected the structure
to be formatted (so that multiple modules produced by the same
compiler could share the same function, but modules produced by
different compilers could lay out the structure differently). This
approach could actually save code space in programs that make heavy
use of such functions, while of course offering type safety.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-10 09:56 -0700 |
| Message-ID | <lnfuqctvfe.fsf@kst-u.example.com> |
| In reply to | #92076 |
supercat@casperkitty.com writes:
> On Wednesday, August 10, 2016 at 9:43:15 AM UTC-5, David Brown wrote:
>> Does CAlive have variable argument functions like printf? If I were
>> making a new language, I'd drop such functions - they are error prone,
>> hard to implement well, and difficult for compile-time checking or
>> typing.
>
> If I were designing a language, I'd include two kinds of variadic functions
> (with a requirement that a prototype identifying the calling convention be in
> scope before the call):
>
> 1. For functions that use a fixed type, I'd have a declaration that would
> cause a sequence of arguments to be stored in a temporary array and
> have the caller receive the address of the array and its length. On
> most implementations, creating the array on the stack would take the
> same amount of work as pushing arguments individually, so the only
> extra work would be passing the pointer and the length, but the called
> function would then be guaranteed to have an actual array, and it would
> also be callable with an array.
I'd make it possible to pass arrays as arguments (perhaps by reference),
and provide a reasonable syntax for constructing an array value. So
rather than
func(10, 20, 30, 40);
you could write something like
func([10, 20, 30, 40]);
with func taking a single argument of array type, with the bounds made
available to the function. It avoids the need for a special kind of
variadic function and can be used in other contexts.
A number of languages already do something like this.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-10 10:04 -0700 |
| Message-ID | <lnbn10tv1g.fsf@kst-u.example.com> |
| In reply to | #92084 |
Keith Thompson <kst-u@mib.org> writes:
> supercat@casperkitty.com writes:
[...]
>> If I were designing a language, I'd include two kinds of variadic functions
>> (with a requirement that a prototype identifying the calling convention be in
>> scope before the call):
>>
>> 1. For functions that use a fixed type, I'd have a declaration that would
>> cause a sequence of arguments to be stored in a temporary array and
>> have the caller receive the address of the array and its length. On
>> most implementations, creating the array on the stack would take the
>> same amount of work as pushing arguments individually, so the only
>> extra work would be passing the pointer and the length, but the called
>> function would then be guaranteed to have an actual array, and it would
>> also be callable with an array.
>
> I'd make it possible to pass arrays as arguments (perhaps by reference),
> and provide a reasonable syntax for constructing an array value. So
> rather than
> func(10, 20, 30, 40);
> you could write something like
> func([10, 20, 30, 40]);
> with func taking a single argument of array type, with the bounds made
> available to the function. It avoids the need for a special kind of
> variadic function and can be used in other contexts.
>
> A number of languages already do something like this.
>
> [...]
For that matter, it's not that hard to do the equivalent in C:
const int arg[] = { 10, 20, 30, 40 };
func(arg, sizeof arg / sizeof arg[0]);
A little syntactic sugar would be nice, but it's not really necessary.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-11 07:08 -0700 |
| Message-ID | <kfnfuqbgzyt.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92086 |
Keith Thompson <kst-u@mib.org> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> supercat@casperkitty.com writes:
>
> [...]
>
>>> If I were designing a language, I'd include two kinds of variadic functions
>>> (with a requirement that a prototype identifying the calling convention be in
>>> scope before the call):
>>>
>>> 1. For functions that use a fixed type, I'd have a declaration that would
>>> cause a sequence of arguments to be stored in a temporary array and
>>> have the caller receive the address of the array and its length. On
>>> most implementations, creating the array on the stack would take the
>>> same amount of work as pushing arguments individually, so the only
>>> extra work would be passing the pointer and the length, but the called
>>> function would then be guaranteed to have an actual array, and it would
>>> also be callable with an array.
>>
>> I'd make it possible to pass arrays as arguments (perhaps by reference),
>> and provide a reasonable syntax for constructing an array value. So
>> rather than
>> func(10, 20, 30, 40);
>> you could write something like
>> func([10, 20, 30, 40]);
>> with func taking a single argument of array type, with the bounds made
>> available to the function. It avoids the need for a special kind of
>> variadic function and can be used in other contexts.
>>
>> A number of languages already do something like this.
>>
>> [...]
>
> For that matter, it's not that hard to do the equivalent in C:
>
> const int arg[] = { 10, 20, 30, 40 };
> func(arg, sizeof arg / sizeof arg[0]);
>
> A little syntactic sugar would be nice, but it's not really necessary.
Most of the sugaring can be provided by using a suitably defined
macro. Here is a short program to illustrate.
#include <stdio.h>
#define COUNTED_ARRAY( T, ... ) COUNTED_ARRAY_1_( ((T[]){ __VA_ARGS__ }) )
#define COUNTED_ARRAY_1_( it ) (sizeof it / sizeof 0[it]), it
unsigned
add_up( size_t n, unsigned v[static n] ){
unsigned i, t;
printf( " there are %zu elements...\n", n );
for( i = 0, t = 0; i < n; i++ ) t += v[i];
return t;
}
int
main(){
unsigned sum = add_up( COUNTED_ARRAY( unsigned, 3, 4, 5, 6, 7 ) );
printf( " sum is %u\n", sum );
return 0;
}
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-11 07:15 -0700 |
| Message-ID | <fd73511d-4c10-4c16-a05e-400aa5645955@googlegroups.com> |
| In reply to | #92121 |
On Thursday, August 11, 2016 at 10:08:56 AM UTC-4, Tim Rentsch wrote:
> Keith Thompson <kst-u@mib.org> writes:
>
> > Keith Thompson <kst-u@mib.org> writes:
> >> supercat@casperkitty.com writes:
> >
> > [...]
> >
> >>> If I were designing a language, I'd include two kinds of variadic functions
> >>> (with a requirement that a prototype identifying the calling convention be in
> >>> scope before the call):
> >>>
> >>> 1. For functions that use a fixed type, I'd have a declaration that would
> >>> cause a sequence of arguments to be stored in a temporary array and
> >>> have the caller receive the address of the array and its length. On
> >>> most implementations, creating the array on the stack would take the
> >>> same amount of work as pushing arguments individually, so the only
> >>> extra work would be passing the pointer and the length, but the called
> >>> function would then be guaranteed to have an actual array, and it would
> >>> also be callable with an array.
> >>
> >> I'd make it possible to pass arrays as arguments (perhaps by reference),
> >> and provide a reasonable syntax for constructing an array value. So
> >> rather than
> >> func(10, 20, 30, 40);
> >> you could write something like
> >> func([10, 20, 30, 40]);
> >> with func taking a single argument of array type, with the bounds made
> >> available to the function. It avoids the need for a special kind of
> >> variadic function and can be used in other contexts.
> >>
> >> A number of languages already do something like this.
> >>
> >> [...]
> >
> > For that matter, it's not that hard to do the equivalent in C:
> >
> > const int arg[] = { 10, 20, 30, 40 };
> > func(arg, sizeof arg / sizeof arg[0]);
> >
> > A little syntactic sugar would be nice, but it's not really necessary.
>
> Most of the sugaring can be provided by using a suitably defined
> macro. Here is a short program to illustrate.
>
>
> #include <stdio.h>
>
> #define COUNTED_ARRAY( T, ... ) COUNTED_ARRAY_1_( ((T[]){ __VA_ARGS__ }) )
> #define COUNTED_ARRAY_1_( it ) (sizeof it / sizeof 0[it]), it
>
>
> unsigned
> add_up( size_t n, unsigned v[static n] ){
> unsigned i, t;
> printf( " there are %zu elements...\n", n );
> for( i = 0, t = 0; i < n; i++ ) t += v[i];
> return t;
> }
>
> int
> main(){
> unsigned sum = add_up( COUNTED_ARRAY( unsigned, 3, 4, 5, 6, 7 ) );
> printf( " sum is %u\n", sum );
> return 0;
> }
It never ceases to amaze me how so many developers actually believe
something like this is a valid solution for everyday people using the
language.
The far better solution is to offer help to people so they can have
tools that work as they think, not as is merely possible through the
mechanics of the tool, as in the above example.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-12 08:11 -0700 |
| Message-ID | <kfntweqf2du.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92122 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Thursday, August 11, 2016 at 10:08:56 AM UTC-4, Tim Rentsch wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> supercat@casperkitty.com writes:
>>>
>>> [...]
>>>
>>>>> If I were designing a language, I'd include two kinds of variadic functions
>>>>> (with a requirement that a prototype identifying the calling convention be in
>>>>> scope before the call):
>>>>>
>>>>> 1. For functions that use a fixed type, I'd have a declaration that would
>>>>> cause a sequence of arguments to be stored in a temporary array and
>>>>> have the caller receive the address of the array and its length. On
>>>>> most implementations, creating the array on the stack would take the
>>>>> same amount of work as pushing arguments individually, so the only
>>>>> extra work would be passing the pointer and the length, but the called
>>>>> function would then be guaranteed to have an actual array, and it would
>>>>> also be callable with an array.
>>>>
>>>> I'd make it possible to pass arrays as arguments (perhaps by reference),
>>>> and provide a reasonable syntax for constructing an array value. So
>>>> rather than
>>>> func(10, 20, 30, 40);
>>>> you could write something like
>>>> func([10, 20, 30, 40]);
>>>> with func taking a single argument of array type, with the bounds made
>>>> available to the function. It avoids the need for a special kind of
>>>> variadic function and can be used in other contexts.
>>>>
>>>> A number of languages already do something like this.
>>>>
>>>> [...]
>>>
>>> For that matter, it's not that hard to do the equivalent in C:
>>>
>>> const int arg[] = { 10, 20, 30, 40 };
>>> func(arg, sizeof arg / sizeof arg[0]);
>>>
>>> A little syntactic sugar would be nice, but it's not really necessary.
>>
>> Most of the sugaring can be provided by using a suitably defined
>> macro. Here is a short program to illustrate.
>>
>>
>> #include <stdio.h>
>>
>> #define COUNTED_ARRAY( T, ... ) COUNTED_ARRAY_1_( ((T[]){ __VA_ARGS__ }) )
>> #define COUNTED_ARRAY_1_( it ) (sizeof it / sizeof 0[it]), it
>>
>>
>> unsigned
>> add_up( size_t n, unsigned v[static n] ){
>> unsigned i, t;
>> printf( " there are %zu elements...\n", n );
>> for( i = 0, t = 0; i < n; i++ ) t += v[i];
>> return t;
>> }
>>
>> int
>> main(){
>> unsigned sum = add_up( COUNTED_ARRAY( unsigned, 3, 4, 5, 6, 7 ) );
>> printf( " sum is %u\n", sum );
>> return 0;
>> }
>
> It never ceases to amaze me how so many developers actually believe
> something like this is a valid solution for everyday people using the
> language. [...]
I expect you will continue to be amazed for some years to come.
Note by the way that I wasn't advocating this approach be used,
only that it is a way of providing some of the syntactic sugar
for the technique Keith Thompson was discussing.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-08-10 20:38 +0200 |
| Message-ID | <nofsbf$o5b$1@dont-email.me> |
| In reply to | #92084 |
Le 10/08/2016 à 18:56, Keith Thompson a écrit : > I'd make it possible to pass arrays as arguments (perhaps by reference), > and provide a reasonable syntax for constructing an array value. So > rather than > func(10, 20, 30, 40); > you could write something like > func([10, 20, 30, 40]); > with func taking a single argument of array type, with the bounds made > available to the function. It avoids the need for a special kind of > variadic function and can be used in other contexts. > > A number of languages already do something like this. > > [...] > As you (may) know, you are proposing heterogeneous arrays. In C, arrays contain a single type of data. Allowing for arrays that contain different types of data is already possible with structures, but there, array positions are named, what in many cases is a good idea for heterogeneous arrays. Unnamed (by position) arrays would be an innovation that could bring something that we do not have already? Could you describe a use case?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-10 12:20 -0700 |
| Message-ID | <lntwessa6c.fsf@kst-u.example.com> |
| In reply to | #92093 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 10/08/2016 à 18:56, Keith Thompson a écrit :
>
>> I'd make it possible to pass arrays as arguments (perhaps by reference),
>> and provide a reasonable syntax for constructing an array value. So
>> rather than
>> func(10, 20, 30, 40);
>> you could write something like
>> func([10, 20, 30, 40]);
>> with func taking a single argument of array type, with the bounds made
>> available to the function. It avoids the need for a special kind of
>> variadic function and can be used in other contexts.
>>
>> A number of languages already do something like this.
>>
>> [...]
>>
>
> As you (may) know, you are proposing heterogeneous arrays.
I am not. In the part I replied to, supercat proposed a new kind of
variadic function for which all the arguments are of the same type.
I merely pointed out that ordinary homogeneous arrays provide the
same functionality (and in a new language, a bit of added syntactic
sugar could make it more convenient than it is in C).
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-10 12:17 -0700 |
| Message-ID | <557bb9db-be69-48d6-a460-27fc47e01b27@googlegroups.com> |
| In reply to | #92094 |
On Wednesday, August 10, 2016 at 1:55:45 PM UTC-5, Keith Thompson wrote: > I am not. In the part I replied to, supercat proposed a new kind of > variadic function for which all the arguments are of the same type. > I merely pointed out that ordinary homogeneous arrays provide the > same functionality (and in a new language, a bit of added syntactic > sugar could make it more convenient than it is in C). The uniform-type case would be syntactic sugar, with the basic intention being that if a function indicates that it wants a pointer to a bunch of "double" values, along with an indication of how many were passed, the caller's source code shouldn't need to explicitly specify the type nor the number of items, both of which the compiler should be able to determine.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-08-10 21:48 +0200 |
| Message-ID | <nog0f4$7o2$1@dont-email.me> |
| In reply to | #92094 |
Le 10/08/2016 à 21:20, Keith Thompson a écrit : >> As you (may) know, you are proposing heterogeneous arrays. > I am not. In C, function arguments can have ANY type, the array of all arguments to a function is an heterogeneous array. I can see no other example of heterogeneous arrays in C. The arguments are ordered by "first argument", second, etc, from left to right. Conceptually then, the set of arguments to a function is such an array. Your proposal (nowhere was said that all arguments are of the same type) wanted to replace the argument list with an array. Then you started with how to pass it to the function etc.
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web