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

Groups > comp.lang.c > #168839 > unrolled thread

structs passed by copy

Back to article view | Back to comp.lang.c

Contents

  structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-20 10:41 -0800
    Re: structs passed by copy gazelle@shell.xmission.com (Kenny McCormack) - 2023-01-20 19:01 +0000
      Re: structs passed by copy Anton Shepelev <anton.txt@gmail.com> - 2023-01-20 23:01 +0300
        Re: structs passed by copy gazelle@shell.xmission.com (Kenny McCormack) - 2023-01-20 21:28 +0000
          Re: structs passed by copy Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-21 09:14 +0000
          Re: structs passed by copy Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2023-01-21 10:58 -0700
            Re: structs passed by copy gazelle@shell.xmission.com (Kenny McCormack) - 2023-01-21 18:00 +0000
            Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-21 16:14 -0800
              Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-22 16:00 -0500
                Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 13:07 -0800
                Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-22 13:27 -0800
                  Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 13:51 -0800
                    Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 13:51 -0800
                  Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-22 17:11 -0500
                    Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-22 16:01 -0800
                      Re: structs passed by copy Richard Damon <Richard@Damon-Family.org> - 2023-01-22 21:22 -0500
                      Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-01-23 10:46 +0100
                        Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-23 12:15 -0800
                          Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-01-23 21:47 +0100
                            Re: structs passed by copy Michael S <already5chosen@yahoo.com> - 2023-01-23 13:21 -0800
                              Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-23 23:49 +0000
                                Re: structs passed by copy Michael S <already5chosen@yahoo.com> - 2023-01-24 02:46 -0800
                                  Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 04:18 -0800
                                    Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 04:45 -0800
                                      Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 04:54 -0800
                                        Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 05:26 -0800
                                          Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 05:38 -0800
                                            Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 05:53 -0800
                                              Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 06:20 -0800
                                                Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 06:56 -0800
                                                  Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 07:17 -0800
                                  Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-24 12:56 +0000
                                    Re: structs passed by copy Michael S <already5chosen@yahoo.com> - 2023-01-24 07:29 -0800
                      Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-23 15:44 -0800
                        Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-23 16:37 -0800
                          Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-23 20:13 -0500
                            Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-23 17:58 -0800
                          Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-24 07:53 -0800
                            Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-24 11:14 -0800
                              Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-24 12:02 -0800
                                Re: structs passed by copy Phil Carmody <pc+usenet@asdf.org> - 2023-01-25 10:18 +0200
                                  Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-25 10:53 -0800
                                    Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-29 13:30 -0800
                                      Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-29 17:42 -0800
                                        Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-17 07:19 -0800
                                          Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-17 09:35 -0800
                                      Re: structs passed by copy John Forkosh <forkosh@panix.com> - 2023-01-30 04:24 +0000
                                        Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-29 21:10 -0800
                                        Re: structs passed by copy Michael S <already5chosen@yahoo.com> - 2023-01-30 13:55 -0800
                                        Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-17 05:57 -0800
        Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-21 05:00 -0500
          Re: structs passed by copy Anton Shepelev <anton.txt@gmail.com> - 2023-01-21 23:00 +0300
            Re: structs passed by copy Richard Damon <Richard@Damon-Family.org> - 2023-01-21 17:10 -0500
      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-20 18:12 -0800
      Re: structs passed by copy antispam@math.uni.wroc.pl - 2023-01-21 02:28 +0000
    Re: structs passed by copy Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-01-20 14:09 -0500
      Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-20 11:26 -0800
    Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-20 11:22 -0800
    Re: structs passed by copy Bart <bc@freeuk.com> - 2023-01-20 20:16 +0000
      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-20 19:16 -0800
        Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-20 21:08 -0800
        Re: structs passed by copy Bart <bc@freeuk.com> - 2023-01-21 13:30 +0000
          Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 10:27 -0800
    Re: structs passed by copy Richard Damon <Richard@Damon-Family.org> - 2023-01-20 21:35 -0500
    Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-20 19:01 -0800
      Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-21 17:01 -0800
    Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-01-21 14:59 +0100
    Re: structs passed by copy Opus <ifonly@youknew.org> - 2023-01-21 19:59 +0100
    Re: structs passed by copy Michael S <already5chosen@yahoo.com> - 2023-01-21 16:55 -0800
      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-22 02:32 -0800
        Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-22 15:54 +0000
          Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 09:17 -0800
            Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 09:56 -0800
              Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 10:19 -0800
                Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 11:01 -0800
                  Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 11:08 -0800
                    Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 11:17 -0800
                    Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 13:27 -0800
          Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 13:04 -0800
            Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-22 21:43 +0000
              Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 14:10 -0800
                Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-22 22:29 +0000
                  Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 14:39 -0800
                  Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-22 19:06 -0800
                    Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-01-23 10:54 +0100
          Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-22 19:00 -0800
            Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-23 12:14 +0000
    Re: structs passed by copy Jorgen Grahn <grahn+nntp@snipabacken.se> - 2023-02-11 19:35 +0000
      Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-11 15:08 -0800
        Re: structs passed by copy Öö Tiib <ootiib@hot.ee> - 2023-02-11 15:56 -0800
          Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-11 16:32 -0800
            Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-12 01:23 -0500
              Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-12 11:24 +0100
                Re: structs passed by copy Vir Campestris <vir.campestris@invalid.invalid> - 2023-02-12 22:11 +0000
                  Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-13 10:25 +0100
                    Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-02-13 06:41 -0800
                      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-02-13 06:50 -0800
                        Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-13 17:22 +0100
                          Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-02-13 10:47 -0800
                            Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-13 21:50 +0100
                              Re: structs passed by copy bart c <bart4858@gmail.com> - 2023-02-15 17:14 -0800
                                Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-16 10:53 +0100
                                  Re: structs passed by copy scott@slp53.sl.home (Scott Lurndal) - 2023-02-16 15:22 +0000
              Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-12 11:04 -0800
            Re: structs passed by copy Öö Tiib <ootiib@hot.ee> - 2023-02-12 12:41 -0800
            Re: structs passed by copy Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-16 22:49 -0800
        Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-02-11 17:49 -0800
        Grammar nitpick (Was: structs passed by copy) gazelle@shell.xmission.com (Kenny McCormack) - 2023-02-12 06:30 +0000
        Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-06 09:32 -0800
          Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-06 09:58 -0800
            Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-06 11:30 -0800
              Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-06 12:59 -0800
      Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-15 01:52 -0800
        Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-02-16 05:20 -0800
          Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-16 16:49 +0100
          Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-26 08:12 -0800
            Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-02-28 05:38 -0800
              Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-28 14:18 -0800
                Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-03-01 05:02 -0800
                  Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-01 10:23 -0800
                    Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-01 10:42 -0800
                    Re: structs passed by copy bart c <bart4858@gmail.com> - 2023-03-01 15:13 -0800
                      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-03-02 04:17 -0800
                      Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-03-05 04:17 -0800
                        Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-03-05 04:55 -0800
                    Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-03-02 10:48 +0100
                      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-03-02 04:07 -0800
                        Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-03-02 15:08 +0100
                          Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-03-02 09:22 -0800
                Re: structs passed by copy gazelle@shell.xmission.com (Kenny McCormack) - 2023-03-01 13:34 +0000
                  Re: structs passed by copy Richard Damon <Richard@Damon-Family.org> - 2023-03-01 21:42 -0500
              Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-06 09:36 -0800
    Re: structs passed by copy Maciej Zelma <maciej.projectmanager@gmail.com> - 2023-02-17 14:10 -0800
      Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-17 15:45 -0800
        Re: structs passed by copy scott@slp53.sl.home (Scott Lurndal) - 2023-02-18 00:12 +0000
          Re: structs passed by copy bart c <bart4858@gmail.com> - 2023-02-18 02:33 -0800
      Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-18 00:44 -0500
        Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-17 22:21 -0800
    Re: structs passed by copy Bonita Montero <Bonita.Montero@gmail.com> - 2023-03-01 18:00 +0100
      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-03-01 09:18 -0800
        Re: structs passed by copy Bonita Montero <Bonita.Montero@gmail.com> - 2023-03-05 14:05 +0100

