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

Groups > comp.lang.c > #146018

Re: in place swap of float types

Show all headers | View raw

On 04/09/2019 16:17, Malcolm McLean wrote:
> On Wednesday, 4 September 2019 14:53:40 UTC+1, David Brown  wrote:
>>
>> If I were making my own language, I'd support multiple assignment.  Then
>> there would be no need for "swap" as a function, builtin, macro or
>> anything else - you'd just write "a, b = b, a".
>>
> That's nasty pitfall for the compiler. Asking for a bug where a and b
> are set to b.

That is something you have to consider, and decide how it will be done.
 It is always the case for swapping, and indeed any other feature of a
language - you have to consider degenerate cases.  (Look at how well the
xor swap works for swapping "a" with "a".)

You also have to consider the meaning of things like "*a++, *b++ = b,
a", or other complicating factors.

>>  
>>> That some instructions include a form of exchange is another reason to
>>> consider it a language primitive.
>>
>> I don't expect a programming language to have that kind of one-to-one
>> relationship with instruction sets.
>>
> Historically C does. That's one reason you have ++ as well as += 1. 

No, that is a myth.  "x++;" predates the famous PDP-11, and is nothing
more or less than a convenient abbreviation for "x = x + 1;".  That is
how it is defined in C, and (to my knowledge) the predecessors of C.

> Many
> assemblers have an INC instruction that is faster then a load immediate with
> value 1 and add sequence.

What you are trying to say, I think, is that many processors have an
"inc" instruction that is shorter than an "add #1" instruction.

And many processors do not.  Also, many processors that have an "add #1"
instruction also have short forms for a few other constants, such as any
signed 4-bit number.

There never has been anything close to a 1-to-1 relationship between
operations, statements, or anything else between C and object code of
any processor.


There certainly have been plenty of C compilers that do mostly a "direct
translation" turning expressions and statements in C source into
sequences of object code in a very direct manner.  This has never been
an expectation or requirement in C, but is the hallmark of simple,
cheap, quickly written, low quality C compilers.  (Such tools may be
entirely appropriate and useful despite generating sub-optimal object code.)

> If you're close to the instruction set, it makes the compiler easier to write,
> and it reduces the need for optimisations.

C is low level, not "close to the instruction set".  "Direct
translations" makes a compiler easier to write, but does not help anyone
in any other way.  It typically means the C programmer has to work
harder if they want efficient object code, learning how the compiler
works, and writing a compiler-oriented source rather than source that is
logical, readable and maintainable.  I've used such limited compilers -
it is a step up from programming in assembly, but a step below using a
decent C compiler.

>>
>> I'd rather have:
>>
>> #define SWAP(var1, var2) \
>> 	{ typeof(var1) t = var2; var2 = var1; var1 = t; }
>>
>> Then at least the type is automatic.  (typeof is a gcc'ism, but
>> supported by a few other compilers too.)
>>
> In C, I'd like memswap(void *, void *, size_t)
> 
> The advantages:
> 1) mem... is already in the C standard library namespace.

If we are talking about adding a feature to the standard library, then
that makes sense for naming.

> 2) The function works like memcpy and memmove.
> 3) A one man compiler can easily provide it as a simple byte copying loop.
> 4) Because it is a standard library function, and the usual pattern will
> be to swap two small variables, the compiler can optimise to a register
> exchange.

Yes, that's true.

But I believe we were talking about user-written code, /not/ adding
something to the compiler.  Having a function like this is likely to be
inefficient even if the function definition is visible to the compiler,
and will definitely be inefficient if it is in a separate translation
unit.  There is no point in inventing a "swap" that is inefficient, and
since a function implementation is likely to be inefficient, the choice
falls on a macro.

> 5) You don't need dialects of C which aren't supported everywhere.
> 6) You can easily swap memory buffers whose size is determined at runtime,
> using the same logic.
> 7) You can implement it without using any RAM.
> 
> The disadvantages:
> a) You can't easily test for overlapping buffers (identical buffers can be a
> no-op).

You compare the two pointers - it's not hard.

> b) It's less easy to read than a straight identifier "swap".

I disagree.

> c) Objects with pointers to internal members become invalid, and again you 
> can't easily warn.
> 

That would be going well beyond the level of sophistication you would
expect in C.  When you want something smarter, use a different language
(like C++ and its std::swap).  In C, you expect to handle such
situations manually.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

