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


Groups > comp.lang.c > #146059

Re: in place swap of float types

Subject Re: in place swap of float types
Newsgroups comp.lang.c
References (9 earlier) <qkofkt$6m7$1@dont-email.me> <pMQbF.165925$Xs5.5927@fx06.am4> <qkr0i2$322$1@dont-email.me> <tf9cF.443041$TW.79701@fx03.am4> <qkt5p7$jdr$1@dont-email.me>
From Bart <bc@freeuk.com>
Message-ID <FcrcF.240288$TY7.124824@fx29.am4> (permalink)
Organization virginmedia.com
Date 2019-09-06 12:14 +0100

Show all headers | View raw


On 06/09/2019 09:35, David Brown wrote:
> On 05/09/2019 16:48, Bart wrote:
>> On 05/09/2019 13:54, David Brown wrote:
>>> On 04/09/2019 17:30, Bart wrote:
>>
>>> Again, I am not saying "do it like C", or "don't make "swap" a built in
>>> function in your language".  I am merely encouraging that you think
>>> about it, and make considered decisions on a solid basis.  The focus
>>> should be on what is best for the programmer, the user of the language.
>>>    I feel that sometimes your focus is on showing off the simplicity of
>>> your compiler (adding features just because it is easy to do so), or on
>>> picking features precisely because C does not have that feature.  As
>>> justifications for features, these are not much better than saying you
>>> are adding the <^v> "min-max-swap" operator because you had a dream
>>> about it.  And I know you don't want to go there!
>>
>> It is /because/ I have simple compilers, that will not have the
>> optimisations found in some C and C++ compilers, that I place importance
>> on having certain operations built-in. Rather than having to emulate
>> them in unwieldy user-code then relying on optimisation to reduce it down.
> 
> If you give the compiler a built-in, it will generate better object code
> for source using that one feature.  If you give the compiler an
> optimisation, it will generate better object code for /all/ source code.
> 
> Look at how C++ handles this.  (Look at the high level ideas - I am not
> suggesting you copy the syntax :-) ).  Features are added to the core
> language to give wide abilities - details and individual features are
> put in the library.  This gives maximal flexibility, making it
> (relatively) easy to make changes, and the language features allow a
> wide range of library functions to be made.  It avoids duplication of
> the work.  And nothing stops you having the library implementation
> delegating particular functions to built-ins for efficiency.
> 
> 
> I realise you have your priorities, and your finite time, and you are
> writing a one-man compiler for a one-man language.  So you will pick a
> different balance than might be chosen for a more general language.  But
> if you dream of moving it beyond a personal project, please don't hobble
> the language at this stage.  We have more than enough oddities in
> programming languages because the design made sense when the project was
> small.
> 
>>> Depending on the expected usage domains of your language, I think it
>>> would be reasonable to relegate "xor" to a standard library function
>>> too, leaving the ^ symbol for a power operator, or re-direction operator
>>> (like in Pascal).
>>
>> Bitwise XOR will always be in the core language. (I also have logical
>> XOR -would be ^^ in C - but have never used it.)
>>
>> When you see the same macros being defined in every other C program:
>> STREQ, SWAP, MIN/MAX, ARRAYLEN, then those are good candidates to be
>> part of either a core-language or core-runtime.
> 
> These are not macros in every other C program - you exaggerate.  But
> certainly many programs have things like that.  I'd fully support
> putting them in a standard library ("core-runtime", if you prefer) - I
> am more sceptical about putting them in the core language.
> 
>>
>>> To me, multiple assignment removes the need for a special "swap" feature
>>> for handling common cases.  I would want a "swap" function if it were
>>> designed to handle more complex types (such as handling "deep swaps" of
>>> trees or lists), and there the critical point is that it must be
>>> extendable and overloaded by user code - /not/ a compiler built-in fixed
>>> function.
>>
>> In my languages, swap is not an operator (it doesn't return a value). In
>> the static one, it will work with any compatible flat types, including
>> arrays and structs. In the dynamic one, it will exchange objects of any
>> complexity and depth (in all cases, it means swapping two 16-byte
>> descriptors), and which do not need to be compatible.
>>
>> I can't see the need for a user-overload. If somebody does, then they
>> can create their own swap function. You can't deny everyone else a
>> 'swap' feature because 0.1% of people might want to override it sometime.
> 
> Imagine you have a simple linked list:
> 
> struct list_node;
> struct list_node {
> 	int data;
> 	struct list_node * next;
> };
> typedef struct list_node *list;
> list a, b;
> 
> What should "swap(a, b)" do?

What does a=b do?

You could argue that "=" should be overridable, and in some languages it 
can be. But if those same languages have 'swap' built-in, then you can 
override that too (if you want to obscure what happens when someone 
encounters swap(a,b) in your code).

At the level of C, you can't override "=", its meaning is clear (it does 
a shallow assignment involving the values of a and b) and the same can 
be done for 'swap'.