Page 1 of 8  [1] 2 3 4 5 6 7 8  Next page →

#168839 — structs passed by copy

At first edition of "The C programming language" we can see
that structs could not be passed directly as function arguments.
They also could not be returned from functions and assigned.

Soon after [1], the language changed to allow assignment and make
structs arguments passed by copy by default.

Today, I have 0% of structs being passed by copy in my code.
So for me this is a very bad default.

If structs where passed by reference this would not be the only
exception  on the type system because arrays are already passed
as pointers.

Do  you have structs passed by copy in your code?
Could it be replaced by const * ?
Considering your answer would you agree with me that this is a bad default?

Returning function by copy is common in my code.

[1]
https://www.bell-labs.com/usr/dmr/www/cchanges.pdf

[toc] | [next] | [standalone]

#168840

In article <76ec6d87-0f5d-4671-b4c8-7023e3da787an@googlegroups.com>,
Thiago Adams  <thiago.adams@gmail.com> wrote:
>At first edition of "The C programming language" we can see
>that structs could not be passed directly as function arguments.
>They also could not be returned from functions and assigned.
>
>Soon after [1], the language changed to allow assignment and make
>structs arguments passed by copy by default.
>
>Today, I have 0% of structs being passed by copy in my code.
>So for me this is a very bad default.

Two comments:
    1) I never really understood *why* they changed the language to allow
	structs to be passed as actual objects.  Anyone care to comment?
    2) The usual method for passing structs around is to pass a pointer to
	the struct.  That works just fine in all cases and, thus, as above,
	I don't understand why the change.

Like you, I've never needed (or used) this ability in my code, so have not
ever used it.  I wonder if it came about because they made some other
changes (enhancements) in what you could legally do with a struct, and this
ended up coming for free.

