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 | 3 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 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-10 13:40 -0700 |
| Message-ID | <lnlh04s6ho.fsf@kst-u.example.com> |
| In reply to | #92098 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> 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.
Here's the context I was replying to, written upthread by supercat:
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 took "fixed type" to mean that the function takes a variable number of
objects, all of the same type. Presumably that type would be identified
by the function declaration. supercat assumed, as far as I can tell,
that the array would be homogeneous. This is a kind of variadic
function that does not currently exist in C.
I did not and do not proposed using heterogeneous arrays to replace
existing variadic functions. Something like that could certainly be
possible in some non-C language (or perhaps in some future or extended
version of C), but it's not what I was talking about.
There was a second part to his proposal regarding variadic functions
that can take arguments of different types. I did not comment on that.
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-12 08:01 +1200 |
| Message-ID | <e143sfFefeeU1@mid.individual.net> |
| In reply to | #92084 |
On 08/11/16 04:56 AM, Keith Thompson wrote:
> 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.
C++ initializer_list provides a similar syntax:
#include <initializer_list>
void f( std::initializer_list<int> );
int main()
{
f( {1,2,3,4} );
}
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2016-08-10 15:00 -0500 |
| Message-ID | <nog15n$ne6$1@news.albasani.net> |
| In reply to | #92068 |
On 8/10/2016 9:43 AM, 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? 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.
>
more common in VM languages is to handle variable argument
functions/methods by transforming the variable argument list into an
"untyped" array (or list, in some languages), and then passing this
array as an implicit final argument.
in my current language (BGBScript2), this is handled by converting the
values to 'variant', and storing in a variant array, which provides for
basic run-time type information via the use of 64-bit tagged values
(though generally it sticks with printf style formatting).
a previous language of mine (C-Aux) did something similar (using an
array of untyped 64-bit values for the argument list).
in both VMs, there is a bit of hackery in place in the FFI to deal with
traditional C vararg functions, which exist in-addition-to the explicit
named arg lists.
ex, in BS2:
native void foo1(cstring str, ...);
native void foo2(cstring str, ... va);
foo1 will accept variable arguments C-style, whereas foo2 will accept
them as a variant array. the 'cstring' type basically means to coerce
the VM string to a "char *" array (nominally UTF-8) for the C function
(as opposed to giving it a tagged address for the string).
within the script-language, these cases are more-or-less equivalent,
though a name is required to be present in the function/method in order
to be able to access the argument list, and there is no technical need
for any fixed arguments to precede the variable args.
side note:
currently, in the BS2 FFI, I am only really requiring support for
functions of up to 4 arguments (fixed and C-style vararg), with longer
argument lists being target specific.
reason mostly has to do with function dispatch via a big switch (in the
plain C case) and the issue that the number of possible argument lists
is exponential (likewise, the 4-level dispatch is still way too big for
most MCUs, although I am not targeting MCUs, *1).
dealing with longer arg lists is only really viable for targets where
ASM code can be used for the dispatch, but I am mostly limiting the
API/... to things which can be safely doable via a plain C interpreter
(even if I am currently internally using a JIT on 32-bit x86, TODO: JITs
for ARM and x86-64).
well, likewise, the bytecode is designed to be reasonable to interpret
via a while/switch interpreter without too much penalty (at least much
beyond what is implied by using a while/switch interpreter).
*1: a possible experiment could be trying to see if a version of the
interpreter backend can be written which is small enough to be usable on
a typical Cortex-M MCU (with only on-chip SRAM and Flash), but I have
doubts if this is really viable.
mostly I have been targeting hardware with at least several MB of RAM
and Flash.
or such...
[toc] | [prev] | [standalone]
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
Back to top | Article view | comp.lang.c
csiph-web