In C, if you want a=b for those lists to do anything other than copy 
pointers, then you write that other code, or put it in a function. Same 
for 'swap'.

   With a simple direct swap function
> (builtin or otherwise), this will swap the heads of the lists - but not
> the tails.  With a user overrideable swap, the user can write (in a sort
> of "C with references") :
> 
> void swap(list &a, list &b) {
> 	if (!a) {
> 		a = b;
> 		b = NULL;
> 		return;
> 	}
> 	if (!b) {
> 		b = a;
> 		a = NULL;
> 		return;
> 	}
> 
> 	swap(a->data, b->data);
> 	swap(a->next, b->next);
> }
> 
> Then they have a "deep swap".

It's not clear what such a deep swap actually achieves.

If A is the list (10,20,30) and and B is (40,50,60), then you can 
exchange their contents simply by swapping the pointers to the heads of 
each list. Your algorithm will exchange the actual values of each node 
in each list.

Which version is suitable depends on requirements (eg. a pointer to the 
2nd node of A must still point to the 2nd node of A), but usually you 
want to minimise the amount of copying going on.

(C code to demonstrate what happens using your override is given below.)

> This is not denying people a swap feature because some people might want
> to override the standard function - it is giving people the standard
> function /and/ allowing them to override it.  /Everybody/ wins.

You can trivially 'override' by providing a dedicated function. Then a 
reader will also know it will be doing something different.

(In the code below, swapint() and swapptr() represent basic built-in 
swaps that would just be a generic swap() if that was present. 
swaplist() is a dedicated swap for a particular type.)

-------------------------------------------
#include <stdio.h>
#include <stdlib.h>

struct list_node;
struct list_node {
     int data;
     struct list_node * next;
};
typedef struct list_node *list;
list a, b;

void swapint(int* a, int* b){
     int temp;
     temp=*a; *a=*b; *b=temp;
}

void swaplist(list* a, list* b) {
     if (!*a) {
         *a = *b;
         *b = NULL;
         return;
     }
     if (!*b) {
         *b = *a;
         *a = NULL;
         return;
     }

     swapint(&((*a)->data), &((*b)->data));
     swaplist(&(*a)->next, &(*b)->next);
}

void swapptr(void** p, void** q) {
     void* temp;
     temp=*p; *p=*q; *q=temp;
}

list newnode(int a,list next){
     list p;
     p=malloc(sizeof(*p));
     p->data=a;
     p->next=next;
}

void printlist(char* caption,list a){
     printf("%s(",caption);
     while (a) {
         printf("%06X:(%d %06X) ",a,a->data, a->next);
//      printf("(%d %08X) ",a->data, a->next);
         a=a->next;
     }
     printf(")\n");
}

int main(void){
     list a,a1,a2,a3;
     list b,b1,b2,b3;

     a3=newnode(30,0);
     a2=newnode(20,a3);
     a1=newnode(10,a2);
     a=a1;
     b3=newnode(60,0);
     b2=newnode(50,b3);
     b1=newnode(40,b2);
     b=b1;

     printlist("A=",a);
     printlist("B=",b);

     puts("\nAfter 'deep' swap:");

     swaplist(&a,&b);

     printlist("A=",a);
     printlist("B=",b);

     swaplist(&a, &b);

     puts("\nAfter reset:");
     printlist("A=",a);
     printlist("B=",b);

     swapptr(&a, &b);

     puts("\nAfter shallow swap:");
     printlist("A=",a);
     printlist("B=",b);
}
-------------------------------------------

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