P.S.  I actually do kinda like the idea that you can pass an array "by
value" (should you want/need to do that) by wrapping the array inside a
struct and passing the struct.  A cute hack that could prove useful some
sunny day...

-- 
"We should always be disposed to believe that which appears to us to be
white is really black, if the hierarchy  of the church so decides." 

    - Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -

[toc] | [prev] | [next] | [standalone]

#168844

Kenny McCormack:

> I never really understood *why* they changed the language
> to allow structs to be passed as actual objects.  Anyone
> care to comment?

Integers, floats, and doubles can be passed by value.  If I
were to implement complex numbers, I should do it as a
struct with a .re (real) and .im (imaginary) fields.  I
should want to pass it by value whenever I pass real types
by value.

-- 
()  ascii ribbon campaign -- against html e-mail 
/\  www.asciiribbon.org   -- against proprietary attachments

[toc] | [prev] | [next] | [standalone]

#168846

In article <20230120230138.1225d36e5ad8e5f07401c67a@gmail.com>,
Anton Shepelev  <anton.txt@gmail.com> wrote:
>Kenny McCormack:
>
>> I never really understood *why* they changed the language
>> to allow structs to be passed as actual objects.  Anyone
>> care to comment?
>
>Integers, floats, and doubles can be passed by value.  If I
>were to implement complex numbers, I should do it as a
>struct with a .re (real) and .im (imaginary) fields.  I
>should want to pass it by value whenever I pass real types
>by value.

I get that, for symmetry's sake and all, but wouldn't it be just as easy to
pass the address of your struct?  Like we do with most of the structs that
get passed to Unix API calls (e.g., stat(2)).

By the way, didn't they already add complex numbers to the standard,
somewhere along the way?  Having never used them, I can't remember, off
hand, how they are implemented.

-- 
Joni Ernst (2014): Obama should be impeached because 2 people have died of Ebola.
Joni Ernst (2020): Trump is doing great things, because only 65,000 times as many people have died of COVID-19.

Josef Stalin (1947): When one person dies, it is a tragedy; when a million die, it is merely statistics.

[toc] | [prev] | [next] | [standalone]

#168853

On 2023-01-20, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> I get that, for symmetry's sake and all, but wouldn't it be just as easy to
> pass the address of your struct?  Like we do with most of the structs that
> get passed to Unix API calls (e.g., stat(2)).

In fact, passing a structure by value can be implemented by a hidden
pointer. Compilers do that at their discretion; it may be based on how
large the structure is and other factors.

The important thing is the semantics. In C, you can modify an argument
without affecting the caller; the understanding is that the object is
a local copy.

One big reason for passing a structure by value is that you want to 
be able to mutate the copy, and to do that conveniently without
a dance like this:

   void fun(struct obj *ptr)
   {
      struct obj local = *ptr;
      // work with local
      local.counter++;
      // ...
   }

It just just becomes

   void fun(struct obj local)
   {
      local.counter++;
      // ...
   }

Even if you don't need the copy, there is less syntax. No pointer
declarator in the parameter, and just dot referencing instead of ->.

Moreover, you don't have to use the & operator to prepare the
argument;

   void fun(struct obj local)
   {
      do_this(local.foo, local.bar);
   }

   //

   struct obj x;
   //
   fun(x);

versus

   void fun(struct obj *local)     // noise here
   {
      do_this(local->foo, local->bar); // more noise here
   }

   //

   struct obj x;
   //
   fun(&x); // noise here

There is more freedom to generate code for the by-value situation in
different ways. The pointer version basically specifies what the
implementation is, whereas the by-value version could use a pointer,
whereby callee copies the struct if necessary, or have the caller make
the copy, passing a pointer to the callee, or have the caller make an
actual stack copy that the callee finds at a fixed offset in the
parameter space. One strategy could be used for large structures,
another for small structures.

Thus, when you write the noise-free, clean version with by-value
passing, it can easily have the same efficiency as the explicit pointer
version, with as little actual data copying.

For small structures, you could actually be making the program less
efficient by passing a pointer. If you have a complex number
represented as a structure holding two doubles, when that is passed
by value, it could acctually be passed using the same mechanism
as if it were two arguments of type double. E.g. two registers.

And when the callee accesses "arg.real" and "arg.imag", that could
actually be compiled to just referring to those registers.

Whereas code that does arg->real might not have that pointer
optimized away at all.

Another consideration is that the recipent of a by-value struct
argument (no matter how the passage is implemented) has the
guarantee that it's a local. If the callee doesn't lift the
address of that local with the & operator, then it is guaranteed
that nothing else in the program has the address of the object;
and thus no function which it uses needs to be suspected of
modifying the object.

Pointer version:

  void fun(const struct complex_number *pcplx)
  {
    double dr = other_fun_1(pcplx->real);
    double di = other_fun_2(pcplx->real + pcplx->imag);
  }

