Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #384414 > unrolled thread
| Started by | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| First post | 2024-04-29 19:13 +0300 |
| Last post | 2024-04-30 16:48 +0000 |
| Articles | 20 on this page of 100 — 13 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-29 19:13 +0300
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-04-29 20:29 +0000
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-29 13:33 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-04-29 22:41 +0000
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-29 16:46 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-04-30 00:11 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 06:54 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 07:10 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 10:13 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 08:53 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 10:59 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 20:34 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-02 05:45 +0200
Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-02 15:53 +0200
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-02 17:10 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-02 23:24 +0000
Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-03 09:38 +0200
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 09:58 +0200
Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-03 11:18 +0200
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 13:23 +0200
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-03 18:01 +0300
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 17:18 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-03 22:20 +0000
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-04 20:41 +0300
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-05 01:41 +0000
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-05 10:38 +0300
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-05 12:37 +0300
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-05 13:00 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-13 00:43 +0000
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-13 15:04 +0300
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-13 16:52 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-17 22:18 +0000
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-21 21:27 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-17 22:17 +0000
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-15 08:53 -0700
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-18 08:11 -0700
Re: Threads across programming languages Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-18 12:26 -0700
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-23 08:54 -0700
Re: Threads across programming languages Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-23 16:31 -0700
Re: Threads across programming languages Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-30 17:27 +0100
Re: Threads across programming languages Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-30 14:21 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-02 23:21 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 08:45 +0200
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 09:05 +0200
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 09:09 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-04 02:33 +0000
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 20:05 -0700
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 20:07 -0700
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 20:09 -0700
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-04 06:00 +0200
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 21:19 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-05 01:40 +0000
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-04 22:23 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-02 05:39 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-02 07:53 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-02 23:16 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 09:00 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-04 02:30 +0000
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 20:36 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-04 04:46 +0000
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 21:50 -0700
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-04 06:00 +0200
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 21:27 -0700
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-02 13:28 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-02 23:15 +0000
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-02 16:58 -0700
Re: Threads across programming languages Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-03 00:15 +0000
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-02 17:22 -0700
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 00:07 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-03 02:25 +0000
Re: Threads across programming languages Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-05-03 12:33 -0700
Re: Threads across programming languages Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-05-07 20:48 -0700
Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-03 10:34 +0200
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-03 18:05 +0300
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 17:20 +0200
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-03 18:47 +0300
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-03 22:19 +0000
Re: Threads across programming languages bart <bc@freeuk.com> - 2024-05-04 00:27 +0100
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-04 22:04 +0300
Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-05 14:56 +0200
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-04 17:36 +0200
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-04 22:11 +0300
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-04 12:59 -0700
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-01 22:20 -0700
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-01 22:22 -0700
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-01 11:55 -0700
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-01 11:55 -0700
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 06:53 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 07:09 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 10:11 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 08:53 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 11:00 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 20:31 +0000
Re: Threads across programming languages scott@slp53.sl.home (Scott Lurndal) - 2024-05-01 21:00 +0000
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-02 00:05 +0300
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 23:05 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-02 05:46 +0200
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-02 13:33 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-03 22:22 +0000
Re: Threads across programming languages scott@slp53.sl.home (Scott Lurndal) - 2024-04-30 16:48 +0000
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-03 18:01 +0300 |
| Message-ID | <20240503180102.00002f98@yahoo.com> |
| In reply to | #384501 |
On Fri, 3 May 2024 13:23:13 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 03.05.2024 um 11:18 schrieb David Brown: > > On 03/05/2024 09:58, Bonita Montero wrote: > >> Am 03.05.2024 um 09:38 schrieb David Brown: > >> > >>> No it is not. C-style functions (or C++ functions for that > >>> matter) are not objects, and do not have calling operators. > >>> Built-in operators do not belong to a type, in the way that class > >>> operators do. > >> > >> You can assign a C-style function pointer to an auto > >> function-object. > > > > A C-style function /pointer/ is an object. A C-style /function/ is > > not. Do you understand the difference? > > Practically there isn't a difference. > For C, I agree, mostly because C has no nested functions. For C++ (after C++11) I am less sure, because of lambdas with non-empty captures.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-05-03 17:18 +0200 |
| Message-ID | <v12v90$ju1r$1@raubtier-asyl.eternal-september.org> |
| In reply to | #384502 |
Am 03.05.2024 um 17:01 schrieb Michael S: > On Fri, 3 May 2024 13:23:13 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: > >> Am 03.05.2024 um 11:18 schrieb David Brown: >>> On 03/05/2024 09:58, Bonita Montero wrote: >>>> Am 03.05.2024 um 09:38 schrieb David Brown: >>>> >>>>> No it is not. C-style functions (or C++ functions for that >>>>> matter) are not objects, and do not have calling operators. >>>>> Built-in operators do not belong to a type, in the way that class >>>>> operators do. >>>> >>>> You can assign a C-style function pointer to an auto >>>> function-object. >>> >>> A C-style function /pointer/ is an object. A C-style /function/ is >>> not. Do you understand the difference? >> >> Practically there isn't a difference. >> > > For C, I agree, mostly because C has no nested functions. > For C++ (after C++11) I am less sure, because of lambdas with > non-empty captures. > Lambdas without captures can be casted to C function-pointers and those lambdas have all the same function-pointer type if the signature of the calling operator is the same. A nice trick to enforce function-pointer casting is to apply the +-ope- rator to a non-capturing lambda since the plus-operator can be applied to all pointers (I can really recommend the book "C++ Lambda Story" for such details); this makes it possible to make the function-pointer defi- nition type-inferenced. Or if you want to create a function<>-object from the lambda which is guaranteed not to allocate if you pass a C function-pointer you can enforce that if you attach the +-sign to the assigned lambda.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-05-03 22:20 +0000 |
| Message-ID | <v13o0b$p9ih$4@dont-email.me> |
| In reply to | #384502 |
On Fri, 3 May 2024 18:01:02 +0300, Michael S wrote: > For C, I agree, mostly because C has no nested functions. GCC implements nested functions in the C compiler. Though oddly, not in C+ +. I posted a C example using nested functions in the “Recursion, Yo” thread.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-05-04 20:41 +0300 |
| Message-ID | <v15s0l$1al59$1@dont-email.me> |
| In reply to | #384511 |
On 04.05.2024 01:20, Lawrence D'Oliveiro wrote: > On Fri, 3 May 2024 18:01:02 +0300, Michael S wrote: > >> For C, I agree, mostly because C has no nested functions. > > GCC implements nested functions in the C compiler. Though oddly, not in C+ > +. > C++ already has functions nested in namespaces, namespaces nested in namespaces, functions nested in classes (static and non-static member functions), and classes nested in classes. It's already a lot of nesting, no need to complicate the matters more. In Pascal, function nesting is used for better encapsulation of data. In C++, the same is achieved in a cleaner and more explicit way via classes and member functions, so no need for this kind of nesting.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-05-05 01:41 +0000 |
| Message-ID | <v16o4t$1gbho$4@dont-email.me> |
| In reply to | #384537 |
On Sat, 4 May 2024 20:41:42 +0300, Paavo Helde wrote: > On 04.05.2024 01:20, Lawrence D'Oliveiro wrote: > >> On Fri, 3 May 2024 18:01:02 +0300, Michael S wrote: >> >>> For C, I agree, mostly because C has no nested functions. >> >> GCC implements nested functions in the C compiler. Though oddly, not in >> C++. >> > C++ already has functions nested in namespaces, namespaces nested in > namespaces, functions nested in classes (static and non-static member > functions), and classes nested in classes. It's already a lot of > nesting, no need to complicate the matters more. > > In Pascal, function nesting is used for better encapsulation of data. In > C++, the same is achieved in a cleaner and more explicit way via classes > and member functions, so no need for this kind of nesting. Interesting, isn’t it? You mention all the complications of C++, and how it doesn’t need yet more complications tacked on top to support something as simple as lexical binding. Yet Pascal had lexical binding from the get- go, and managed it in a much simpler way.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-05-05 10:38 +0300 |
| Message-ID | <v17d1m$1o3tr$1@dont-email.me> |
| In reply to | #384548 |
On 05.05.2024 04:41, Lawrence D'Oliveiro wrote: > On Sat, 4 May 2024 20:41:42 +0300, Paavo Helde wrote: > >> On 04.05.2024 01:20, Lawrence D'Oliveiro wrote: >> >>> On Fri, 3 May 2024 18:01:02 +0300, Michael S wrote: >>> >>>> For C, I agree, mostly because C has no nested functions. >>> >>> GCC implements nested functions in the C compiler. Though oddly, not in >>> C++. >>> >> C++ already has functions nested in namespaces, namespaces nested in >> namespaces, functions nested in classes (static and non-static member >> functions), and classes nested in classes. It's already a lot of >> nesting, no need to complicate the matters more. >> >> In Pascal, function nesting is used for better encapsulation of data. In >> C++, the same is achieved in a cleaner and more explicit way via classes >> and member functions, so no need for this kind of nesting. > > Interesting, isn’t it? You mention all the complications of C++, and how > it doesn’t need yet more complications tacked on top to support something > as simple as lexical binding. Yet Pascal had lexical binding from the get- > go, and managed it in a much simpler way. A programming language is a tool. The goal is not to have the tool which is simple to make. The goal is not even to have the tool which is simple to use. The goal is to have a tool which is adequate for its job.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-05 12:37 +0300 |
| Message-ID | <20240505123718.00000503@yahoo.com> |
| In reply to | #384548 |
On Sun, 5 May 2024 01:41:49 -0000 (UTC) Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > On Sat, 4 May 2024 20:41:42 +0300, Paavo Helde wrote: > > > On 04.05.2024 01:20, Lawrence D'Oliveiro wrote: > > > >> On Fri, 3 May 2024 18:01:02 +0300, Michael S wrote: > >> > >>> For C, I agree, mostly because C has no nested functions. > >> > >> GCC implements nested functions in the C compiler. Though oddly, > >> not in C++. > >> > > C++ already has functions nested in namespaces, namespaces nested in > > namespaces, functions nested in classes (static and non-static > > member functions), and classes nested in classes. It's already a > > lot of nesting, no need to complicate the matters more. > > > > In Pascal, function nesting is used for better encapsulation of > > data. In C++, the same is achieved in a cleaner and more explicit > > way via classes and member functions, so no need for this kind of > > nesting. > > Interesting, isn’t it? You mention all the complications of C++, and > how it doesn’t need yet more complications tacked on top to support > something as simple as lexical binding. Yet Pascal had lexical > binding from the get- go, and managed it in a much simpler way. Pascal pays huge price for its simplicity in terms of lack of locality. That is, the price is paid by users of Pascal, rather than by language itself. There are many other languages that have both nested functions and locality (i.e. allow declaration of variable at block or scope), but I find understanding of code written in this languages (my experience is mostly with Ada) way too hard. As a code reader, I very much prefer C, where nested function are not allowed at all. May be, I would like BCPL, where nested functions are allowed, but have no access to variables defined at outer scope, even better than C, but I never had an opportunity to use BCPL. Classic C++, where you can fake BCPL-style nested functions by static member functions of locally-defined classes is not bad, functionality-wise, but as is often a case with Classic C++, is ugly syntactically. Modern C++, with lambdas and captures, has the same or worse readability and comprehensibility problems that I disliked in the past with Ada.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-05-05 13:00 +0200 |
| Message-ID | <v17ot7$1qk8q$1@raubtier-asyl.eternal-september.org> |
| In reply to | #384551 |
Am 05.05.2024 um 11:37 schrieb Michael S: > Modern C++, with lambdas and captures, has the same or worse readability > and comprehensibility problems that I disliked in the past with Ada. I use lambdas to save code you'd otherwise write multiple times. If the code isn't shared among different functions I never make an external function from that. If the code shared multiple times differs for each usage I extend the lambda with generic callbacks. This isn't less readable but more readable since the interaction between the lambda and the surrounding code is that close an external function wouldn't make sense for me. Read the code in the thread "Reverse iteration is slower !" for an example.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-05-13 00:43 +0000 |
| Message-ID | <v1rnnq$32md5$1@dont-email.me> |
| In reply to | #384551 |
On Sun, 5 May 2024 12:37:18 +0300, Michael S wrote: > As a code reader, I very much prefer C, where nested function are not > allowed at all. The GNU C compiler allows them: see my example in the “Recursion, Yo” thread.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-13 15:04 +0300 |
| Message-ID | <20240513150450.00003030@yahoo.com> |
| In reply to | #384582 |
On Mon, 13 May 2024 00:43:38 -0000 (UTC) Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > On Sun, 5 May 2024 12:37:18 +0300, Michael S wrote: > > > As a code reader, I very much prefer C, where nested function are > > not allowed at all. > > The GNU C compiler allows them: see my example in the “Recursion, Yo” > thread. Which does not make it legal C. Or good ideea.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-05-13 16:52 +0200 |
| Message-ID | <v1t9fj$3h62p$1@raubtier-asyl.eternal-september.org> |
| In reply to | #384584 |
Am 13.05.2024 um 14:04 schrieb Michael S: > On Mon, 13 May 2024 00:43:38 -0000 (UTC) > Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > >> On Sun, 5 May 2024 12:37:18 +0300, Michael S wrote: >> >>> As a code reader, I very much prefer C, where nested function are >>> not allowed at all. >> >> The GNU C compiler allows them: see my example in the “Recursion, Yo” >> thread. > > Which does not make it legal C. Or good ideea. > If you target a certain platform relying on the compiler is the least problem. Even more because clang supports these nested C functions also.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-05-17 22:18 +0000 |
| Message-ID | <v28l2q$2d8vg$2@dont-email.me> |
| In reply to | #384585 |
On Mon, 13 May 2024 16:52:36 +0200, Bonita Montero wrote: > If you target a certain platform relying on the compiler is the least > problem. GCC is the closest we have to a de-facto-standard compiler, too.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-05-21 21:27 -0700 |
| Message-ID | <864jaqwjx7.fsf@linuxsc.com> |
| In reply to | #384598 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: > On Mon, 13 May 2024 16:52:36 +0200, Bonita Montero wrote: > >> If you target a certain platform relying on the compiler is the least >> problem. > > GCC is the closest we have to a de-facto-standard compiler, too. Perhaps true but not in its default mode. gcc -std=c99 -pedantic is very close to being standard C99, and similarly for -std=C90 and -std=C11 (in both cases with -pedantic). But gcc by itself, without any options and especially without -pedantic, is nowhere close to being a standard C compiler, de facto or otherwise.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-05-17 22:17 +0000 |
| Message-ID | <v28l1u$2d8vg$1@dont-email.me> |
| In reply to | #384584 |
On Mon, 13 May 2024 15:04:50 +0300, Michael S wrote: > On Mon, 13 May 2024 00:43:38 -0000 (UTC) Lawrence D'Oliveiro > <ldo@nz.invalid> wrote: > >> On Sun, 5 May 2024 12:37:18 +0300, Michael S wrote: >> >> > As a code reader, I very much prefer C, where nested function are not >> > allowed at all. >> >> The GNU C compiler allows them: see my example in the “Recursion, Yo” >> thread. > > Which does not make it legal C. Or good ideea. Worthwhile comparing, though: the one using nested functions is 99 source lines; the one doing it in strictly standard C is 128 source lines. That’s nearly 30% more code to do the same thing.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-05-15 08:53 -0700 |
| Message-ID | <868r0brrzz.fsf@linuxsc.com> |
| In reply to | #384582 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: > On Sun, 5 May 2024 12:37:18 +0300, Michael S wrote: > >> As a code reader, I very much prefer C, where nested function are not >> allowed at all. > > The GNU C compiler allows them: see my example in the ?Recursion, Yo? > thread. gcc accepts all sorts of things that aren't C. That doesn't make them part of the C language.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-05-18 08:11 -0700 |
| Message-ID | <86zfsnqhn6.fsf@linuxsc.com> |
| In reply to | #384502 |
Michael S <already5chosen@yahoo.com> writes: > On Fri, 3 May 2024 13:23:13 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: > >> Am 03.05.2024 um 11:18 schrieb David Brown: >> >>> On 03/05/2024 09:58, Bonita Montero wrote: >>> >>>> Am 03.05.2024 um 09:38 schrieb David Brown: >>>> >>>>> No it is not. C-style functions (or C++ functions for that >>>>> matter) are not objects, and do not have calling operators. >>>>> Built-in operators do not belong to a type, in the way that class >>>>> operators do. >>>> >>>> You can assign a C-style function pointer to an auto >>>> function-object. >>> >>> A C-style function /pointer/ is an object. A C-style /function/ is >>> not. Do you understand the difference? >> >> Practically there isn't a difference. > > For C, I agree, mostly because C has no nested functions. > For C++ (after C++11) I am less sure, because of lambdas with > non-empty captures. First, a pointer is not an object. In both C and C++, any pointer, including a function pointer, is a scalar value. A pointer value might be held in an object but it doesn't have to be. In most cases function pointers are not stored in objects but simply used to call the function pointed to. A function is a static (not meant in the sense of the 'static' keyword) program entity, usually arising as the result of giving a function definition somewhere in the test of a program. An expression with function type is a function designator. In most cases function designators are simply the identifier used in the definition that defines the function in question. When the operand of an & operator is a function, the result of evaluating the & expression is the address of the function designated, or in other words a function pointer value. In most other contexts a function designator is automatically converted to a function pointer value when evaluated, as would have happened if an & operator had been applied. (Applying a * operator to a function pointer operand gives a function designator for the pointed-to function.) In the lambda world there isn't an exact analogue to the idea of a function. There is the static text of a lambda expression, but that doesn't define a "thing" any more than the text '3+4' defines a "thing". Rather, when evaluated, a lambda expression produces a lambda value, also known as a closure. A closure is a value like other more familiar values: it can be used directly in a larger expression, like the result of evaluating '3+4' might be used in an expression like 'x[3+4]'; or it can be assigned thru an lvalue of the appropriate type to be stored in an object. The key point here is to distinguish between lambda expressions, which are simply text strings and not "things", and the result of evaluating a lambda expression, which are lambda values (closures). Lambda values are like function pointers in that they are values and can be dealt with as such, but they are not like function pointers in that they don't point to anything; they are simply values that can be used in conjunction with certain operators to effect various program actions. Disclaimer: I have not consulted any C++ standard to see if my terminology here matches how terminology is used in C++.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-18 12:26 -0700 |
| Message-ID | <87fruely54.fsf@nosuchdomain.example.com> |
| In reply to | #384603 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> First, a pointer is not an object. In both C and C++, any pointer,
> including a function pointer, is a scalar value. A pointer value
> might be held in an object but it doesn't have to be. In most cases
> function pointers are not stored in objects but simply used to call
> the function pointed to.
[...]
Certainly a pointer value is not an object. Certainly a pointer object
*is* an object. It's not uncommon to informally refer to a pointer
object as "a pointer". I presume you would consider such usage to be
incorrect, and I don't disagree, but it is fairly common.
I often find it useful to avoid referring to "pointers", and instead
refer to "pointer types", "pointer values", "pointer objects", and so
on (likewise for arrays).
The C standard does not, as far as I can tell, provide a definition for
the standalone term "pointer". (I could have missed something; I
checked section 3, "Terms, definitions, and symbols", and the index.)
But the standard does, in several places, use the term "pointer" to
refer to a pointer value. I don't know whether it's consistent.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-05-23 08:54 -0700 |
| Message-ID | <86v834v804.fsf@linuxsc.com> |
| In reply to | #384617 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > [...] > >> First, a pointer is not an object. In both C and C++, any pointer, >> including a function pointer, is a scalar value. A pointer value >> might be held in an object but it doesn't have to be. In most cases >> function pointers are not stored in objects but simply used to call >> the function pointed to. > > [...] > > Certainly a pointer value is not an object. Certainly a pointer > object *is* an object. It's not uncommon to informally refer to a > pointer object as "a pointer". I presume you would consider such > usage to be incorrect, and I don't disagree, but it is fairly > common. Good usage will be precise and logically consistent, adhere to the rules of normal English usage, and align with how terminology and phrasing is used in the C standard. On the flip side, it is best to try to avoid phrasing that is haphazard, careless, confusing, or sloppy. I don't remember ever seeing the phrase "pointer object" used to mean a pointer value, either informally or otherwise. The C standard does use the phrase "pointer object" in some places, but it means something quite different from a pointer, namely, an object that has pointer type (and not a pointer itself). A local declaration such as int *p; introduces the identifier 'p' as (a way to designate) a pointer object, but there is no pointer value anywhere in sight. > I often find it useful to avoid referring to "pointers", and > instead refer to "pointer types", "pointer values", "pointer > objects", and so on (likewise for arrays). I have the impression that you are someone who is unusually averse to ambiguity. I appreciate that your suggestions are given with the idea that they will help with clarity of communication. Unfortunately they don't always help, and sometimes make things worse rather than better. Your comment here is a case in point. The C standard uses the word pointer (or pointers) in a little over 900 places. In most of those, pointer is used as a simple noun; whether in each case it refers to a type or a run-time value is clear from context. Notably, the C standard uses the phrase "pointer value" in just a few places (I see five in n1570). It seems clear that the Standard's use of this phrase is meant to connote something different than just "pointer" by itself, and also that this (rather rare) usage wasn't chosen by accident. So the rule you describe muddies the water rather than helping, because it's not consistent with usage followed in the C standard. > The C standard does not, as far as I can tell, provide a > definition for the standalone term "pointer". (I could have > missed something; I checked section 3, "Terms, definitions, and > symbols", and the index.) But the standard does, in several > places, use the term "pointer" to refer to a pointer value. I > don't know whether it's consistent. Yes, AFAICT the C standard doesn't define "pointer" as a standalone noun. But it is clear from context that "pointer" by itself means basically the same thing as an address, as can be seen from the description of unary &, in 6.5.3.2 p3, or in the second sentence of the second paragraph of the footnote to 6.3.2.1 p1. The C standard does, however, define the word "object" to mean a region of storage in the execution environment. Whatever it is that a pointer might be, it's clear that it isn't a region of storage in the execution environment. The idea that a pointer object might be a pointer, rather than an object, is nonsensical on its face, and deserves to be called out as such.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-23 16:31 -0700 |
| Message-ID | <871q5s3y2k.fsf@nosuchdomain.example.com> |
| In reply to | #384903 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [...]
>>
>>> First, a pointer is not an object. In both C and C++, any pointer,
>>> including a function pointer, is a scalar value. A pointer value
>>> might be held in an object but it doesn't have to be. In most cases
>>> function pointers are not stored in objects but simply used to call
>>> the function pointed to.
>>
>> [...]
>>
>> Certainly a pointer value is not an object. Certainly a pointer
>> object *is* an object. It's not uncommon to informally refer to a
>> pointer object as "a pointer". I presume you would consider such
>> usage to be incorrect, and I don't disagree, but it is fairly
>> common.
>
> Good usage will be precise and logically consistent, adhere to the
> rules of normal English usage, and align with how terminology and
> phrasing is used in the C standard. On the flip side, it is best
> to try to avoid phrasing that is haphazard, careless, confusing,
> or sloppy.
That's obvious (and a bit condescending).
> I don't remember ever seeing the phrase "pointer object" used to
> mean a pointer value, either informally or otherwise. The C
> standard does use the phrase "pointer object" in some places, but
> it means something quite different from a pointer, namely, an
> object that has pointer type (and not a pointer itself). A local
> declaration such as
>
> int *p;
>
> introduces the identifier 'p' as (a way to designate) a pointer
> object, but there is no pointer value anywhere in sight.
Obviously, and I can't figure out why you feel the need to make that
point. Of course the phrase "pointer object" doesn't mean "pointer
value". I didn't suggest that it could, or that anyone might think it
could.
>> I often find it useful to avoid referring to "pointers", and
>> instead refer to "pointer types", "pointer values", "pointer
>> objects", and so on (likewise for arrays).
>
> I have the impression that you are someone who is unusually averse
> to ambiguity. I appreciate that your suggestions are given with
> the idea that they will help with clarity of communication.
> Unfortunately they don't always help, and sometimes make things
> worse rather than better. Your comment here is a case in point.
> The C standard uses the word pointer (or pointers) in a little
> over 900 places. In most of those, pointer is used as a simple
> noun; whether in each case it refers to a type or a run-time
> value is clear from context. Notably, the C standard uses the
> phrase "pointer value" in just a few places (I see five in n1570).
> It seems clear that the Standard's use of this phrase is meant
> to connote something different than just "pointer" by itself, and
> also that this (rather rare) usage wasn't chosen by accident. So
> the rule you describe muddies the water rather than helping,
> because it's not consistent with usage followed in the C standard.
The terms "pointer object" and "pointer value" are unambiguous, are they
not? Using "pointer value" rather than "pointer" is more precise than
the standard's typical usage, but does not conflict with it.
I haven't bothered to search the standard for all uses of the word
"pointer", and I'm not planning to do so. Apparently it's reasonably
consistent in its usage, and does not refer to objects of pointer type
as "pointers". Rather a "pointer" is either a pointer type or an object
of pointer type, and I presume each using is clear enough in context.
>> The C standard does not, as far as I can tell, provide a
>> definition for the standalone term "pointer". (I could have
>> missed something; I checked section 3, "Terms, definitions, and
>> symbols", and the index.) But the standard does, in several
>> places, use the term "pointer" to refer to a pointer value. I
>> don't know whether it's consistent.
>
> Yes, AFAICT the C standard doesn't define "pointer" as a standalone
> noun. But it is clear from context that "pointer" by itself means
> basically the same thing as an address, as can be seen from the
> description of unary &, in 6.5.3.2 p3, or in the second sentence
> of the second paragraph of the footnote to 6.3.2.1 p1.
Sure.
Incidentally, the footnote you cited refers to an *expression* as "a
pointer". I'm not sure that supports your point. I can accept that the
usage in that footnote is informal.
> The C standard does, however, define the word "object" to mean
> a region of storage in the execution environment. Whatever it
> is that a pointer might be, it's clear that it isn't a region
> of storage in the execution environment. The idea that a pointer
> object might be a pointer, rather than an object, is nonsensical
> on its face, and deserves to be called out as such.
It would deserve to be called out if anyone actually suggested it.
I certainly did not.
The idea that a pointer object is a pointer "rather than an object" is
obviously wrong, and not something I suggested. Of course a pointer
object (an object of pointer type) is an object, as I've already
explicitly said. My suggestion was that an object of pointer type might
be informally referred to as "a pointer". Perhaps the standard never
does so.
I get the impression that you're assuming that the word "pointer" can
*never* refer to an object of pointer type, and that clarifying the
distinction is therefore a waste of time. Is that accurate?
I note that
<https://en.wikipedia.org/wiki/Pointer_(computer_programming)> says:
> In computer science, a pointer is an object in many programming
> languages that stores a memory address.
which suggests that your statement that "a pointer is not an object"
might call for some clarification, even if it's entirely consistent with
the usage in the C standard.
I'm not presenting that sentence from Wikipedia as correct. I'm using
it to suggest that informally referring to a pointer object as "a
pointer" is common enough that it's worth mentioning the potential
ambiguity.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-05-30 17:27 +0100 |
| Message-ID | <v3a9eg$1osnv$2@dont-email.me> |
| In reply to | #384938 |
On 24/05/2024 00:31, Keith Thompson wrote: > > Obviously, and I can't figure out why you feel the need to make that > point. Of course the phrase "pointer object" doesn't mean "pointer > value". I didn't suggest that it could, or that anyone might think it > could. > A "pointer object" would be the physical bits which hold the pointer. A "pointer value" would be the address which these bits represent. You very rarely need to make this distinction because it's usually quite obvious from context, or it doesn't matter. So usually the term "pointer" will do. But just occasionally yu might need to be clear which one you are referring to. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web