Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #118907 > 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 138 — 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 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-06 15:13 -0700
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-07 08:41 +0300
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-07 11:00 +0200
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-13 19:43 -0700
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-14 04:59 +0200
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-21 16:39 -0700
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-14 13:53 +0300
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-14 13:42 +0200
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-14 19:55 +0800
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-14 14:11 +0200
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-14 20:16 +0800
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-14 16:02 +0200
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-14 13:34 -0700
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-14 19:46 +0800
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-14 14:13 +0200
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-14 20:28 +0800
Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-14 16:24 +0200
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-15 03:29 +0800
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-14 23:34 +0300
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-15 08:31 +0800
Re: Threads across programming languages Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-05-14 18:16 -0700
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 06:26 +0200
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-15 11:06 +0300
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-21 16:34 -0700
Re: Threads across programming languages olcott <polcott333@gmail.com> - 2024-05-21 18:43 -0500
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 06:25 +0200
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-15 20:48 +0300
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 06:23 +0200
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-14 21:37 -0700
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-15 19:57 +0800
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-15 20:07 +0800
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 17:33 +0200
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-15 08:43 -0700
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 17:55 +0200
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-15 10:31 -0700
Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-15 11:20 +0200
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-15 22:38 +0800
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-15 20:46 +0300
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 21:51 +0200
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-03 19:30 -0700
Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-06-04 09:03 +0200
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-15 14:24 +0300
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-21 19:26 -0700
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-21 20:27 -0700
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-22 11:43 +0300
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-01 21:03 -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 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-03 18:01 +0300 |
| Message-ID | <20240503180102.00002f98@yahoo.com> |
| In reply to | #119011 |
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 | #119016 |
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 | #119016 |
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 | #119027 |
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 | #119053 |
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 | #119065 |
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 | #119065 |
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 | #119070 |
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 | #119070 |
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 | #119101 |
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 | #119102 |
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 | #119103 |
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 | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-05-17 22:17 +0000 |
| Message-ID | <v28l1u$2d8vg$1@dont-email.me> |
| In reply to | #119102 |
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-06 15:13 -0700 |
| Message-ID | <86ikzqtwqr.fsf@linuxsc.com> |
| In reply to | #119053 |
Paavo Helde <eesnimi@osa.pri.ee> writes: > 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. C++ doesn't need nested functions because it has lambdas, which are effectively equivalent. (Disclaimer: I don't know if C++ calls them lambdas. I hope everyone understands to what I am referring.)
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-05-07 08:41 +0300 |
| Message-ID | <v1cetc$33b2i$1@dont-email.me> |
| In reply to | #119077 |
On 07.05.2024 01:13, Tim Rentsch wrote: > Paavo Helde <eesnimi@osa.pri.ee> writes: > >> 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. > > C++ doesn't need nested functions because it has lambdas, which > are effectively equivalent. Lambdas are better than nested functions as one can specify explicitly which variables are shared and how. One can be lazy and pass [&], but one doesn't have to.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-05-07 11:00 +0200 |
| Message-ID | <v1cqjk$35l5e$1@raubtier-asyl.eternal-september.org> |
| In reply to | #119078 |
Am 07.05.2024 um 07:41 schrieb Paavo Helde: > Lambdas are better than nested functions as one can specify explicitly > which variables are shared and how. One can be lazy and pass [&], but > one doesn't have to. I mostly make implicit [&]-captures except when there's nothing to capture or I need the lambda in a different thread context, where I use [=] or individually moved objects with [x = move( y )].
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-05-13 19:43 -0700 |
| Message-ID | <86cyppru3q.fsf@linuxsc.com> |
| In reply to | #119078 |
Paavo Helde <eesnimi@osa.pri.ee> writes: > On 07.05.2024 01:13, Tim Rentsch wrote: > >> Paavo Helde <eesnimi@osa.pri.ee> writes: >> >>> 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. >> >> C++ doesn't need nested functions because it has lambdas, which >> are effectively equivalent. > > Lambdas are better than nested functions as one can specify explicitly > which variables are shared and how. One can be lazy and pass [&], but > one doesn't have to. To me that sounds like all the complications of nested functions, and more besides, and no real advantages. The choice of which variables to share is syntactic sugar, there is no difference in expressive power.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-05-14 04:59 +0200 |
| Message-ID | <v1uk2d$3uec0$1@raubtier-asyl.eternal-september.org> |
| In reply to | #119104 |
Am 14.05.2024 um 04:43 schrieb Tim Rentsch:
> To me that sounds like all the complications of nested functions,
> and more besides, and no real advantages. The choice of which
> variables to share is syntactic sugar, there is no difference
> in expressive power.
Lambdas can reduce a lot of redundant code. Here's one example:
add = 0;
// virtually adjust number of initiations
auto adjust = [&]<bool Reduce>( size_t max, bool_constant<Reduce> )
{
auto neg = []( ptrdiff_t value ) { return Reduce ? -value : value; };
if( max > m_nThreadsExecuting )
if( max >= m_nThreadsExecuting + m_queueSize )
add += neg( m_queueSize );
else
add += neg( max - m_nThreadsExecuting );
};
// sub before initiations
adjust( m_maxThreads, true_type() );
// add after initiations
adjust( maxThreads, false_type() );
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-05-21 16:39 -0700 |
| Message-ID | <865xv6spjy.fsf@linuxsc.com> |
| In reply to | #119105 |
Bonita Montero <Bonita.Montero@gmail.com> writes: > Am 14.05.2024 um 04:43 schrieb Tim Rentsch: > >> To me that sounds like all the complications of nested functions, >> and more besides, and no real advantages. The choice of which >> variables to share is syntactic sugar, there is no difference >> in expressive power. > > Lambdas can reduce a lot of redundant code. [...] Your example is isomorphic to using nested functions.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-05-14 13:53 +0300 |
| Message-ID | <v1vfqf$4eq2$1@dont-email.me> |
| In reply to | #119104 |
On 14.05.2024 05:43, Tim Rentsch wrote: > Paavo Helde <eesnimi@osa.pri.ee> writes: > >> On 07.05.2024 01:13, Tim Rentsch wrote: > >>> >>> C++ doesn't need nested functions because it has lambdas, which >>> are effectively equivalent. >> >> Lambdas are better than nested functions as one can specify explicitly >> which variables are shared and how. One can be lazy and pass [&], but >> one doesn't have to. > > To me that sounds like all the complications of nested functions, > and more besides, and no real advantages. The choice of which > variables to share is syntactic sugar, there is no difference > in expressive power. Most of what programming languages do is syntactic sugar. For just writing Turing complete code one programming language would be enough.
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c++
csiph-web