Here although the structure is marked "const", we have no idea
where the pointer came form and who else has that pointer.
When the other_fun_1 is called, and is an external function about which
we know nothing, it has to be assumed that it has access to that object
and can modify it.  Thus the second evaluation of pcplx->real has to
re-load that member through the pointer. It cannot just re-use thue
previously loaded pcplx->real value.

There is no such threat under by-value:


  void fun(const struct complex_number cplx)
  {
    double dr = other_fun_1(cplx.real);
    double di = other_fun_2(cplx.real + cplx.imag);
  }

The call to other_fun_1 cannot possibly change the value of
cplx.real; the compiler can put that into a register,
which doesn't have to be spilled and reloaded across
calls to external functions.

The pointer version could be optimized similarly if we
could convince the compiler that the object cannot
be modified. E.g. the members themselves could
be const-qualified types:

  struct complex_number { const double real, imag; };

That's going to create hassles.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#168857

gazelle@shell.xmission.com (Kenny McCormack) writes:
>
> By the way, didn't they already add complex numbers to the standard,
> somewhere along the way?  Having never used them, I can't remember, off
> hand, how they are implemented.

Yes, though that doesn't really affect the example.

I first learned about complex numbers in C when I typoed something like
5i when I meant 5+i and was very, very confused for a while.

[toc] | [prev] | [next] | [standalone]

#168858

In article <1btu0jojlm.fsf@pfeifferfamily.net>,
Joe Pfeiffer  <pfeiffer@cs.nmsu.edu> wrote:
>gazelle@shell.xmission.com (Kenny McCormack) writes:
>>
>> By the way, didn't they already add complex numbers to the standard,
>> somewhere along the way?  Having never used them, I can't remember, off
>> hand, how they are implemented.
>
>Yes, though that doesn't really affect the example.

Agreed.

>I first learned about complex numbers in C when I typoed something like
>5i when I meant 5+i and was very, very confused for a while.

Interesting.

-- 
I'll give him credit for one thing: He is (& will be) the most quotable President
ever.  Books have been written about (GW) Bushisms, but Dubya's got nothing on Trump.

    Tremendously wet - from the standpoint of water.

[toc] | [prev] | [next] | [standalone]

#168862

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
[...]
> I first learned about complex numbers in C when I typoed something like
> 5i when I meant 5+i and was very, very confused for a while.

5i is an imaginary constant, a gcc-specific extension.  It's a syntax
error in standard C.

