Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #343873 > unrolled thread
| Started by | Leo Baumann <ib@leobaumann.de> |
|---|---|
| First post | 2023-09-09 19:04 +0200 |
| Last post | 2023-09-15 20:23 +0200 |
| Articles | 20 on this page of 261 — 23 participants |
Back to article view | Back to de.sci.electronics
Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-09 19:04 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Wabnig <hwabnig@.- --- -.dotat> - 2023-09-10 07:46 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-10 15:52 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Wabnig <hwabnig@.- --- -.dotat> - 2023-09-10 17:45 +0200
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-09-10 17:54 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-10 18:04 +0200
Re: Wirkungsgrad von 100 m RG213U Andreas Bockelmann <xotzil@gmx.de> - 2023-09-14 08:33 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-14 08:43 +0200
Re: Wirkungsgrad von 100 m RG213U Andreas Bockelmann <xotzil@gmx.de> - 2023-09-14 14:36 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-14 14:43 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-14 08:54 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-14 12:20 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-14 12:55 +0200
Re: Wirkungsgrad von 100 m RG213U "Wolfgang Allinger" <all2001@spambog.com> - 2023-09-14 08:17 -0400
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-14 14:29 +0200
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-09-16 13:59 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-16 14:55 +0200
Re: Wirkungsgrad von 100 m RG213U Hergen Lehmann <hlehmann.expires.12-22@snafu.de> - 2023-09-16 15:02 +0200
Re: Wirkungsgrad von 100 m RG213U Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-09-16 21:13 +0200
Re: Wirkungsgrad von 100 m RG213U Axel Berger <Spam@Berger-Odenthal.De> - 2023-09-14 15:32 +0200
Computer-Steinzeit (was Re: Wirkungsgrad von 100 m RG213U "Wolfgang Allinger" <all2001@spambog.com> - 2023-09-14 17:57 -0400
Re: Computer-Steinzeit (was Re: Wirkungsgrad von 100 m RG213U Andreas Bockelmann <xotzil@gmx.de> - 2023-09-15 08:59 +0200
Re: Computer-Steinzeit (was Re: Wirkungsgrad von 100 m RG213U "Wolfgang Allinger" <all2001@spambog.com> - 2023-09-15 05:29 -0400
Re: Computer-Steinzeit (was Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-09-16 23:24 +0200
Re: Computer-Steinzeit (was Re: Wirkungsgrad von 100 m RG213U "Wolfgang Allinger" <all2001@spambog.com> - 2023-09-17 18:18 -0400
Re: Computer-Steinzeit (was Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-09-18 11:26 +0200
Re: Computer-Steinzeit (was Re: Wirkungsgrad von 100 m RG213U Carla Schneider <carla_schn@proton.me> - 2023-09-19 16:43 +0200
Re: Wirkungsgrad von 100 m RG213U Michael Schwingen <news-1513678000@discworld.dascon.de> - 2023-09-15 19:05 +0000
Re: Wirkungsgrad von 100 m RG213U "Wolfgang Allinger" <all2001@spambog.com> - 2023-09-14 17:27 -0400
Re: Wirkungsgrad von 100 m RG213U Volker Bartheld <news2023@bartheld.net> - 2023-09-15 17:46 +0200
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-09-16 14:00 +0200
Re: Wirkungsgrad von 100 m RG213U "Wolfgang Allinger" <all2001@spambog.com> - 2023-09-16 07:48 -0400
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-09-16 20:50 +0200
Re: Wirkungsgrad von 100 m RG213U Axel Berger <Spam@Berger-Odenthal.De> - 2023-09-16 22:10 +0200
Re: Wirkungsgrad von 100 m RG213U Marte Schwarz <marte.schwarz@gmx.de> - 2023-09-16 22:41 +0200
Re: Wirkungsgrad von 100 m RG213U Axel Berger <Spam@Berger-Odenthal.De> - 2023-09-17 00:18 +0200
Re: Wirkungsgrad von 100 m RG213U Carla Schneider <carla_schn@proton.me> - 2023-09-19 00:00 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-19 10:14 +0200
Re: Wirkungsgrad von 100 m RG213U Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-09-19 21:13 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-20 11:56 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-20 16:27 +0200
Re: Wirkungsgrad von 100 m RG213U Hartmut Kraus <hartmut.melina@web.de> - 2023-09-20 21:55 +0200
Re: Wirkungsgrad von 100 m RG213U Marte Schwarz <marte.schwarz@gmx.de> - 2023-09-21 08:03 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-21 14:51 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-22 11:29 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-22 23:29 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-23 12:54 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-23 21:54 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-23 23:00 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-23 23:26 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-24 00:04 +0200
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-10-11 23:17 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-10-11 23:40 +0200
Re: Wirkungsgrad von 100 m RG213U Holger Schieferdecker <spamless@gmx.de> - 2023-09-21 09:57 +0200
Re: Wirkungsgrad von 100 m RG213U Hartmut Kraus <hartmut.melina@web.de> - 2023-09-21 10:16 +0200
Re: Wirkungsgrad von 100 m RG213U Hartmut Kraus <hartmut.melina@web.de> - 2023-09-21 10:18 +0200
Re: Wirkungsgrad von 100 m RG213U Hartmut Kraus <hartmut.melina@web.de> - 2023-09-21 10:48 +0200
Re: Wirkungsgrad von 100 m RG213U "Wolfgang Allinger" <all2001@spambog.com> - 2023-09-21 06:12 -0400
Re: Wirkungsgrad von 100 m RG213U Carla Schneider <carla_schn@proton.me> - 2023-09-21 14:10 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-21 16:30 +0200
Re: Wirkungsgrad von 100 m RG213U "Wolfgang Allinger" <all2001@spambog.com> - 2023-09-21 18:11 -0400
Re: Wirkungsgrad von 100 m RG213U Carla Schneider <carla_schn@proton.me> - 2023-09-22 08:20 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-22 14:56 +0200
Re: Wirkungsgrad von 100 m RG213U "Wolfgang Allinger" <all2001@spambog.com> - 2023-09-22 19:35 -0400
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-23 14:05 +0200
Re: Wirkungsgrad von 100 m RG213U Hartmut Kraus <hartmut.melina@web.de> - 2023-09-23 22:05 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-23 23:05 +0200
Re: Wirkungsgrad von 100 m RG213U Hartmut Kraus <hartmut.melina@web.de> - 2023-09-24 18:30 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-24 20:40 +0200
Re: Wirkungsgrad von 100 m RG213U Hartmut Kraus <hartmut.melina@web.de> - 2023-09-25 22:32 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-26 17:30 +0200
Re: Wirkungsgrad von 100 m RG213U Hergen Lehmann <hlehmann.expires.12-22@snafu.de> - 2023-09-21 14:44 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-21 16:53 +0200
Re: Wirkungsgrad von 100 m RG213U Hergen Lehmann <hlehmann.expires.12-22@snafu.de> - 2023-09-21 17:24 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-22 00:45 +0200
Re: Wirkungsgrad von 100 m RG213U Hergen Lehmann <hlehmann.expires.12-22@snafu.de> - 2023-09-22 10:31 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-23 00:50 +0200
Re: Wirkungsgrad von 100 m RG213U Hartmut Kraus <hartmut.melina@web.de> - 2023-09-23 09:25 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-23 11:11 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-23 13:39 +0200
Re: Wirkungsgrad von 100 m RG213U Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-09-23 20:41 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-23 22:46 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-23 23:30 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-24 00:07 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-23 22:11 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-23 23:28 +0200
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-09-28 20:49 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-28 22:48 +0200
Re: Wirkungsgrad von 100 m RG213U Volker Bartheld <news2023@bartheld.net> - 2023-09-29 14:52 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-10-01 23:21 +0200
Re: Wirkungsgrad von 100 m RG213U Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-09-23 21:11 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-23 23:14 +0200
Re: Wirkungsgrad von 100 m RG213U Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-09-24 21:03 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-24 22:49 +0200
Re: Wirkungsgrad von 100 m RG213U Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-09-25 21:35 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-26 12:28 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-25 23:13 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-21 18:18 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-22 00:20 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-22 08:56 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-22 09:01 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-22 09:43 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-22 09:58 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-22 11:12 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-23 00:50 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-23 13:29 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-23 22:19 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-23 23:36 +0200
Re: Wirkungsgrad von 100 m RG213U Holger Schieferdecker <spamless@gmx.de> - 2023-09-26 12:31 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-26 14:21 +0200
Re: Wirkungsgrad von 100 m RG213U Carla Schneider <carla_schn@proton.me> - 2023-09-22 13:50 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-22 15:10 +0200
Re: Wirkungsgrad von 100 m RG213U Carla Schneider <carla_schn@proton.me> - 2023-09-22 15:21 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-22 15:25 +0200
Re: Wirkungsgrad von 100 m RG213U Andreas Fecht <forum@aftec.de> - 2023-09-22 15:39 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-22 15:41 +0200
Re: Wirkungsgrad von 100 m RG213U Carla Schneider <carla_schn@proton.me> - 2023-09-22 16:08 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-22 16:07 +0200
Re: Wirkungsgrad von 100 m RG213U Carla Schneider <carla_schn@proton.me> - 2023-09-22 16:20 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-22 16:32 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-22 16:03 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-23 01:09 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-23 01:36 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-27 01:51 +0200
Re: Wirkungsgrad von 100 m RG213U "Wolfgang Allinger" <all2001@spambog.com> - 2023-09-21 18:23 -0400
Re: Wirkungsgrad von 100 m RG213U Hergen Lehmann <hlehmann.expires.12-22@snafu.de> - 2023-09-22 10:49 +0200
Re: Wirkungsgrad von 100 m RG213U Volker Bartheld <news2023@bartheld.net> - 2023-09-22 14:19 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-22 15:28 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-23 01:30 +0200
Re: Wirkungsgrad von 100 m RG213U Hartmut Kraus <hartmut.melina@web.de> - 2023-09-23 09:28 +0200
Re: Wirkungsgrad von 100 m RG213U "Wolfgang Allinger" <all2001@spambog.com> - 2023-09-22 19:55 -0400
Re: Wirkungsgrad von 100 m RG213U Hartmut Kraus <hartmut.melina@web.de> - 2023-09-23 09:30 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-22 11:33 +0200
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-09-28 20:32 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-21 11:51 +0200
Re: Wirkungsgrad von 100 m RG213U Hartmut Kraus <hartmut.melina@web.de> - 2023-09-21 14:57 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-21 13:18 +0200
Re: Wirkungsgrad von 100 m RG213U Carla Schneider <carla_schn@proton.me> - 2023-09-21 14:18 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-22 11:16 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-22 23:29 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-23 12:49 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-23 22:08 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-23 23:27 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-24 00:10 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-24 01:19 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-24 09:27 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-24 19:51 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-24 21:37 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-25 00:30 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-25 22:59 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-26 14:09 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-27 01:39 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-27 09:39 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-27 11:54 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-27 16:51 +0200
Re: Wirkungsgrad von 100 m RG213U Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-09-27 21:23 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-28 08:51 +0200
Re: Wirkungsgrad von 100 m RG213U Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-09-28 20:55 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-28 23:57 +0200
Re: Wirkungsgrad von 100 m RG213U Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-09-29 20:17 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-10-02 02:05 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-10-03 14:55 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-10-03 18:50 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-10-04 10:52 +0200
Re: Wirkungsgrad von 100 m RG213U Hergen Lehmann <hlehmann.expires.12-22@snafu.de> - 2023-10-04 12:48 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-10-04 16:33 +0200
Re: Wirkungsgrad von 100 m RG213U Michael Schwingen <news-1513678000@discworld.dascon.de> - 2023-09-28 11:45 +0000
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-28 16:17 +0200
Re: Wirkungsgrad von 100 m RG213U Michael Schwingen <news-1513678000@discworld.dascon.de> - 2023-09-28 17:07 +0000
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-28 23:09 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-28 03:02 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-21 14:42 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-09-21 16:42 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-21 17:21 +0200
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-10-05 21:10 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-10-06 02:03 +0200
Re: Wirkungsgrad von 100 m RG213U Andreas Bockelmann <xotzil@gmx.de> - 2023-10-06 07:49 +0200
Re: Wirkungsgrad von 100 m RG213U Carla Schneider <carla_schn@proton.me> - 2023-09-19 00:57 +0200
Re: Wirkungsgrad von 100 m RG213U Axel Berger <Spam@Berger-Odenthal.De> - 2023-09-19 01:43 +0200
Re: Wirkungsgrad von 100 m RG213U Marte Schwarz <marte.schwarz@gmx.de> - 2023-09-19 08:05 +0200
Re: Wirkungsgrad von 100 m RG213U Volker Bartheld <news2023@bartheld.net> - 2023-09-19 18:48 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-14 14:12 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-14 14:16 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-14 15:04 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-14 15:11 +0200
Re: Wirkungsgrad von 100 m RG213U "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2023-09-14 13:24 +0000
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-14 15:39 +0200
Re: Wirkungsgrad von 100 m RG213U Bernd Laengerich <Bernd.Laengerich@web.de> - 2023-09-14 18:09 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-14 18:21 +0200
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-09-15 11:36 +0200
Re: Wirkungsgrad von 100 m RG213U "Wolfgang Allinger" <all2001@spambog.com> - 2023-09-14 18:03 -0400
Re: Wirkungsgrad von 100 m RG213U "Peter Heirich" <talk.usenet@info21.heirich.name> - 2023-09-15 04:12 +0000
Re: Wirkungsgrad von 100 m RG213U "Wolfgang Allinger" <all2001@spambog.com> - 2023-09-15 04:49 -0400
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-14 16:10 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-14 16:17 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-14 16:34 +0200
Re: Wirkungsgrad von 100 m RG213U "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2023-09-14 15:37 +0000
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-14 18:07 +0200
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-09-16 14:07 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-16 17:41 +0200
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-09-18 11:56 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-18 15:39 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-18 21:10 +0200
Re: Wirkungsgrad von 100 m RG213U Carla Schneider <carla_schn@proton.me> - 2023-09-19 13:06 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-19 18:43 +0200
Re: Wirkungsgrad von 100 m RG213U Carla Schneider <carla_schn@proton.me> - 2023-09-18 23:43 +0200
Re: Wirkungsgrad von 100 m RG213U Christoph Müller <chrnewsgroup@astrail.de> - 2023-09-19 08:32 +0200
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-10-10 23:48 +0200
Re: Wirkungsgrad von 100 m RG213U Christoph Müller <chrnewsgroup@astrail.de> - 2023-10-11 08:31 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-10-11 11:15 +0200
Re: Wirkungsgrad von 100 m RG213U Christoph Müller <chrnewsgroup@astrail.de> - 2023-10-11 17:52 +0200
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-10-11 23:26 +0200
Re: Wirkungsgrad von 100 m RG213U Christoph Müller <chrnewsgroup@astrail.de> - 2023-10-13 09:00 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-10-13 15:30 +0200
Re: Wirkungsgrad von 100 m RG213U Christoph Müller <chrnewsgroup@astrail.de> - 2023-10-13 20:51 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-10-14 12:43 +0200
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-11-04 11:01 +0100
Re: Wirkungsgrad von 100 m RG213U Christoph Müller <chrnewsgroup@astrail.de> - 2023-11-06 08:10 +0100
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-11-04 11:14 +0100
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-10-11 11:54 +0200
Re: Wirkungsgrad von 100 m RG213U Christoph Müller <chrnewsgroup@astrail.de> - 2023-10-11 17:56 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-10-11 20:40 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-10-12 01:14 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-10-12 11:39 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-10-13 02:07 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-10-13 19:39 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-10-14 12:47 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-10-14 16:52 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-10-14 17:00 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Wabnig <hwabnig@.- --- -.dotat> - 2023-10-14 17:20 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Wabnig <hwabnig@.- --- -.dotat> - 2023-10-14 17:26 +0200
Re: Wirkungsgrad von 100 m RG213U Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2023-10-15 06:40 +0200
Re: Wirkungsgrad von 100 m RG213U Andreas Bockelmann <xotzil@gmx.de> - 2023-10-15 12:32 +0200
Re: Wirkungsgrad von 100 m RG213U Eric Bruecklmeier <u@5i7.de> - 2023-10-14 17:51 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-10-14 21:04 +0200
Re: Wirkungsgrad von 100 m RG213U Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2023-10-12 01:09 +0200
Re: Wirkungsgrad von 100 m RG213U Bernd Laengerich <Bernd.Laengerich@web.de> - 2023-10-12 08:28 +0200
Re: Wirkungsgrad von 100 m RG213U "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2023-09-19 07:14 +0000
Re: Wirkungsgrad von 100 m RG213U Carla Schneider <carla_schn@proton.me> - 2023-09-19 14:44 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-19 16:53 +0200
Re: Wirkungsgrad von 100 m RG213U Carla Schneider <carla_schn@proton.me> - 2023-09-19 00:50 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-19 01:42 +0200
Re: Wirkungsgrad von 100 m RG213U Marte Schwarz <marte.schwarz@gmx.de> - 2023-09-19 08:08 +0200
Re: Wirkungsgrad von 100 m RG213U Carla Schneider <carla_schn@proton.me> - 2023-09-19 08:33 +0200
Re: Wirkungsgrad von 100 m RG213U Andreas Bockelmann <xotzil@gmx.de> - 2023-09-15 10:54 +0200
Re: Wirkungsgrad von 100 m RG213U Hergen Lehmann <hlehmann.expires.12-22@snafu.de> - 2023-09-15 11:34 +0200
Re: Wirkungsgrad von 100 m RG213U Andreas Bockelmann <xotzil@gmx.de> - 2023-09-15 12:32 +0200
Re: Wirkungsgrad von 100 m RG213U Hergen Lehmann <hlehmann.expires.12-22@snafu.de> - 2023-09-15 13:52 +0200
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-09-16 23:40 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-18 12:57 +0200
Re: Wirkungsgrad von 100 m RG213U Bernd Laengerich <Bernd.Laengerich@web.de> - 2023-09-20 15:48 +0200
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-10-11 23:54 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-10-12 12:18 +0200
Re: Wirkungsgrad von 100 m RG213U "Peter Heirich" <talk.usenet@info21.heirich.name> - 2023-09-15 04:04 +0000
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-09-16 20:57 +0200
Re: Wirkungsgrad von 100 m RG213U Helmut Schellong <var@schellong.biz> - 2023-09-16 22:05 +0200
Re: Wirkungsgrad von 100 m RG213U Andreas Bockelmann <xotzil@gmx.de> - 2023-09-15 08:54 +0200
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-09-15 11:19 +0200
Re: Wirkungsgrad von 100 m RG213U "Wolfgang Allinger" <all2001@spambog.com> - 2023-09-15 05:45 -0400
Re: Wirkungsgrad von 100 m RG213U Rolf Bombach <rolfnospambombach@invalid.invalid> - 2023-09-10 18:04 +0200
Re: Wirkungsgrad von 100 m RG213U Leo Baumann <ib@leobaumann.de> - 2023-09-15 20:23 +0200
Page 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2023-09-23 12:49 +0200 |
| Message-ID | <uemfqu$gjbd$2@solani.org> |
| In reply to | #344358 |
Am 22.09.2023 um 23:29 schrieb Hans-Peter Diettrich:
> On 9/22/23 10:07 AM, Stefan Ram wrote:
>> Carla Schneider <carla_schn@proton.me> writes:
>>> Der Preprozessor ist auch kein Teil von C
>>
>> Die Programmiersprache C wird durch die ISO/IEC 9899
>> beschrieben. Und diese Beschreibung umfaßt auch den
>> Präprozessor:
>
> Wobei man erkennen kann, daß C und Präprozessor eine andere Syntax haben, also unterschiedliche
> formale Sprachen darstellen.
Nein, beispielsweise
# if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4
ist C.
Es gibt keine separate Präprozessor-Sprache.
Der C-Standard beschreibt _nur_ die Sprache C.
--
Mit freundlichen Grüßen
Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2023-09-23 22:08 +0200 |
| Message-ID | <kn8vr9Fc7mtU3@mid.individual.net> |
| In reply to | #344392 |
On 9/23/23 12:49 PM, Helmut Schellong wrote: > Am 22.09.2023 um 23:29 schrieb Hans-Peter Diettrich: >> On 9/22/23 10:07 AM, Stefan Ram wrote: >>> Carla Schneider <carla_schn@proton.me> writes: >>>> Der Preprozessor ist auch kein Teil von C >>> >>> Die Programmiersprache C wird durch die ISO/IEC 9899 >>> beschrieben. Und diese Beschreibung umfaßt auch den >>> Präprozessor: >> >> Wobei man erkennen kann, daß C und Präprozessor eine andere Syntax >> haben, also unterschiedliche formale Sprachen darstellen. > > Nein, beispielsweise > # if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4 > ist C. > > Es gibt keine separate Präprozessor-Sprache. > Der C-Standard beschreibt _nur_ die Sprache C. Ich schicke Dir mal ein paar von den Zeichen, die zwischen C und Präprozessor Syntax umschalten: # # # # # # # # DoDi
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2023-09-23 23:27 +0200 |
| Message-ID | <uenl82$h6he$4@solani.org> |
| In reply to | #344410 |
Am 23.09.2023 um 22:08 schrieb Hans-Peter Diettrich: > On 9/23/23 12:49 PM, Helmut Schellong wrote: >> Am 22.09.2023 um 23:29 schrieb Hans-Peter Diettrich: >>> On 9/22/23 10:07 AM, Stefan Ram wrote: >>>> Carla Schneider <carla_schn@proton.me> writes: >>>>> Der Preprozessor ist auch kein Teil von C >>>> >>>> Die Programmiersprache C wird durch die ISO/IEC 9899 >>>> beschrieben. Und diese Beschreibung umfaßt auch den >>>> Präprozessor: >>> >>> Wobei man erkennen kann, daß C und Präprozessor eine andere Syntax haben, also unterschiedliche >>> formale Sprachen darstellen. >> >> Nein, beispielsweise >> # if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4 >> ist C. >> >> Es gibt keine separate Präprozessor-Sprache. >> Der C-Standard beschreibt _nur_ die Sprache C. > > Ich schicke Dir mal ein paar von den Zeichen, die zwischen C und Präprozessor Syntax umschalten: > # # # # # # # # Dieses Zeichen ist syntaktischer Bestandteil der Sprache C. # und ## gehören zu den Punktuatoren der Sprache C. Du scheinst die Semantiken innerhalb eines Standards nicht zu verstehen. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2023-09-24 00:10 +0200 |
| Message-ID | <kn9651Fd73cU1@mid.individual.net> |
| In reply to | #344416 |
On 9/23/23 11:27 PM, Helmut Schellong wrote: >>> Nein, beispielsweise >>> # if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4 >>> ist C. Was meint ein C Compiler dann z.B. zu: >> # if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4 << > # und ## gehören zu den Punktuatoren der Sprache C. Mit welcher Wirkung? Hast Du vielleicht ein Beispiel für die Benutzung von ## in C oder C++, außerhalb einer Präprozessor-Direktive? > Du scheinst die Semantiken innerhalb eines Standards nicht zu verstehen. Sag ich doch: der Standard ist ein Konglomerat aus Präprozessor, C und C++ Sprachen. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2023-09-24 01:19 +0200 |
| Message-ID | <uenrqv$hame$1@solani.org> |
| In reply to | #344423 |
Am 24.09.2023 um 00:10 schrieb Hans-Peter Diettrich:
> On 9/23/23 11:27 PM, Helmut Schellong wrote:
>
>>>> Nein, beispielsweise
>>>> # if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4
>>>> ist C.
>
> Was meint ein C Compiler dann z.B. zu:
> >>
> #
> if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4
> <<
C verlangt, daß der Code mit defined... hinter einem # steht.
Der Code
if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4
ohne # davor ist daher ungültig.
'if' ohne Klammern dahinter [if (expr)] ist bereits falsch.
>> # und ## gehören zu den Punktuatoren der Sprache C.
>
> Mit welcher Wirkung?
Die Wirkungen hierzu sind im C-Standard beschrieben, und teilweise oben.
> Hast Du vielleicht ein Beispiel für die Benutzung von ## in C oder C++, außerhalb einer
> Präprozessor-Direktive?
Ja, viele sogar.
'#' ist keine Präprozessor-Direktive, sondern ein C-Punktuator und PP-Token!
'if', 'else' und 'define' sind solche PP-Direktiven.
Diese dürfen jeweils nur nach dem Punktuator '#' vorkommen.
'if defined' entspricht 'ifdef',
'if !defined' entspricht 'ifndef'.
>> Du scheinst die Semantiken innerhalb eines Standards nicht zu verstehen.
>
> Sag ich doch: der Standard ist ein Konglomerat aus Präprozessor, C und C++ Sprachen.
Ist er nicht, Du denkst das nur, weil Du Standards nicht richtig verstehst.
Es kann sein, daß Du den C-Standard gar nicht vorliegen hast.
Ich habe jedenfalls mehrere C-Standards von ANSI gekauft.
--
Mit freundlichen Grüßen
Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2023-09-24 09:27 +0200 |
| Message-ID | <ueooda$hp2n$1@solani.org> |
| In reply to | #344424 |
Am 24.09.2023 um 01:19 schrieb Helmut Schellong: > Am 24.09.2023 um 00:10 schrieb Hans-Peter Diettrich: >> On 9/23/23 11:27 PM, Helmut Schellong wrote: >> >>>>> Nein, beispielsweise >>>>> # if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4 >>>>> ist C. >> >> Was meint ein C Compiler dann z.B. zu: >> >> >> # >> if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4 >> << > > C verlangt, daß der Code mit defined... hinter einem # steht. > Der Code > if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4 > ohne # davor ist daher ungültig. > > 'if' ohne Klammern dahinter [if (expr)] ist bereits falsch. > >>> # und ## gehören zu den Punktuatoren der Sprache C. >> >> Mit welcher Wirkung? > > Die Wirkungen hierzu sind im C-Standard beschrieben, und teilweise oben. |A punctuator is a symbol that has independent syntactic and semantic significance. |Depending on context, it may specify an operation to be performed |(which in turn may yield a value or a function designator, produce a side effect, or |some combination thereof) in which case it is known as an |operator (other forms of operator also exist in some contexts). |An operand is an entity on which an operator acts. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2023-09-24 19:51 +0200 |
| Message-ID | <knbbteFntjnU1@mid.individual.net> |
| In reply to | #344424 |
On 9/24/23 1:19 AM, Helmut Schellong wrote: > Am 24.09.2023 um 00:10 schrieb Hans-Peter Diettrich: >> On 9/23/23 11:27 PM, Helmut Schellong wrote: >> >>>>> Nein, beispielsweise >>>>> # if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4 >>>>> ist C. >> >> Was meint ein C Compiler dann z.B. zu: >> >> >> # >> if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4 >> << > > C verlangt, daß der Code mit defined... hinter einem # steht. Tut er doch? Und das verlangt nicht C, sondern der Präprozessor. > Der Code > if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4 > ohne # davor ist daher ungültig. Ist kein C, weder syntaktisch noch semantisch, sowas versteht nur der Präprozessor. > > 'if' ohne Klammern dahinter [if (expr)] ist bereits falsch. Sag ich doch. >>> # und ## gehören zu den Punktuatoren der Sprache C. >> >> Mit welcher Wirkung? > > Die Wirkungen hierzu sind im C-Standard beschrieben, und teilweise oben. Jetzt bin ich aber gespannt: >> Hast Du vielleicht ein Beispiel für die Benutzung von ## in C oder >> C++, außerhalb einer Präprozessor-Direktive? > > Ja, viele sogar. Eines zu ## in C würde mir reichen. >>> Du scheinst die Semantiken innerhalb eines Standards nicht zu verstehen. Hast Du schon mal einen Parser für C98 geschrieben? >> >> Sag ich doch: der Standard ist ein Konglomerat aus Präprozessor, C und >> C++ Sprachen. > > Ist er nicht, Du denkst das nur, weil Du Standards nicht richtig verstehst. > Es kann sein, daß Du den C-Standard gar nicht vorliegen hast. > Ich habe jedenfalls mehrere C-Standards von ANSI gekauft. Dann kannst Du sicher darin finden, welche Wirkung *speziell* der Punktuator ## *außerhalb* einer Präprozessor-Direktive hat. Ich konnte dazu nichts finden. Und wenn Du dazu auch nichts finden kannst, dann erkläre ich diese Diskussion für beendet. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2023-09-24 21:37 +0200 |
| Message-ID | <ueq351$ieq2$1@solani.org> |
| In reply to | #344447 |
Am 24.09.2023 um 19:51 schrieb Hans-Peter Diettrich: > On 9/24/23 1:19 AM, Helmut Schellong wrote: >> Am 24.09.2023 um 00:10 schrieb Hans-Peter Diettrich: >>> On 9/23/23 11:27 PM, Helmut Schellong wrote: >>> >>>>>> Nein, beispielsweise >>>>>> # if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4 >>>>>> ist C. >>> >>> Was meint ein C Compiler dann z.B. zu: >>> >> >>> # >>> if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4 >>> << >> >> C verlangt, daß der Code mit defined... hinter einem # steht. > > Tut er doch? Nein, eine gültige Zeile für den Präprozessor ist nicht auf zwei Zeilen verteilt. > Und das verlangt nicht C, sondern der Präprozessor. Nein, der C-Standard verlangt das. >> Der Code >> if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4 >> ohne # davor ist daher ungültig. > > Ist kein C, weder syntaktisch noch semantisch, sowas versteht nur der Präprozessor. Da das Zeichen # nicht den Code anführt, ist es keine Zeile für den Präprozessor. Ohne das anführende Zeichen # handelt es sich um ungültigen Code. >> >> 'if' ohne Klammern dahinter [if (expr)] ist bereits falsch. > > Sag ich doch. Ich auch; Der Code ist ungültig. >>>> # und ## gehören zu den Punktuatoren der Sprache C. >>> >>> Mit welcher Wirkung? >> >> Die Wirkungen hierzu sind im C-Standard beschrieben, und teilweise oben. > > Jetzt bin ich aber gespannt: > > >>> Hast Du vielleicht ein Beispiel für die Benutzung von ## in C oder C++, außerhalb einer >>> Präprozessor-Direktive? >> >> Ja, viele sogar. > > Eines zu ## in C würde mir reichen. Es kommt darauf an, wie der C-Standard eine PP-Direktive genau definiert. 'define' ist jedenfalls ein Direktiven-Name. 'defined' ist kein Direktiven-Name. Weitere Details genau hierzu habe ich nicht im Kopf. >>>> Du scheinst die Semantiken innerhalb eines Standards nicht zu verstehen. > > Hast Du schon mal einen Parser für C98 geschrieben? ISO-C-Standards sind bisher C90, C99, C11, C17, und wahrscheinlich C23 in der Zukunft. C17 ist vernachlässigbar, da Minor. Einen direkten C-Parser habe ich bisher nicht geschrieben. Aber einen C-Parser für Syntax-Highlighting habe ich begonnen. Die Kommandos findccc und findcs in meiner bish-Shell sind Vorarbeiten zu diesem Projekt. >>> Sag ich doch: der Standard ist ein Konglomerat aus Präprozessor, C und C++ Sprachen. >> >> Ist er nicht, Du denkst das nur, weil Du Standards nicht richtig verstehst. >> Es kann sein, daß Du den C-Standard gar nicht vorliegen hast. >> Ich habe jedenfalls mehrere C-Standards von ANSI gekauft. > > Dann kannst Du sicher darin finden, welche Wirkung *speziell* der Punktuator ## *außerhalb* einer > Präprozessor-Direktive hat. Ich konnte dazu nichts finden. Und wenn Du dazu auch nichts finden > kannst, dann erkläre ich diese Diskussion für beendet. Ich schaue mal gründlich nach. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2023-09-25 00:30 +0200 |
| Message-ID | <ueqd9g$ij8c$1@solani.org> |
| In reply to | #344449 |
Am 24.09.2023 um 21:37 schrieb Helmut Schellong: > Am 24.09.2023 um 19:51 schrieb Hans-Peter Diettrich: >> On 9/24/23 1:19 AM, Helmut Schellong wrote: >>> Am 24.09.2023 um 00:10 schrieb Hans-Peter Diettrich: >>>> On 9/23/23 11:27 PM, Helmut Schellong wrote:[...] >>>> Hast Du vielleicht ein Beispiel für die Benutzung von ## in C oder C++, außerhalb einer >>>> Präprozessor-Direktive? >>> >>> Ja, viele sogar. >> >> Eines zu ## in C würde mir reichen. > > Es kommt darauf an, wie der C-Standard eine PP-Direktive genau definiert. > 'define' ist jedenfalls ein Direktiven-Name. > 'defined' ist kein Direktiven-Name. > Weitere Details genau hierzu habe ich nicht im Kopf. > >>>>> Du scheinst die Semantiken innerhalb eines Standards nicht zu verstehen. >> >> Hast Du schon mal einen Parser für C98 geschrieben? > > ISO-C-Standards sind bisher C90, C99, C11, C17, und wahrscheinlich C23 in der Zukunft. > C17 ist vernachlässigbar, da Minor. > > Einen direkten C-Parser habe ich bisher nicht geschrieben. > Aber einen C-Parser für Syntax-Highlighting habe ich begonnen. > Die Kommandos findccc und findcs in meiner bish-Shell sind Vorarbeiten zu diesem Projekt. > >>>> Sag ich doch: der Standard ist ein Konglomerat aus Präprozessor, C und C++ Sprachen. >>> >>> Ist er nicht, Du denkst das nur, weil Du Standards nicht richtig verstehst. >>> Es kann sein, daß Du den C-Standard gar nicht vorliegen hast. >>> Ich habe jedenfalls mehrere C-Standards von ANSI gekauft. >> >> Dann kannst Du sicher darin finden, welche Wirkung *speziell* der Punktuator ## *außerhalb* einer >> Präprozessor-Direktive hat. Ich konnte dazu nichts finden. Und wenn Du dazu auch nichts finden >> kannst, dann erkläre ich diese Diskussion für beendet. > > Ich schaue mal gründlich nach. ============================================================================================== A preprocessing directive consists of a sequence of preprocessing tokens that satisfies the following constraints: The first token in the sequence is a # preprocessing token that (at the start of translation phase 4) is either the first character in the source file (optionally after white space containing no new-line characters) or that follows white space containing at least one new-line character. The last token in the sequence is the first new-line character that follows the first token in the sequence. ============================================================================================== Vorstehend wird die Angelegenheit klargestellt. Viele andere Texte befinden sich (scheinbar) im Widerspruch zum Vorstehenden. Eine PP-Direktive besteht folglich aus der gesamten PP-Zeile, von # bis zur NL. Das war mir nicht klar. Ich dachte, beispielsweise '# define' sei eine PP-Direktive. Das ist jedoch nur der Direktiven-Name. Obwohl ich hier irrte, bedeutet dies nicht, daß der C-Standard ein Konglomerat aus den Sprachen 'Präprozessor', 'C' und 'C++' ist. . Programming languages — C This document specifies the form and establishes the interpretation of programs . expressed in the programming language C. Vorstehender Text ist eindeutig. Es werden keine weiteren Sprachen im C-Standard beschrieben. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2023-09-25 22:59 +0200 |
| Message-ID | <knebouF8c2pU1@mid.individual.net> |
| In reply to | #344458 |
On 9/25/23 12:30 AM, Helmut Schellong wrote: > Am 24.09.2023 um 21:37 schrieb Helmut Schellong: > ============================================================================================== > > A preprocessing directive consists of a sequence of preprocessing tokens > that satisfies > the following constraints: > The first token in the sequence is a # preprocessing token that (at the > start of translation > phase 4) is either the first character in the source file > (optionally after white space containing no new-line characters) > or that follows white space containing at least one new-line character. > The last token in the sequence is the first new-line character > that follows the first token in the sequence. > ============================================================================================== > > > Vorstehend wird die Angelegenheit klargestellt. > Viele andere Texte befinden sich (scheinbar) im Widerspruch zum > Vorstehenden. Texte außerhalb des Standards sind nun mal unverbindlich. > Eine PP-Direktive besteht folglich aus der gesamten PP-Zeile, von # bis > zur NL. > Das war mir nicht klar. > Ich dachte, beispielsweise '# define' sei eine PP-Direktive. Die Direktive ist die ganze Zeile, ggf. mit Fortsetzungszeilen. In anderem Kontext hast Du das auch schon als Kommando bezeichnet. > Das ist jedoch nur der Direktiven-Name. Es ist (hier) ein die erste Präprozessor-Anweisung innerhalb der Direktive. > > Obwohl ich hier irrte, bedeutet dies nicht, daß der C-Standard ein > Konglomerat > aus den Sprachen 'Präprozessor', 'C' und 'C++' ist. > > . Programming languages — C > This document specifies the form and establishes the interpretation of > programs > . expressed in the programming language C. > > Vorstehender Text ist eindeutig. > Es werden keine weiteren Sprachen im C-Standard beschrieben. Mein ANSI C98 Draft beginnt mit >> This document specifies [...] expressed in the programming language C++. << In den Drafts und Standards, die ich kenne, wird der Präprozessor, C und C++ gemeinsam beschrieben. In einem Quelltext kann zwischen diesen Sprachen kontrolliert umgeschaltet werden: # --> C oder C++ nach Präprozessor extern "C" --> C++ nach C Wenn Du einen C Standard ohne C++ gefunden hast, dann ist das für mich ein Zeichen von Wildwuchs, zumindest bei C++. Wie soll ein C++ Compiler auf C umschalten können, ohne daß die Sprache C ausreichend spezifiziert ist? Was ich bezüglich des Konglomerats von Sprachen schon lange hätte sagen sollen: We agree to disagree. Das ist nunmal Ansichtssache, egal was die Standards von sich behaupten oder in sie hineininterpretiert werden kann. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2023-09-26 14:09 +0200 |
| Message-ID | <ueuhlu$kibq$1@solani.org> |
| In reply to | #344476 |
Am 25.09.2023 um 22:59 schrieb Hans-Peter Diettrich: > On 9/25/23 12:30 AM, Helmut Schellong wrote: >> Am 24.09.2023 um 21:37 schrieb Helmut Schellong: > >> ============================================================================================== >> A preprocessing directive consists of a sequence of preprocessing tokens that satisfies >> the following constraints: >> The first token in the sequence is a # preprocessing token that (at the start of translation >> phase 4) is either the first character in the source file >> (optionally after white space containing no new-line characters) >> or that follows white space containing at least one new-line character. >> The last token in the sequence is the first new-line character >> that follows the first token in the sequence. >> ============================================================================================== >> >> Vorstehend wird die Angelegenheit klargestellt. >> Viele andere Texte befinden sich (scheinbar) im Widerspruch zum Vorstehenden. > Texte außerhalb des Standards sind nun mal unverbindlich. Ich meine andere Texte _innerhalb_ des C-Standards, die (scheinbar) widersprüchlich sind. Du wußtest, daß ich Texte innerhalb des C-Standards meine. >> Eine PP-Direktive besteht folglich aus der gesamten PP-Zeile, von # bis zur NL. >> Das war mir nicht klar. >> Ich dachte, beispielsweise '# define' sei eine PP-Direktive. > > Die Direktive ist die ganze Zeile, ggf. mit Fortsetzungszeilen. |5.1.1.2 Translation phases |1. Physical source file multibyte characters are mapped, ... |2. Each instance of a backslash character (\) immediately followed by a new-line character | is deleted, splicing physical source lines to form logical source lines |... |8. ... Die Fortsetzungszeilen (per \NL) werden also ganz früh zu einer Zeile umgeformt. > In anderem Kontext hast Du das auch schon als Kommando bezeichnet. Als ich von einer Kommando-Programmiersprache (Shell-Skript) schrieb. >> Das ist jedoch nur der Direktiven-Name. > > Es ist (hier) ein die erste Präprozessor-Anweisung innerhalb der Direktive. Der C-Standard erwähnt konkret Direktiven-Namen: |When in a group that is skipped (6.10.1), the directive syntax is relaxed to allow any sequence of |preprocessing tokens to occur between the _directive name_ and the following new-line character. >> Obwohl ich hier irrte, bedeutet dies nicht, daß der C-Standard ein Konglomerat >> aus den Sprachen 'Präprozessor', 'C' und 'C++' ist. >> >> . Programming languages — C >> This document specifies the form and establishes the interpretation of programs >> . expressed in the programming language C. >> >> Vorstehender Text ist eindeutig. >> Es werden keine weiteren Sprachen im C-Standard beschrieben. > > Mein ANSI C98 Draft beginnt mit > >> > This document specifies [...] expressed in the programming language C++. > << https://www.open-std.org/jtc1/sc22/wg14/www/projects.html Besorge Dir dort mal /richtige/ Drafts: |ISO/IEC 9899:TC3 Committee Draft — Septermber 7, 2007 WG14/N1256 |N1570 Committee Draft — April 12, 2011 ISO/IEC 9899:201x Programming languages — C 1. Scope 1 This International Standard specifies the form and establishes the interpretation of programs written in the C programming language.1) It specifies — the representation of C programs; — the syntax and constraints of the C language; — the semantic rules for interpreting C programs; — the representation of input data to be processed by C programs; — the representation of output data produced by C programs; — the restrictions and limits imposed by a conforming implementation of C. 2 This International Standard does not specify — the mechanism by which C programs are transformed for use by a data-processing system; — the mechanism by which C programs are invoked for use by a data-processing system; — the mechanism by which input data are transformed for use by a C program; — the mechanism by which output data are transformed after being produced by a C program; — the size or complexity of a program and its data that will exceed the capacity of any specific data-processing system or the capacity of a particular processor; — all minimal requirements of a data-processing system that is capable of supporting a conforming implementation > In den Drafts und Standards, die ich kenne, wird der Präprozessor, C und C++ gemeinsam beschrieben. > In einem Quelltext kann zwischen diesen Sprachen kontrolliert umgeschaltet werden: > # --> C oder C++ nach Präprozessor > extern "C" --> C++ nach C > > Wenn Du einen C Standard ohne C++ gefunden hast, dann ist das für mich ein Zeichen von Wildwuchs, > zumindest bei C++. Wie soll ein C++ Compiler auf C umschalten können, ohne daß die Sprache C > ausreichend spezifiziert ist? https://www.open-std.org/jtc1/sc22/wg14/www/projects.html Du mußt halt die offiziellen Drafts benutzen (zuvor auf einer dänischen Seite: ...dkuug.dk). Ich schrieb bereits zuvor, daß es C98 nicht gab/gibt. Du tust aber etwa so, als sei Dein ungültiger Kram das Echte, meine offiziellen Dokumente jedoch nicht. > Was ich bezüglich des Konglomerats von Sprachen schon lange hätte sagen sollen: > We agree to disagree. > Das ist nunmal Ansichtssache, egal was die Standards von sich behaupten oder in sie > hineininterpretiert werden kann. Einfach offizielle, gültige Dokumente verwenden. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2023-09-27 01:39 +0200 |
| Message-ID | <knh9cmFn6thU1@mid.individual.net> |
| In reply to | #344493 |
On 9/26/23 2:09 PM, Helmut Schellong wrote: > Am 25.09.2023 um 22:59 schrieb Hans-Peter Diettrich: >> On 9/25/23 12:30 AM, Helmut Schellong wrote: >>> Am 24.09.2023 um 21:37 schrieb Helmut Schellong: >> >>> ============================================================================================== >>> >>> A preprocessing directive consists of a sequence of preprocessing >>> tokens that satisfies >>> the following constraints: >>> The first token in the sequence is a # preprocessing token that (at >>> the start of translation >>> phase 4) is either the first character in the source file >>> (optionally after white space containing no new-line characters) >>> or that follows white space containing at least one new-line character. >>> The last token in the sequence is the first new-line character >>> that follows the first token in the sequence. >>> ============================================================================================== >>> >>> >>> Vorstehend wird die Angelegenheit klargestellt. >>> Viele andere Texte befinden sich (scheinbar) im Widerspruch zum >>> Vorstehenden. > >> Texte außerhalb des Standards sind nun mal unverbindlich. > > Ich meine andere Texte _innerhalb_ des C-Standards, die (scheinbar) > widersprüchlich sind. Du meinst Passagen im Stadard? > Du wußtest, daß ich Texte innerhalb des C-Standards meine. Nein, so konnte ich das nicht verstehen. Für mich ist der C-Standard 1 Text. > Die Fortsetzungszeilen (per \NL) werden also ganz früh zu einer Zeile > umgeformt. Nicht so ganz, die Zeilenenden müssen für den Compiler weiterhin sichtbar bleiben. >> In anderem Kontext hast Du das auch schon als Kommando bezeichnet. > > Als ich von einer Kommando-Programmiersprache (Shell-Skript) schrieb. Das ist beim Präprozessor nicht anders. Der übersetzt nichts, wandelt nur den Quelltext um. Als eigenständiges Programm kann er jeden Text überarbeiten. >> Mein ANSI C98 Draft beginnt mit >> >> >> This document specifies [...] expressed in the programming language C++. >> << > > https://www.open-std.org/jtc1/sc22/wg14/www/projects.html > > Besorge Dir dort mal /richtige/ Drafts: > |ISO/IEC 9899:TC3 Committee Draft — Septermber 7, 2007 WG14/N1256 > |N1570 Committee Draft — April 12, 2011 ISO/IEC 9899:201x Da scheinen ANSI und ISO getrennte Wege zu gehen? Wenn ich mich schon mit ungeliebten Sprachen beschäftigen muß, dann bitte gleich richtig (C++, enthält C) und nicht nur ein Teilchen davon. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2023-09-27 09:39 +0200 |
| Message-ID | <uf0m73$lj58$1@solani.org> |
| In reply to | #344508 |
Am 27.09.2023 um 01:39 schrieb Hans-Peter Diettrich: > On 9/26/23 2:09 PM, Helmut Schellong wrote: >> Am 25.09.2023 um 22:59 schrieb Hans-Peter Diettrich: >>> On 9/25/23 12:30 AM, Helmut Schellong wrote: >>>> Am 24.09.2023 um 21:37 schrieb Helmut Schellong: >>> >>>> ============================================================================================== >>>> A preprocessing directive consists of a sequence of preprocessing tokens that satisfies >>>> the following constraints: >>>> The first token in the sequence is a # preprocessing token that (at the start of translation >>>> phase 4) is either the first character in the source file >>>> (optionally after white space containing no new-line characters) >>>> or that follows white space containing at least one new-line character. >>>> The last token in the sequence is the first new-line character >>>> that follows the first token in the sequence. >>>> ============================================================================================== >>>> >>>> Vorstehend wird die Angelegenheit klargestellt. >>>> Viele andere Texte befinden sich (scheinbar) im Widerspruch zum Vorstehenden. >> >>> Texte außerhalb des Standards sind nun mal unverbindlich. >> >> Ich meine andere Texte _innerhalb_ des C-Standards, die (scheinbar) widersprüchlich sind. > > Du meinst Passagen im Stadard? Ja, natürlich. Ein Bezug auf andere Texte außerhalb des Standards wäre ja Unfug. >> Du wußtest, daß ich Texte innerhalb des C-Standards meine. > > Nein, so konnte ich das nicht verstehen. Für mich ist der C-Standard 1 Text. Ein Text kann auch beliebig in Texte (Textteile, Textstellen) aufgeteilt werden. Prolog, Epilog und Kapitel können auch als verschiedene Texte innerhalb eines Romans gelten. Den vollen Text ... Teil oder Ganzes eines Textes ... Einen Text aus der Bibel ...; Das kann auch nur ein Satz sein. >> Die Fortsetzungszeilen (per \NL) werden also ganz früh zu einer Zeile umgeformt. > > Nicht so ganz, die Zeilenenden müssen für den Compiler weiterhin sichtbar bleiben. Für Fortsetzungszeilen gilt das nicht: |Each instance of a backslash character (\) immediately followed by a new-line character is |deleted, splicing physical source lines to form logical source lines. Vorstehenden Satz hast Du gelöscht. Die gelöschten Zeichenfolgen '\NL' sind für den Compiler weiterhin _nicht_ sichtbar. >>> In anderem Kontext hast Du das auch schon als Kommando bezeichnet. >> >> Als ich von einer Kommando-Programmiersprache (Shell-Skript) schrieb. > > Das ist beim Präprozessor nicht anders. Der übersetzt nichts, wandelt nur den Quelltext um. Als > eigenständiges Programm kann er jeden Text überarbeiten. Der Präprozessor ist kein Kommando, sondern nur 'cc' oder 'clang' sind hier Kommandos. Der Präprozessor kann nur Texte in gültigem C (eine C-Quelle) bearbeiten. >>> Mein ANSI C98 Draft beginnt mit >>> >> >>> This document specifies [...] expressed in the programming language C++. >>> << >> >> https://www.open-std.org/jtc1/sc22/wg14/www/projects.html >> >> Besorge Dir dort mal /richtige/ Drafts: >> |ISO/IEC 9899:TC3 Committee Draft — Septermber 7, 2007 WG14/N1256 >> |N1570 Committee Draft — April 12, 2011 ISO/IEC 9899:201x > > Da scheinen ANSI und ISO getrennte Wege zu gehen? Nein, gar nicht. ISO und IEC sind internationale Organisationen. ANSI ist eine US-amerikanische Organisation, die ISO-Standards übernimmt, so wie auch DIN. > Wenn ich mich schon mit ungeliebten Sprachen beschäftigen muß, dann bitte gleich richtig (C++, > enthält C) und nicht nur ein Teilchen davon. C++ wird von der WG21 bearbeitet, einer anderen Workgroup. https://www.open-std.org/jtc1/sc22/wg21/docs/standards -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2023-09-27 11:54 +0200 |
| Message-ID | <knid1iFskklU1@mid.individual.net> |
| In reply to | #344516 |
On 9/27/23 9:39 AM, Helmut Schellong wrote: > Am 27.09.2023 um 01:39 schrieb Hans-Peter Diettrich: >>> Die Fortsetzungszeilen (per \NL) werden also ganz früh zu einer Zeile >>> umgeformt. >> >> Nicht so ganz, die Zeilenenden müssen für den Compiler weiterhin >> sichtbar bleiben. > > Für Fortsetzungszeilen gilt das nicht: > |Each instance of a backslash character (\) immediately followed by a > new-line character is > |deleted, splicing physical source lines to form logical source lines. Das Entfernen von \NL ist erst nach Entfernen von // Kommentaren möglich, und diese Entfernung muß \NL beibehalten. Mir ist nicht ganz klar, wie sich dieses Entfernen z.B. auf String-Literale auswirkt, die sich über mehrere Zeilen erstrecken. Vielleicht gibt es noch mehr Stellen, an denen Zeilenenden weiterhin bedeutsam sein können. >>> Als ich von einer Kommando-Programmiersprache (Shell-Skript) schrieb. >> >> Das ist beim Präprozessor nicht anders. Der übersetzt nichts, wandelt >> nur den Quelltext um. Als eigenständiges Programm kann er jeden Text >> überarbeiten. > > Der Präprozessor ist kein Kommando, sondern nur 'cc' oder 'clang' sind > hier Kommandos. > Der Präprozessor kann nur Texte in gültigem C (eine C-Quelle) bearbeiten. Das gilt nur für den Präprozessor als Teil eines Compilers, *nicht* für einen *selbständigen* Präprozessor. Der ursprünglich selbständige Präprozessor konnte und kann weiterhin zur Bearbeitung beliebiger Texte verwendet werden. Seitdem hat es aber im C/C++ Parser Änderungen gegeben, die eine unabhängige Vorbereitung solcher Quellen nicht mehr zuläßt. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2023-09-27 16:51 +0200 |
| Message-ID | <uf1fi3$m2tg$1@solani.org> |
| In reply to | #344523 |
Am 27.09.2023 um 11:54 schrieb Hans-Peter Diettrich:
> On 9/27/23 9:39 AM, Helmut Schellong wrote:
>> Am 27.09.2023 um 01:39 schrieb Hans-Peter Diettrich:
>
>
>>>> Die Fortsetzungszeilen (per \NL) werden also ganz früh zu einer Zeile umgeformt.
>>>
>>> Nicht so ganz, die Zeilenenden müssen für den Compiler weiterhin sichtbar bleiben.
>>
>> Für Fortsetzungszeilen gilt das nicht:
>> |Each instance of a backslash character (\) immediately followed by a new-line character is
>> |deleted, splicing physical source lines to form logical source lines.
>
> Das Entfernen von \NL ist erst nach Entfernen von // Kommentaren möglich, und diese Entfernung muß
> \NL beibehalten. Mir ist nicht ganz klar, wie sich dieses Entfernen z.B. auf String-Literale
> auswirkt, die sich über mehrere Zeilen erstrecken. Vielleicht gibt es noch mehr Stellen, an denen
> Zeilenenden weiterhin bedeutsam sein können.
Ich habe noch nie Zeilenkommentare //... innerhalb einer PP-Zeile geschrieben.
Sondern nur /*...*/.
Noch nie habe ich /*...*/ über Zeilenverlängerungen \NL hinweg geschrieben.
Das wäre auch nie sinnvoll gewesen.
Zeichenfolgen '\NL' werden in Translation phase 2 gelöscht.
Kommentare werden in Translation phase 3 gelöscht.
Phase 2 hat folglich Vorrang.
Das weiß ich schon lange.
Auch "...//..." (") hat Vorrang durch Maskierung.
>>>> Als ich von einer Kommando-Programmiersprache (Shell-Skript) schrieb.
>>>
>>> Das ist beim Präprozessor nicht anders. Der übersetzt nichts, wandelt nur den Quelltext um. Als
>>> eigenständiges Programm kann er jeden Text überarbeiten.
>>
>> Der Präprozessor ist kein Kommando, sondern nur 'cc' oder 'clang' sind hier Kommandos.
>> Der Präprozessor kann nur Texte in gültigem C (eine C-Quelle) bearbeiten.
>
> Das gilt nur für den Präprozessor als Teil eines Compilers, *nicht* für einen *selbständigen*
> Präprozessor. Der ursprünglich selbständige Präprozessor konnte und kann weiterhin zur Bearbeitung
Ein vom Compiler unabhängig aufrufbarer Präprozessor ist mir gänzlich unbekannt.
Es sei denn, es handelt sich um Unix-Kommandos wie 'tr' und ähnlich.
> beliebiger Texte verwendet werden. Seitdem hat es aber im C/C++ Parser Änderungen gegeben, die eine
> unabhängige Vorbereitung solcher Quellen nicht mehr zuläßt.
Beispielsweise werden Kommentare durch ein Leerzeichen ersetzt.
Damit nicht neue Tokens unkontrolliert entstehen.
#if 0
rreiuegkööekwq ea ä
#endif
"rreiuegkööekwq ea ä"
"rreiuegk\224\224ekwq ea \204"
Ich hatte in den beiden vorstehenden Fällen schon ERROR erlebt.
Bei alten Compilern, die non-ASCII nirgendwo in der Quelle akzeptierten.
--
Mit freundlichen Grüßen
Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2023-09-27 21:23 +0200 |
| Message-ID | <20230927212353.20ece650@Achmuehle.WOR> |
| In reply to | #344531 |
Hallo Helmut, Du schriebst am Wed, 27 Sep 2023 16:51:49 +0200: > Ich habe noch nie Zeilenkommentare //... innerhalb einer PP-Zeile > geschrieben. Sondern nur /*...*/. > Noch nie habe ich /*...*/ über Zeilenverlängerungen \NL hinweg > geschrieben. Das wäre auch nie sinnvoll gewesen. Geht aber alles. Du kannst auch beliebige Kommentare in Makro-Defintionen einbauen, sauber formatiert mit "\NL" (wie Du das schreibst). ... > Ein vom Compiler unabhängig aufrufbarer Präprozessor ist mir gänzlich > unbekannt. Es sei denn, es handelt sich um Unix-Kommandos wie 'tr' und > ähnlich. Du hast den "cc" selber genannt. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz -----------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2023-09-28 08:51 +0200 |
| Message-ID | <uf37pf$mr17$1@solani.org> |
| In reply to | #344536 |
Am 27.09.2023 um 21:23 schrieb Sieghard Schicktanz:
> Hallo Helmut,
>
> Du schriebst am Wed, 27 Sep 2023 16:51:49 +0200:
>
>> Ich habe noch nie Zeilenkommentare //... innerhalb einer PP-Zeile
>> geschrieben. Sondern nur /*...*/.
>> Noch nie habe ich /*...*/ über Zeilenverlängerungen \NL hinweg
>> geschrieben. Das wäre auch nie sinnvoll gewesen.
>
> Geht aber alles. Du kannst auch beliebige Kommentare in Makro-Defintionen
> einbauen, sauber formatiert mit "\NL" (wie Du das schreibst).
Vorher:
# define HKL cccccccccccccccc \
ddd //kkkkkkkkkk \
eeeeeeeeeeeeeeee
Nachher 1:
# define HKL cccccccccccccccc ddd //kkkkkkkkkk eeeeeeeeeeeeeeee
Nachher 2:
# define HKL cccccccccccccccc ddd
Das ist aber in die Hose gegangen.
Es fehlt nun 'eeeeeeeeeeeeeeee'.
>> Ein vom Compiler unabhängig aufrufbarer Präprozessor ist mir gänzlich
>> unbekannt. Es sei denn, es handelt sich um Unix-Kommandos wie 'tr' und
>> ähnlich.
>
> Du hast den "cc" selber genannt.
Das ist aber kein vom Compiler unabhängig aufrufbarer Präprozessor, sondern
'cc' IST der Compiler.
--
Mit freundlichen Grüßen
Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2023-09-28 20:55 +0200 |
| Message-ID | <20230928205526.66fb6f01@Achmuehle.WOR> |
| In reply to | #344548 |
Hallo Helmut, Du schriebst am Thu, 28 Sep 2023 08:51:33 +0200: > Am 27.09.2023 um 21:23 schrieb Sieghard Schicktanz: > > Hallo Helmut, > > > > Du schriebst am Wed, 27 Sep 2023 16:51:49 +0200: > > > >> Ich habe noch nie Zeilenkommentare //... innerhalb einer PP-Zeile > >> geschrieben. Sondern nur /*...*/. > >> Noch nie habe ich /*...*/ über Zeilenverlängerungen \NL hinweg > >> geschrieben. Das wäre auch nie sinnvoll gewesen. > > > > Geht aber alles. Du kannst auch beliebige Kommentare in > > Makro-Defintionen einbauen, sauber formatiert mit "\NL" (wie Du das > > schreibst). > > Vorher: > # define HKL cccccccccccccccc \ > ddd //kkkkkkkkkk \ > eeeeeeeeeeeeeeee > > Nachher 1: > # define HKL cccccccccccccccc ddd //kkkkkkkkkk > eeeeeeeeeeeeeeee > > Nachher 2: > # define HKL cccccccccccccccc ddd > > Das ist aber in die Hose gegangen. > Es fehlt nun 'eeeeeeeeeeeeeeee'. Nee, warum? Der Kommentar hinter "//" bis zum Ende der Gesamtzeile fehlt doch durchaus ordnungsgemäß. Aber was soll Dein "Nachher 1" sein? _Das_ ist eine Zwischenaktion des Präprozessors, die nicht nach außen sichtbar ist. Ansonsten schaut die Ausgabe des Präprozessors (hier: cpp) so aus: $ cpp cct.c # 0 "cct.c" # 0 "<built-in>" # 0 "<command-line>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 0 "<command-line>" 2 # 1 "cct.c" Jawoisserdenn? Wo ist denn der Makro-Text geblieben? Da gibt's nur leere Zeilen, wo die Definition gestanden haben könnte, und sonst nischt? Vielleich hilft ein Makro-Aufruf dahinter... So: $ cpp cct.c # 0 "cct.c" # 0 "<built-in>" # 0 "<command-line>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 0 "<command-line>" 2 # 1 "cct.c" cccccccccccccccc ddd Ja, daisserja! Die Zeile mit dem Makro-Text kommt also _nur dann_, wenn das Makro auch ausgeführt wird und seinen Inhalt in das Ausgabe-File ergießt. > >> Ein vom Compiler unabhängig aufrufbarer Präprozessor ist mir gänzlich > >> unbekannt. Es sei denn, es handelt sich um Unix-Kommandos wie 'tr' und > >> ähnlich. > > > > Du hast den "cc" selber genannt. > > Das ist aber kein vom Compiler unabhängig aufrufbarer Präprozessor, > sondern 'cc' IST der Compiler. Nein, das ist auch nicht der Compiler, das ist der "Compiler Controller". Aber Du hast insofern recht, als der Präprozessor den Namen "cpp" hat, so wie ich ihn oben auch aufgerufen habe. Ein "cc -E" wäre auch gegangen, dann wird gleich nach dem Präprozessor-Aufruf aufgehört und dessen Ausgabe landet auf dem Bildschirm. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz -----------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2023-09-28 23:57 +0200 |
| Message-ID | <uf4ssv$nni7$1@solani.org> |
| In reply to | #344588 |
Am 28.09.2023 um 20:55 schrieb Sieghard Schicktanz: > Hallo Helmut, > > Du schriebst am Thu, 28 Sep 2023 08:51:33 +0200: > >> Am 27.09.2023 um 21:23 schrieb Sieghard Schicktanz: >>> Hallo Helmut, >>> >>> Du schriebst am Wed, 27 Sep 2023 16:51:49 +0200: >>> >>>> Ich habe noch nie Zeilenkommentare //... innerhalb einer PP-Zeile >>>> geschrieben. Sondern nur /*...*/. >>>> Noch nie habe ich /*...*/ über Zeilenverlängerungen \NL hinweg >>>> geschrieben. Das wäre auch nie sinnvoll gewesen. >>> >>> Geht aber alles. Du kannst auch beliebige Kommentare in >>> Makro-Defintionen einbauen, sauber formatiert mit "\NL" (wie Du das >>> schreibst). >> >> Vorher: >> # define HKL cccccccccccccccc \ >> ddd //kkkkkkkkkk \ >> eeeeeeeeeeeeeeee >> >> Nachher 1: >> # define HKL cccccccccccccccc ddd //kkkkkkkkkk >> eeeeeeeeeeeeeeee >> >> Nachher 2: >> # define HKL cccccccccccccccc ddd >> >> Das ist aber in die Hose gegangen. >> Es fehlt nun 'eeeeeeeeeeeeeeee'. > > Nee, warum? Der Kommentar hinter "//" bis zum Ende der Gesamtzeile fehlt > doch durchaus ordnungsgemäß. Aber was soll Dein "Nachher 1" sein? _Das_ ist > eine Zwischenaktion des Präprozessors, die nicht nach außen sichtbar ist. Vorher: # define HKL ccccc \ ddd //kkkkk \ eeeee Nachher 1: # define HKL ccccc ddd //kkkkk eeeee Nachher 2: # define HKL ccccc ddd 'Nachher 1' ist der Zustand nach translation phase 2: Löschen von \NL. Dadurch rutscht eeeee unbeabsichtigt in den Kommentar hinein und verschwindet in phase 3. Zeilenkommentare funktionieren folglich nicht innerhalb von Zeilenverlängerungen. Das ist doch der geltende Kontext. Habe ich in vorhergehenden Postings erklärt. [...] >>>> Ein vom Compiler unabhängig aufrufbarer Präprozessor ist mir gänzlich >>>> unbekannt. Es sei denn, es handelt sich um Unix-Kommandos wie 'tr' und >>>> ähnlich. >>> >>> Du hast den "cc" selber genannt. >> >> Das ist aber kein vom Compiler unabhängig aufrufbarer Präprozessor, >> sondern 'cc' IST der Compiler. > > Nein, das ist auch nicht der Compiler, das ist der "Compiler Controller". Du konterkarierst durch Deine Argumentation: >>>> Ein vom Compiler unabhängig aufrufbarer Präprozessor ist mir gänzlich >>>> unbekannt. Es sei denn, es handelt sich um Unix-Kommandos wie 'tr' und >>>> ähnlich. >>> >>> Du hast den "cc" selber genannt. > Aber Du hast insofern recht, als der Präprozessor den Namen "cpp" hat, so > wie ich ihn oben auch aufgerufen habe. Der cpp interessiert mich einfach gar nicht. Der Compiler (inklusive PP) wird _grundsätzlich_ über sein Frontend aufgerufen. G R U N D S Ä T Z L I C H !!! Ich werde niemals einen externen PP verwenden. Ich wüßte gar nicht, warum überhaupt! Ich habe die man-page zu 'cpp' gelesen und lasse den externen cpp fallen wie eine heiße Kartoffel! Der paßt ja gar nicht richtig! Dessen Verwendung ist risikoreich! 'cc -E' ist der einzig richtige Weg. > Ein "cc -E" wäre auch gegangen, dann > wird gleich nach dem Präprozessor-Aufruf aufgehört und dessen Ausgabe > landet auf dem Bildschirm. Kenne ich seit den 1980ern. Die 5 verschieden umfangreichen Aufgaben eines C-Compilers habe ich in meinen C-Büchern erklärt. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2023-09-29 20:17 +0200 |
| Message-ID | <20230929201749.169a432c@Achmuehle.WOR> |
| In reply to | #344595 |
Hallo Helmut, Du schriebst am Thu, 28 Sep 2023 23:57:51 +0200: > > Nee, warum? Der Kommentar hinter "//" bis zum Ende der Gesamtzeile fehlt > > doch durchaus ordnungsgemäß. Aber was soll Dein "Nachher 1" sein? _Das_ > > ist eine Zwischenaktion des Präprozessors, die nicht nach außen > > sichtbar ist. > > Vorher: > # define HKL ccccc \ > ddd //kkkkk \ > eeeee > > Nachher 1: > # define HKL ccccc ddd //kkkkk eeeee > > Nachher 2: > # define HKL ccccc ddd > > 'Nachher 1' ist der Zustand nach translation phase 2: Löschen von \NL. Den Zustand gibt es nur innerhalb des Präprozessors als Zwischenschritt zur Vorbereitung der Verarbeitung, und in dem Fall sogar noch vor der _Definition_ des Makros. > Dadurch rutscht eeeee unbeabsichtigt in den Kommentar hinein und Nein, tut er nicht - dieser Teil _war_ schon _von Anfang an_ "im Kommentar", bzw. ein Teil davon. Die Sequenz "\NL" (ich bleib' mal bei dieser Schreibweise) ist _nicht_ Teil des Programmtextes. Folglich ist die gesamte Makro-Definition genau _eine_ Zeile, wie das ja auch verlangt ist. > verschwindet in phase 3. Zeilenkommentare funktionieren folglich nicht > innerhalb von Zeilenverlängerungen. Nein, da "verschwidet" nichts. > Das ist doch der geltende Kontext. > Habe ich in vorhergehenden Postings erklärt. Ja, falsch. > [...] > Du konterkarierst durch Deine Argumentation: > >>>> Ein vom Compiler unabhängig aufrufbarer Präprozessor ist mir > >>>> gänzlich unbekannt. Es sei denn, es handelt sich um Unix-Kommandos ... > > Aber Du hast insofern recht, als der Präprozessor den Namen "cpp" hat, > > so wie ich ihn oben auch aufgerufen habe. Eigentlich nicht - der "cpp" _ist_ e"in vom Compiler unabhängig aufrufbarer Präprozessor". Na schön, bei Dir könnte ich mir schon vorstellen, daß der Dir bis dato "gänzlich unbekannt" war... > Der cpp interessiert mich einfach gar nicht. > Der Compiler (inklusive PP) wird _grundsätzlich_ über sein Frontend > aufgerufen. G R U N D S Ä T Z L I C H !!! Kannsr Du so halten, und das ist im Normalfall auch durchaus sinnvoll, weil sich dann der Compiler-Controller (Steuerprogramm für die Kompilation) um alles für die Programmerstellung nötige kümmert. > Ich werde niemals einen externen PP verwenden. > Ich wüßte gar nicht, warum überhaupt! Es verlangt ja auch niemand von Dir. Aber manchmal ist es halt _dich_ nützlich, das Ergebnis dess Präprozessor zu sehen, z.B. wenn man fremde Makros benutzt (was durchaus vorkommt...) und sich nicht sicher ist, ob die im "#include"-Wust auch richtig umgesetzt werden, insbesondere wenn da viele symbolesteuerte bedingte Makro-Expansionen drinstecken. > Ich habe die man-page zu 'cpp' gelesen und lasse den externen cpp fallen > wie eine heiße Kartoffel! > Der paßt ja gar nicht richtig! Dessen Verwendung ist risikoreich! > 'cc -E' ist der einzig richtige Weg. Das ist die identische Funktion, halt indirekt über das Steuerprogramm. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz -----------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
Page 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
Back to top | Article view | de.sci.electronics
csiph-web