in place swap of float types 3queens@shabbyroad.com - 2019-08-27 17:03 +0000
  Re: in place swap of float types Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-27 19:22 +0000
    Re: in place swap of float types Andrew Smallshaw <andrews@sdf.org> - 2019-09-02 15:25 +0000
      Re: in place swap of float types Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-09-02 19:37 +0000
        Re: in place swap of float types Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-03 06:37 -0700
          Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-09-03 16:13 +0200
            Re: in place swap of float types Bart <bc@freeuk.com> - 2019-09-03 16:54 +0100
              Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-09-04 11:19 +0200
                Re: in place swap of float types Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-04 02:35 -0700
                Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-09-04 12:31 +0200
                Re: in place swap of float types Bart <bc@freeuk.com> - 2019-09-04 12:12 +0100
                Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-09-04 15:53 +0200
                Re: in place swap of float types Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-04 07:17 -0700
                Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-09-05 15:12 +0200
                Re: in place swap of float types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-09-05 21:11 +0100
                Re: in place swap of float types Bart <bc@freeuk.com> - 2019-09-04 16:30 +0100
                Re: in place swap of float types jadill33@gmail.com - 2019-09-04 10:26 -0700
                Re: in place swap of float types Ike Naar <ike@iceland.freeshell.org> - 2019-09-05 06:00 +0000
                Re: in place swap of float types Bart <bc@freeuk.com> - 2019-09-05 11:14 +0100
                Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-09-05 14:54 +0200
                Re: in place swap of float types Bart <bc@freeuk.com> - 2019-09-05 15:48 +0100
                Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-09-06 10:35 +0200
                Re: in place swap of float types Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-06 02:52 -0700
                Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-09-06 13:18 +0200
                Re: in place swap of float types Bart <bc@freeuk.com> - 2019-09-06 12:14 +0100
                Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-09-06 15:08 +0200
                Re: in place swap of float types Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-06 06:23 -0700
                Re: in place swap of float types Keith Thompson <kst-u@mib.org> - 2019-09-04 14:16 -0700
                Re: in place swap of float types Bart <bc@freeuk.com> - 2019-09-04 22:42 +0100
                Re: in place swap of float types Keith Thompson <kst-u@mib.org> - 2019-09-04 15:21 -0700
                Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-09-05 15:15 +0200
              Re: in place swap of float types Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-09-04 08:05 -0600
                Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-09-05 15:17 +0200
                Re: in place swap of float types Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-09-05 20:28 -0600
                Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-09-06 10:39 +0200
                Re: in place swap of float types Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-09-06 08:11 -0600
                Re: in place swap of float types scott@slp53.sl.home (Scott Lurndal) - 2019-09-06 18:31 +0000
          Re: in place swap of float types Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-09-04 19:02 +0000
      Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-09-02 22:16 +0200
  Re: in place swap of float types Robert Wessel <robertwessel2@yahoo.com> - 2019-08-27 17:59 -0500
    Re: in place swap of float types Richard Damon <Richard@Damon-Family.org> - 2019-08-27 17:45 -0700
    Re: in place swap of float types James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-27 20:48 -0400
      Re: in place swap of float types Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-09-03 06:17 -0700
    Re: in place swap of float types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-08-28 02:09 +0100
    Re: in place swap of float types Siri Cruise <chine.bleu@yahoo.com> - 2019-08-27 21:26 -0700
    Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-08-28 09:22 +0200
    Re: in place swap of float types Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-08-28 16:36 -0700
  Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-08-28 09:36 +0200
    Re: in place swap of float types Bart <bc@freeuk.com> - 2019-08-28 12:02 +0100
      Re: in place swap of float types James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-28 05:08 -0700
        Re: in place swap of float types Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-08-28 05:26 -0700
        Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-08-28 14:40 +0200
        Re: in place swap of float types Keith Thompson <kst-u@mib.org> - 2019-08-28 13:01 -0700
    Re: in place swap of float types Philipp Klaus Krause <pkk@spth.de> - 2019-09-04 11:18 +0200
      Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-09-04 12:57 +0200
        Re: in place swap of float types Philipp Klaus Krause <pkk@spth.de> - 2019-09-04 13:24 +0200
  Re: in place swap of float types Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-05 08:18 +0200
    Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-09-05 15:19 +0200
      Re: in place swap of float types Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-05 16:18 +0200
        Re: in place swap of float types Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-05 07:32 -0700
          Re: in place swap of float types Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-05 17:32 +0200
          Re: in place swap of float types David Brown <david.brown@hesbynett.no> - 2019-09-06 10:54 +0200
            Re: in place swap of float types Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-06 14:23 +0200

csiph-web