gcc imaginary constants are of complex type.  The standard defines
optional support for imaginary types in Annex G, but I don't know
of any compiler that supports them (or how they'd be useful).

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#168885

On 1/21/23 19:14, Keith Thompson wrote:
> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> [...]
>> I first learned about complex numbers in C when I typoed something like
>> 5i when I meant 5+i and was very, very confused for a while.
>
> 5i is an imaginary constant, a gcc-specific extension. It's a syntax
> error in standard C.
>
> gcc imaginary constants are of complex type. The standard defines
> optional support for imaginary types in Annex G, but I don't know
> of any compiler that supports them (or how they'd be useful).

Just as it is extremely common for numbers to be pure-real, with no
imaginary part, it is not uncommon, when doing physics or engineering
using complex values, to have some of those quantities being calculated
to be guaranteed to be pure imaginary. Storing such quantities using
_Imaginary types reduces the space required by a factor of 2, which can
be important if you have huge arrays of them (not an uncommon feature of
physics/engineering programs). More importantly, I think, is that use of
such types should enable warnings about questionable uses of such types,
such as taking the Real part of them.

It's certainly not impossible to work with such quantities efficiently
without using the _Imaginary types - before the introduction of those
types, they could have been stored as real values, with a comment
indicating that these real values are the imaginary component of the
actual value. However, making _Imaginary a part of the declaration of
such objects is better than relying upon people to notice such a comment.

[toc] | [prev] | [next] | [standalone]

#168887

On 1/22/2023 1:00 PM, James Kuyper wrote:
> On 1/21/23 19:14, Keith Thompson wrote:
>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>> [...]
>>> I first learned about complex numbers in C when I typoed something like
>>> 5i when I meant 5+i and was very, very confused for a while.
>>
>> 5i is an imaginary constant, a gcc-specific extension. It's a syntax
>> error in standard C.
>>
>> gcc imaginary constants are of complex type. The standard defines
>> optional support for imaginary types in Annex G, but I don't know
>> of any compiler that supports them (or how they'd be useful).
> 
> Just as it is extremely common for numbers to be pure-real, with no
> imaginary part, it is not uncommon, when doing physics or engineering
> using complex values, to have some of those quantities being calculated
> to be guaranteed to be pure imaginary. Storing such quantities using
> _Imaginary types reduces the space required by a factor of 2, which can
> be important if you have huge arrays of them (not an uncommon feature of
> physics/engineering programs). More importantly, I think, is that use of
> such types should enable warnings about questionable uses of such types,
> such as taking the Real part of them.

0+2i

The real part is zero, the imaginary part is 2i. Taking the real part of 
2i should be zero.


> 
> It's certainly not impossible to work with such quantities efficiently
> without using the _Imaginary types - before the introduction of those
> types, they could have been stored as real values, with a comment
> indicating that these real values are the imaginary component of the
> actual value. However, making _Imaginary a part of the declaration of
> such objects is better than relying upon people to notice such a comment.
> 
> 

[toc] | [prev] | [next] | [standalone]

#168889

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 1/21/23 19:14, Keith Thompson wrote:
>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>> [...]
>>> I first learned about complex numbers in C when I typoed something like
>>> 5i when I meant 5+i and was very, very confused for a while.
>>
>> 5i is an imaginary constant, a gcc-specific extension. It's a syntax
>> error in standard C.
>>
>> gcc imaginary constants are of complex type. The standard defines
>> optional support for imaginary types in Annex G, but I don't know
>> of any compiler that supports them (or how they'd be useful).
>
> Just as it is extremely common for numbers to be pure-real, with no
> imaginary part, it is not uncommon, when doing physics or engineering
> using complex values, to have some of those quantities being calculated
> to be guaranteed to be pure imaginary. Storing such quantities using
> _Imaginary types reduces the space required by a factor of 2, which can
> be important if you have huge arrays of them (not an uncommon feature of
> physics/engineering programs). More importantly, I think, is that use of
> such types should enable warnings about questionable uses of such types,
> such as taking the Real part of them.
>
> It's certainly not impossible to work with such quantities efficiently
> without using the _Imaginary types - before the introduction of those
> types, they could have been stored as real values, with a comment
> indicating that these real values are the imaginary component of the
> actual value. However, making _Imaginary a part of the declaration of
> such objects is better than relying upon people to notice such a comment.

Thanks, I didn't know that.

Given that imaginary types are useful, I wonder why they're not
widely supported.  Neither gcc 12.2.0 nor clang 15.0.0 supports
`_Imaginary double`.

And both predefine __STDC_IEC_559_COMPLEX__, which if I'm reading
Annex G correctly implies that they're required to support imaginary
types.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#168894

On 1/22/2023 1:27 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 1/21/23 19:14, Keith Thompson wrote:
>>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>> [...]
>>>> I first learned about complex numbers in C when I typoed something like
>>>> 5i when I meant 5+i and was very, very confused for a while.
>>>
>>> 5i is an imaginary constant, a gcc-specific extension. It's a syntax
>>> error in standard C.
>>>
>>> gcc imaginary constants are of complex type. The standard defines
>>> optional support for imaginary types in Annex G, but I don't know
>>> of any compiler that supports them (or how they'd be useful).
>>
>> Just as it is extremely common for numbers to be pure-real, with no
>> imaginary part, it is not uncommon, when doing physics or engineering
>> using complex values, to have some of those quantities being calculated
>> to be guaranteed to be pure imaginary. Storing such quantities using
>> _Imaginary types reduces the space required by a factor of 2, which can
>> be important if you have huge arrays of them (not an uncommon feature of
>> physics/engineering programs). More importantly, I think, is that use of
>> such types should enable warnings about questionable uses of such types,
>> such as taking the Real part of them.
>>
>> It's certainly not impossible to work with such quantities efficiently
>> without using the _Imaginary types - before the introduction of those
>> types, they could have been stored as real values, with a comment
>> indicating that these real values are the imaginary component of the
>> actual value. However, making _Imaginary a part of the declaration of
>> such objects is better than relying upon people to notice such a comment.
> 
> Thanks, I didn't know that.
> 
> Given that imaginary types are useful, I wonder why they're not
> widely supported.  Neither gcc 12.2.0 nor clang 15.0.0 supports
> `_Imaginary double`.
> 
> And both predefine __STDC_IEC_559_COMPLEX__, which if I'm reading
> Annex G correctly implies that they're required to support imaginary
> types.
> 

Fwiw, when you get some free time to burn, check out some of my 
experimental fractal code here, using complex types in c99:
_______________________________
double complex
ct_project_to_xy(
     struct ct_plot* const self,
     long x,
     long y
){
     double complex p =
         (self->plane.axes.xmin + x * self->plane.xstep) +
         (self->plane.axes.ymax - y * self->plane.ystep) * I;

     return p;
}
_______________________________


0+1*I

Is the pure imaginary normalized unit.

[toc] | [prev] | [next] | [standalone]

#168895

On 1/22/2023 1:51 PM, Chris M. Thomasson wrote:
> On 1/22/2023 1:27 PM, Keith Thompson wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>> On 1/21/23 19:14, Keith Thompson wrote:
>>>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>>> [...]
>>>>> I first learned about complex numbers in C when I typoed something 
>>>>> like
>>>>> 5i when I meant 5+i and was very, very confused for a while.
>>>>
>>>> 5i is an imaginary constant, a gcc-specific extension. It's a syntax
>>>> error in standard C.
>>>>
>>>> gcc imaginary constants are of complex type. The standard defines
>>>> optional support for imaginary types in Annex G, but I don't know
>>>> of any compiler that supports them (or how they'd be useful).
>>>
>>> Just as it is extremely common for numbers to be pure-real, with no
>>> imaginary part, it is not uncommon, when doing physics or engineering
>>> using complex values, to have some of those quantities being calculated
>>> to be guaranteed to be pure imaginary. Storing such quantities using
>>> _Imaginary types reduces the space required by a factor of 2, which can
>>> be important if you have huge arrays of them (not an uncommon feature of
>>> physics/engineering programs). More importantly, I think, is that use of
>>> such types should enable warnings about questionable uses of such types,
>>> such as taking the Real part of them.
>>>
>>> It's certainly not impossible to work with such quantities efficiently
>>> without using the _Imaginary types - before the introduction of those
>>> types, they could have been stored as real values, with a comment
>>> indicating that these real values are the imaginary component of the
>>> actual value. However, making _Imaginary a part of the declaration of
>>> such objects is better than relying upon people to notice such a 
>>> comment.
>>
>> Thanks, I didn't know that.
>>
>> Given that imaginary types are useful, I wonder why they're not
>> widely supported.  Neither gcc 12.2.0 nor clang 15.0.0 supports
>> `_Imaginary double`.
>>
>> And both predefine __STDC_IEC_559_COMPLEX__, which if I'm reading
>> Annex G correctly implies that they're required to support imaginary
>> types.
>>
> 
> Fwiw, when you get some free time to burn, check out some of my 
> experimental fractal code here, using complex types in c99:

Forgot to link to the damn code!

https://pastebin.com/raw/07TWQQYF

Sorry about that. ;^o



> _______________________________
> double complex
> ct_project_to_xy(
>      struct ct_plot* const self,
>      long x,
>      long y
> ){
>      double complex p =
>          (self->plane.axes.xmin + x * self->plane.xstep) +
>          (self->plane.axes.ymax - y * self->plane.ystep) * I;
> 
>      return p;
> }
> _______________________________
> 
> 
> 0+1*I
> 
> Is the pure imaginary normalized unit.

[toc] | [prev] | [next] | [standalone]

#168898

On 1/22/23 16:27, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
...
>> Just as it is extremely common for numbers to be pure-real, with no
>> imaginary part, it is not uncommon, when doing physics or engineering
>> using complex values, to have some of those quantities being calculated
>> to be guaranteed to be pure imaginary. Storing such quantities using
>> _Imaginary types reduces the space required by a factor of 2, which can
>> be important if you have huge arrays of them (not an uncommon feature of
>> physics/engineering programs). More importantly, I think, is that use of
>> such types should enable warnings about questionable uses of such types,
>> such as taking the Real part of them.
>>
>> It's certainly not impossible to work with such quantities efficiently
>> without using the _Imaginary types - before the introduction of those
>> types, they could have been stored as real values, with a comment
>> indicating that these real values are the imaginary component of the
>> actual value. However, making _Imaginary a part of the declaration of
>> such objects is better than relying upon people to notice such a comment.
>
> Thanks, I didn't know that.
>
> Given that imaginary types are useful, I wonder why they're not
> widely supported. Neither gcc 12.2.0 nor clang 15.0.0 supports
> `_Imaginary double`.
>
> And both predefine __STDC_IEC_559_COMPLEX__, which if I'm reading
> Annex G correctly implies that they're required to support imaginary
> types.

I said that they could be useful. I didn't address how useful they would
be. I don't imagine that the usefulness is great. I hope the committee
had some evidence of actual demand for such a feature before deciding to
add it to the language.

[toc] | [prev] | [next] | [standalone]

#168903

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 1/22/23 16:27, Keith Thompson wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> ...
>>> Just as it is extremely common for numbers to be pure-real, with no
>>> imaginary part, it is not uncommon, when doing physics or engineering
>>> using complex values, to have some of those quantities being calculated
>>> to be guaranteed to be pure imaginary. Storing such quantities using
>>> _Imaginary types reduces the space required by a factor of 2, which can
>>> be important if you have huge arrays of them (not an uncommon feature of
>>> physics/engineering programs). More importantly, I think, is that use of
>>> such types should enable warnings about questionable uses of such types,
>>> such as taking the Real part of them.
>>>
>>> It's certainly not impossible to work with such quantities efficiently
>>> without using the _Imaginary types - before the introduction of those
>>> types, they could have been stored as real values, with a comment
>>> indicating that these real values are the imaginary component of the
>>> actual value. However, making _Imaginary a part of the declaration of
>>> such objects is better than relying upon people to notice such a comment.
>>
>> Thanks, I didn't know that.
>>
>> Given that imaginary types are useful, I wonder why they're not
>> widely supported. Neither gcc 12.2.0 nor clang 15.0.0 supports
>> `_Imaginary double`.
>>
>> And both predefine __STDC_IEC_559_COMPLEX__, which if I'm reading
>> Annex G correctly implies that they're required to support imaginary
>> types.

I was wrong about this; see below.

> I said that they could be useful. I didn't address how useful they would
> be. I don't imagine that the usefulness is great. I hope the committee
> had some evidence of actual demand for such a feature before deciding to
> add it to the language.

There are still a few things I'm curious about:

Why did the committee choose to make complex numbers mandatory and
imaginary numbers optional?  I wouldn't expect imaginary numbers
to be very difficult to implement once you have complex numbers.
Nor would I expect users of one C implementation to have a greater
need for them than users of another (which would have been a
reasonable basis for making them optional).

Have any C compilers implemented _Imaginary?  (If not, it seems
like a failed experiment.)

A minor note: N1256 (C99) has a footnote in 7.3 referring
to "informative annex G".  N1570 (C11) has the same footnote.
But Annex G is informative in C99, normative in C11.

BTW, I was wrong about one thing: Support for _Imaginary is optional
even for an implementation that predefines __STDC_IEC_559_COMPLEX__.
`#ifdef _Imaginary_I` can be used to detect whether an implementation
supports imaginary types.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#168910

On 1/22/23 7:01 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 1/22/23 16:27, Keith Thompson wrote:
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> ...
>>>> Just as it is extremely common for numbers to be pure-real, with no
>>>> imaginary part, it is not uncommon, when doing physics or engineering
>>>> using complex values, to have some of those quantities being calculated
>>>> to be guaranteed to be pure imaginary. Storing such quantities using
>>>> _Imaginary types reduces the space required by a factor of 2, which can
>>>> be important if you have huge arrays of them (not an uncommon feature of
>>>> physics/engineering programs). More importantly, I think, is that use of
>>>> such types should enable warnings about questionable uses of such types,
>>>> such as taking the Real part of them.
>>>>
>>>> It's certainly not impossible to work with such quantities efficiently
>>>> without using the _Imaginary types - before the introduction of those
>>>> types, they could have been stored as real values, with a comment
>>>> indicating that these real values are the imaginary component of the
>>>> actual value. However, making _Imaginary a part of the declaration of
>>>> such objects is better than relying upon people to notice such a comment.
>>>
>>> Thanks, I didn't know that.
>>>
>>> Given that imaginary types are useful, I wonder why they're not
>>> widely supported. Neither gcc 12.2.0 nor clang 15.0.0 supports
>>> `_Imaginary double`.
>>>
>>> And both predefine __STDC_IEC_559_COMPLEX__, which if I'm reading
>>> Annex G correctly implies that they're required to support imaginary
>>> types.
> 
> I was wrong about this; see below.
> 
>> I said that they could be useful. I didn't address how useful they would
>> be. I don't imagine that the usefulness is great. I hope the committee
>> had some evidence of actual demand for such a feature before deciding to
>> add it to the language.
> 
> There are still a few things I'm curious about:
> 
> Why did the committee choose to make complex numbers mandatory and
> imaginary numbers optional?  I wouldn't expect imaginary numbers
> to be very difficult to implement once you have complex numbers.
> Nor would I expect users of one C implementation to have a greater
> need for them than users of another (which would have been a
> reasonable basis for making them optional).
> 
> Have any C compilers implemented _Imaginary?  (If not, it seems
> like a failed experiment.)
> 
> A minor note: N1256 (C99) has a footnote in 7.3 referring
> to "informative annex G".  N1570 (C11) has the same footnote.
> But Annex G is informative in C99, normative in C11.
> 
> BTW, I was wrong about one thing: Support for _Imaginary is optional
> even for an implementation that predefines __STDC_IEC_559_COMPLEX__.
> `#ifdef _Imaginary_I` can be used to detect whether an implementation
> supports imaginary types.
> 

My guess, and it is just a guess, is that while adding support of 
imaginary isn't "hard", it does add a moderate amount of code to the 
library if you want things like + and * to stay reasonably efficient in 
the mixed type cases.

Since the use case of imaginary only numbers is somewhat limited, making 
it optional might well significantly increase the number of 
implementatios willing to support the complex type.

[toc] | [prev] | [next] | [standalone]

#168920

On 23/01/2023 01:01, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 1/22/23 16:27, Keith Thompson wrote:
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> ...
>>>> Just as it is extremely common for numbers to be pure-real, with no
>>>> imaginary part, it is not uncommon, when doing physics or engineering
>>>> using complex values, to have some of those quantities being calculated
>>>> to be guaranteed to be pure imaginary. Storing such quantities using
>>>> _Imaginary types reduces the space required by a factor of 2, which can
>>>> be important if you have huge arrays of them (not an uncommon feature of
>>>> physics/engineering programs). More importantly, I think, is that use of
>>>> such types should enable warnings about questionable uses of such types,
>>>> such as taking the Real part of them.
>>>>
>>>> It's certainly not impossible to work with such quantities efficiently
>>>> without using the _Imaginary types - before the introduction of those
>>>> types, they could have been stored as real values, with a comment
>>>> indicating that these real values are the imaginary component of the
>>>> actual value. However, making _Imaginary a part of the declaration of
>>>> such objects is better than relying upon people to notice such a comment.
>>>
>>> Thanks, I didn't know that.
>>>
>>> Given that imaginary types are useful, I wonder why they're not
>>> widely supported. Neither gcc 12.2.0 nor clang 15.0.0 supports
>>> `_Imaginary double`.
>>>
>>> And both predefine __STDC_IEC_559_COMPLEX__, which if I'm reading
>>> Annex G correctly implies that they're required to support imaginary
>>> types.
> 
> I was wrong about this; see below.
> 
>> I said that they could be useful. I didn't address how useful they would
>> be. I don't imagine that the usefulness is great. I hope the committee
>> had some evidence of actual demand for such a feature before deciding to
>> add it to the language.
> 
> There are still a few things I'm curious about:
> 
> Why did the committee choose to make complex numbers mandatory and
> imaginary numbers optional?  I wouldn't expect imaginary numbers
> to be very difficult to implement once you have complex numbers.
> Nor would I expect users of one C implementation to have a greater
> need for them than users of another (which would have been a
> reasonable basis for making them optional).
> 

I also wonder why the committee choose to make complex numbers mandatory 
in C99, then optional in C11.  Complex numbers are not particularly hard 
to implement (once you have all the rest of floating point support and 
<math.h>), and on the user side they are zero cost if you don't use them.

> Have any C compilers implemented _Imaginary?  (If not, it seems
> like a failed experiment.)
> 

I note that C++ does not have a standard library "imaginary" type 
either.  I suppose there simply hasn't been much call for such a type in 
practice - you can always handle them yourself using real types, as long 
as you are careful about usage in expressions.  (And in C++, you could 
easily make a wrapper class so you don't have to be careful!)

[toc] | [prev] | [next] | [standalone]

#168939

David Brown <david.brown@hesbynett.no> writes:
[...]
> I also wonder why the committee choose to make complex numbers
> mandatory in C99, then optional in C11.  Complex numbers are not
> particularly hard to implement (once you have all the rest of floating
> point support and <math.h>), and on the user side they are zero cost
> if you don't use them.

I had forgotten that C11 made complex numbers optional.  I agree that it
was an odd decision, as was making VLAs optional.

Making a feature optional could be a good first step towards making it
mandatory in a future edition of the standard.  Making an existing
mandatory feature optional makes less sense to me.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#168943

On 23/01/2023 21:15, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> I also wonder why the committee choose to make complex numbers
>> mandatory in C99, then optional in C11.  Complex numbers are not
>> particularly hard to implement (once you have all the rest of floating
>> point support and <math.h>), and on the user side they are zero cost
>> if you don't use them.
> 
> I had forgotten that C11 made complex numbers optional.  I agree that it
> was an odd decision, as was making VLAs optional.
> 
> Making a feature optional could be a good first step towards making it
> mandatory in a future edition of the standard.  Making an existing
> mandatory feature optional makes less sense to me.
> 

Could it have been pressure from a certain major compiler manufacturer 
who has been extremely slow at implementing some C99 features, other 
than those that were also part of C++ ?  Perhaps they wanted to change 
their reputation of being poor at C because they were far from C99 
compliant, and they could now get C11 compliance with less effort.


Or maybe that's just a conspiracy theory :-)

[toc] | [prev] | [next] | [standalone]

#168946

On Monday, January 23, 2023 at 10:47:45 PM UTC+2, David Brown wrote:
> On 23/01/2023 21:15, Keith Thompson wrote: 
> > David Brown <david...@hesbynett.no> writes: 
> > [...] 
> >> I also wonder why the committee choose to make complex numbers 
> >> mandatory in C99, then optional in C11. Complex numbers are not 
> >> particularly hard to implement (once you have all the rest of floating 
> >> point support and <math.h>), and on the user side they are zero cost 
> >> if you don't use them. 
> > 
> > I had forgotten that C11 made complex numbers optional. I agree that it 
> > was an odd decision, as was making VLAs optional. 
> > 
> > Making a feature optional could be a good first step towards making it 
> > mandatory in a future edition of the standard. Making an existing 
> > mandatory feature optional makes less sense to me. 
> >
> Could it have been pressure from a certain major compiler manufacturer 
> who has been extremely slow at implementing some C99 features, other 
> than those that were also part of C++ ? Perhaps they wanted to change 
> their reputation of being poor at C because they were far from C99 
> compliant, and they could now get C11 compliance with less effort. 
> 
> 
> Or maybe that's just a conspiracy theory :-)

I'd guess, that's part of the reason.
The other part is desire to make 'C' maximally close to a subset of C++.

[toc] | [prev] | [next] | [standalone]

Page 1 of 8  [1] 2 3 4 5 6 7 8  Next page →

Back to top | Article view | comp.lang.c

csiph-web