Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #71186 > unrolled thread
| Started by | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| First post | 2015-09-25 04:02 +0200 |
| Last post | 2015-10-02 00:16 +0200 |
| Articles | 20 on this page of 332 — 34 participants |
Back to article view | Back to comp.lang.c
Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 04:02 +0200
Re: Unexpected and difficult to understand SIGSEGV "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-24 19:51 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:09 +0200
Re: Unexpected and difficult to understand SIGSEGV John Gordon <gordon@panix.com> - 2015-09-25 04:32 +0000
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:09 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-25 22:07 +0000
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-25 18:46 -0400
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-26 10:57 +1200
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-25 21:40 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-26 16:51 +1200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-26 10:45 +0100
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-26 03:39 -0700
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-26 12:20 +0100
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-26 06:39 -0700
Re: Unexpected and difficult to understand SIGSEGV fir <profesor.fir@gmail.com> - 2015-09-27 01:45 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-26 23:11 +0200
Re: Unexpected and difficult to understand SIGSEGV jacobnavia <jacob@jacob.remcomp.fr> - 2015-09-25 10:28 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-25 10:33 +0000
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:05 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-25 16:44 +0000
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:08 +0200
Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-25 10:55 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:00 +0200
Re: Unexpected and difficult to understand SIGSEGV luser droog <luser.droog@gmail.com> - 2015-09-25 09:40 -0700
Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-25 20:25 +0100
Re: Unexpected and difficult to understand SIGSEGV <william@wilbur.25thandClement.com> - 2015-09-25 19:07 -0700
Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-26 10:47 +0100
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-26 10:34 -0400
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-26 15:28 +0000
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 17:32 -0700
Re: Unexpected and difficult to understand SIGSEGV Noob <root@127.0.0.1> - 2015-09-27 09:59 +0200
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-30 02:52 -0700
Re: Unexpected and difficult to understand SIGSEGV Noob <root@127.0.0.1> - 2015-09-30 20:13 +0200
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 16:00 -0700
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-28 08:17 +0000
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-30 04:00 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-01 09:34 +1300
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-01 19:05 +0000
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-02 08:25 +1300
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 16:02 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 12:57 +1300
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-06 09:23 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-07 11:18 +1300
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-09 13:52 -0700
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 09:51 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-29 11:07 +0000
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 15:09 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-30 07:34 +0000
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-30 10:33 +0200
Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-30 11:14 +0100
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-30 12:26 +0200
Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-30 11:58 +0100
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-01 19:16 +0000
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 16:21 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-01 19:27 +0000
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 07:58 -0700
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-01 21:52 +0200
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 16:10 -0700
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-27 11:15 +0100
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-28 08:47 +0000
Re: Unexpected and difficult to understand SIGSEGV Andrew Cooper <amc96@cam.ac.uk> - 2015-09-26 00:02 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 00:02 +0200
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-26 23:32 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 22:10 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 17:01 -0400
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-27 22:15 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 23:36 +0200
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 23:33 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 10:40 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 23:58 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 11:08 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 00:25 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 12:50 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:06 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:15 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:20 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:24 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:44 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:50 +1300
Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-09-27 23:44 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 20:17 +1300
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-28 01:06 -0700
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-28 16:59 +0200
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-28 09:23 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-29 07:47 +1300
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-28 13:46 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-29 07:52 +1300
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 10:15 +0200
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-02 09:55 +0000
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-02 11:59 -0400
Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-10-03 11:51 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-03 15:25 -0400
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:50 -0700
Re: Unexpected and difficult to understand SIGSEGV Richard Damon <Richard@Damon-Family.org> - 2015-09-27 18:32 -0400
Re: Unexpected and difficult to understand SIGSEGV asetofsymbols@gmail.com - 2015-09-27 17:37 -0700
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-27 17:50 -0700
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-28 18:18 +0000
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-28 11:31 -0700
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-29 07:37 +0000
Re: Unexpected and difficult to understand SIGSEGV asetofsymbols@gmail.com - 2015-09-27 17:38 -0700
Re: Unexpected and difficult to understand SIGSEGV asetofsymbols@gmail.com - 2015-09-27 17:39 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:42 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:46 +0200
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-02 09:56 +0000
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 18:20 -0400
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-27 15:54 -0700
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-27 18:23 -0400
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 00:33 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 11:42 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 01:04 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 12:32 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 01:37 +0200
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-27 16:53 -0700
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-28 00:21 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 01:30 +0200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-28 00:41 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 01:52 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 12:59 +1300
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-28 17:07 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-30 11:17 +0000
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-09-30 06:08 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-27 17:09 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:17 +0200
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-28 09:00 -0700
Re: Unexpected and difficult to understand SIGSEGV ais523 <ais523@nethack4.org> - 2015-10-01 14:05 +0000
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-01 16:23 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-01 10:26 -0400
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-01 16:53 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-01 11:26 -0400
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-01 21:57 +0200
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-01 13:30 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-01 13:57 -0700
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-01 17:19 -0400
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-01 15:38 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-01 17:14 -0700
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:19 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 15:01 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-04 18:26 -0400
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 17:53 -0700
Re: Unexpected and difficult to understand SIGSEGV Richard Damon <Richard@Damon-Family.org> - 2015-10-04 18:37 -0400
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-04 19:13 -0400
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 17:57 -0700
Re: Unexpected and difficult to understand SIGSEGV Richard Damon <Richard@Damon-Family.org> - 2015-10-04 21:57 -0400
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-05 01:53 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-05 09:37 -0700
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-09 14:10 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-09 14:35 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-10 11:43 +1300
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-12 09:17 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-12 12:32 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-12 14:12 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-12 14:52 -0700
Re: Unexpected and difficult to understand SIGSEGV glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-13 03:00 +0000
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-12 23:34 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-14 11:00 +0000
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-14 08:34 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-14 11:34 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-14 11:57 -0700
Re: Unexpected and difficult to understand SIGSEGV glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-15 00:03 +0000
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-15 10:57 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-20 16:06 +0000
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-17 07:32 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-17 07:51 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-17 15:51 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-02 10:09 +0000
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-02 08:55 -0400
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-02 08:59 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 17:35 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 10:02 -0700
Re: Unexpected and difficult to understand SIGSEGV Robert Wessel <robertwessel2@yahoo.com> - 2015-10-03 16:11 -0500
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-03 17:27 -0400
Re: Unexpected and difficult to understand SIGSEGV Robert Wessel <robertwessel2@yahoo.com> - 2015-10-03 16:58 -0500
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 15:16 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-03 18:21 -0400
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-03 18:23 -0400
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-03 18:52 -0400
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 16:16 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-03 19:13 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 23:34 -0700
Re: Unexpected and difficult to understand SIGSEGV glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-04 07:09 +0000
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 14:43 -0700
Re: Unexpected and difficult to understand SIGSEGV Robert Wessel <robertwessel2@yahoo.com> - 2015-10-04 03:19 -0500
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:48 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 16:26 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 13:21 -0700
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-02 17:05 -0400
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-02 15:11 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 20:55 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 12:00 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-03 16:52 -0700
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:40 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-01 22:02 -0400
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 10:09 +0100
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 08:19 -0700
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-02 03:17 -0700
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-02 13:02 +0200
Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-10-01 18:33 -0700
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-01 11:17 -0400
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-01 17:06 +0100
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-01 11:45 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-02 10:21 +0000
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 11:36 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-02 11:44 +0100
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 13:24 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-02 15:31 +0100
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 18:04 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-02 18:21 +0100
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 21:04 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-03 08:29 +0200
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-03 16:47 +0200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-03 17:37 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-03 17:54 +0100
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-04 18:16 +0200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 18:13 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-04 18:22 +0100
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 20:17 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-04 21:07 +0100
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 22:10 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 09:24 +1300
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 22:15 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 10:38 +1300
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 23:02 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 11:10 +1300
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 23:51 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 11:56 +1300
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 07:38 +1300
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-04 23:51 +0200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 23:44 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 11:52 +1300
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-05 00:09 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 13:00 +1300
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-10-04 17:14 -0700
Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-10-05 09:40 -0700
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-05 18:32 +0100
Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-10-05 21:59 -0700
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-05 01:13 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-06 17:14 +0000
Re: Unexpected and difficult to understand SIGSEGV Gareth Owen <gwowen@gmail.com> - 2015-10-02 14:56 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-02 16:31 +0100
Re: Unexpected and difficult to understand SIGSEGV Gareth Owen <gwowen@gmail.com> - 2015-10-02 20:11 +0100
Re: Unexpected and difficult to understand SIGSEGV jadill33@gmail.com - 2015-10-02 09:18 -0700
Re: Unexpected and difficult to understand SIGSEGV Gareth Owen <gwowen@gmail.com> - 2015-10-02 20:14 +0100
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 10:20 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-04 14:03 +0000
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-01 09:28 -0700
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-10-01 18:53 +0200
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-10-02 06:26 +0200
Generating header files (Was: Unexpected and difficult to understand SIGSEGV) Roberto Waltman <usenet@rwaltman.com> - 2015-10-01 13:40 -0400
Re: Generating header files (Was: Unexpected and difficult to understand SIGSEGV) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-01 23:58 +0200
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:06 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 21:05 -0400
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 10:26 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 21:15 -0400
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-28 09:52 -0400
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-28 10:36 -0400
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-28 10:40 -0400
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-28 15:55 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-29 01:16 +0200
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-29 00:26 +0100
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 10:34 +0200
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-29 15:50 +0100
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-29 11:16 -0400
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-29 16:22 +0100
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-29 13:15 -0400
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-29 18:56 +0100
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-29 07:04 -0400
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 00:07 +0200
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-29 18:13 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-09-29 21:57 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-30 01:57 -0400
Re: Unexpected and difficult to understand SIGSEGV jadill33@gmail.com - 2015-09-30 06:01 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 16:11 +0200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-30 14:12 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 16:15 +0200
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-30 08:40 -0700
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-09-30 22:28 +0200
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-09-30 22:31 +0200
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-30 16:53 -0400
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-09-30 23:19 +0200
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-09-30 23:32 +0200
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-30 18:17 -0400
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-01 03:19 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-30 22:01 -0400
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-02 00:46 +0200
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 17:44 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:51 +1300
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 18:04 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 03:39 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 22:03 -0400
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 04:16 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 15:19 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 04:23 +0200
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 14:11 +0200
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 00:15 +0200
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-29 18:14 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-02 00:41 +0200
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-27 19:58 -0700
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 10:43 +0200
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 00:16 +0200
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-29 15:51 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 16:37 +0200
Strings (was Re: Unexpected and difficult to understand SIGSEGV) supercat@casperkitty.com - 2015-09-30 09:12 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-09-30 17:34 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) supercat@casperkitty.com - 2015-09-30 11:29 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-09-30 20:00 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) supercat@casperkitty.com - 2015-09-30 12:49 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-09-30 22:26 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) supercat@casperkitty.com - 2015-09-30 16:27 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-10-01 09:56 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-01 03:08 +0200
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-30 13:10 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Ian Collins <ian-news@hotmail.com> - 2015-10-01 09:23 +1300
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-30 19:02 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Richard Heathfield <rjh@cpax.org.uk> - 2015-10-01 03:12 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-10-01 11:15 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Richard Heathfield <rjh@cpax.org.uk> - 2015-10-01 11:36 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-01 05:49 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) David Brown <david.brown@hesbynett.no> - 2015-10-01 16:41 +0200
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Ian Collins <ian-news@hotmail.com> - 2015-10-01 15:16 +1300
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-30 19:10 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Ian Collins <ian-news@hotmail.com> - 2015-10-01 15:20 +1300
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Philip Lantz <prl@canterey.us> - 2015-10-01 01:26 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-01 02:16 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Martin Shobe <martin.shobe@yahoo.com> - 2015-10-01 08:34 -0500
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 19:06 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 04:18 +0200
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 21:32 -0700
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 07:54 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 17:16 +0200
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-27 11:21 -0400
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 08:59 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-02 00:16 +0200
Page 11 of 17 — ← Prev page 1 … 9 10 [11] 12 13 … 17 Next page →
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-02 10:21 +0000 |
| Message-ID | <560e5a5c.4956718@news.xs4all.nl> |
| In reply to | #71547 |
Bartc <bc@freeuk.com> wrote: > On 01/10/2015 15:05, ais523 wrote: > > Keith Thompson wrote: > > >> It's a clever idea, and it's perfectly reasonable to *think* that > >> it's a good one. > > (It *is* a good idea to avoid having to write the same information > twice. Do you think if C made it possible to write only a function > definition, that anyone would waste time manually writing a prototype > ever again?) I never manually write a prototype. I write a full function declaration as part of the definition, and then copy-and-paste it into either the list at the top of the file, or the header file. That way, at least I know I've misspelt it the same way both times. Richard
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-02 11:36 +0100 |
| Message-ID | <mulmkk$ep$1@dont-email.me> |
| In reply to | #71592 |
On 02/10/2015 11:21, Richard Bos wrote: > Bartc <bc@freeuk.com> wrote: > >> On 01/10/2015 15:05, ais523 wrote: >>> Keith Thompson wrote: >> >>>> It's a clever idea, and it's perfectly reasonable to *think* that >>>> it's a good one. >> >> (It *is* a good idea to avoid having to write the same information >> twice. Do you think if C made it possible to write only a function >> definition, that anyone would waste time manually writing a prototype >> ever again?) > > I never manually write a prototype. I write a full function declaration > as part of the definition, and then copy-and-paste it into either the > list at the top of the file, or the header file. Having to copy&paste is nearly as much effort as writing the prototype. Looking at one, not that huge project, where I did use an automatic tool, I had 500 exported functions needing prototypes (and 150 non-exported ones). That's 650 copy&pastes to start with, and trying to locate the logical place to put each one. Plus many hundreds more operations every time you make a change, *and* having the locate and update its matching prototype. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-02 11:44 +0100 |
| Message-ID | <muln1t$1pi$1@dont-email.me> |
| In reply to | #71593 |
On 02/10/15 11:36, Bartc wrote: > On 02/10/2015 11:21, Richard Bos wrote: >> Bartc <bc@freeuk.com> wrote: >> >>> On 01/10/2015 15:05, ais523 wrote: >>>> Keith Thompson wrote: >>> >>>>> It's a clever idea, and it's perfectly reasonable to *think* that >>>>> it's a good one. >>> >>> (It *is* a good idea to avoid having to write the same information >>> twice. Do you think if C made it possible to write only a function >>> definition, that anyone would waste time manually writing a prototype >>> ever again?) >> >> I never manually write a prototype. I write a full function declaration >> as part of the definition, and then copy-and-paste it into either the >> list at the top of the file, or the header file. > > Having to copy&paste is nearly as much effort as writing the prototype. yy[^W]Wp[ESC]A;[ESC] Job done, with 9 keypresses, all of which are in kinaesthetic memory and thus come quickly and naturally. It would take me perhaps two seconds to perform the above operation, one second on a good day, maybe three on a bad day. How is that "nearly as much effort as writing" double print_account_records(Account *account, size_t count); ? (The prototype took me about 8 seconds to copy-type.) > Looking at one, not that huge project, where I did use an automatic > tool, I had 500 exported functions needing prototypes (and 150 > non-exported ones). All the more reason to use a good editor. > That's 650 copy&pastes to start with, and trying to locate the logical > place to put each one. Plus many hundreds more operations every time you > make a change, *and* having the locate and update its matching prototype. It's really not as difficult as you are trying to make out. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-02 13:24 +0100 |
| Message-ID | <mulsu1$n9s$1@dont-email.me> |
| In reply to | #71594 |
On 02/10/2015 11:44, Richard Heathfield wrote:
> On 02/10/15 11:36, Bartc wrote:
>> On 02/10/2015 11:21, Richard Bos wrote:
>>> Bartc <bc@freeuk.com> wrote:
>>>
>>>> On 01/10/2015 15:05, ais523 wrote:
>>>>> Keith Thompson wrote:
>>>>
>>>>>> It's a clever idea, and it's perfectly reasonable to *think* that
>>>>>> it's a good one.
>>>>
>>>> (It *is* a good idea to avoid having to write the same information
>>>> twice. Do you think if C made it possible to write only a function
>>>> definition, that anyone would waste time manually writing a prototype
>>>> ever again?)
>>>
>>> I never manually write a prototype. I write a full function declaration
>>> as part of the definition, and then copy-and-paste it into either the
>>> list at the top of the file, or the header file.
>>
>> Having to copy&paste is nearly as much effort as writing the prototype.
>
> yy[^W]Wp[ESC]A;[ESC]
>
> Job done, with 9 keypresses, all of which are in kinaesthetic memory and
> thus come quickly and naturally. It would take me perhaps two seconds to
> perform the above operation, one second on a good day, maybe three on a
> bad day. How is that "nearly as much effort as writing"
Since I've no idea what that sequence does, I can't say how it compares
with the copy&paste I would have to do.
If that 9-key sequence does the following:
Wherever you are in or around the function in question, it:
(1) Locates the first line of the function that contains the signature
(2) Copies the contents of that line
(3) Removes the { on the end if there is one
(4) Adds a ";" at the end (but before any comment)
(5) Opens the header file where all shared prototypes reside (perhaps
per module, perhaps per project)
(6) Locates the old version of the prototype
(7) Replaces that line with new version
(8) Closes the header file and gets you back to what you were doing.
Then I would be very impressed. Because the above is what usually needs
to be done even using copy&paste. Even more work if the signature spans
more than one line. (A bit less work if doing this on a batch of
brand-new functions.)
If the change involves switching between static and non-static, which
means moving the prototype between module and header, or changing the
name of the function (making it harder to locate the old prototype),
then it would be more impressive still.
But it seems to me that you are agreeing that maintaining function
prototypes and keeping them in sync is a pain, otherwise why bother seek
out a method that reduces the effort to 2-3 seconds per function?
That's little different to my using an automatic tool that does the same
(my tool would do all functions in a module in some 30ms iirc, and I
wouldn't accidentally miss one out either).
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-02 15:31 +0100 |
| Message-ID | <mum4c9$kmn$1@dont-email.me> |
| In reply to | #71599 |
On 02/10/15 13:24, Bartc wrote:
> On 02/10/2015 11:44, Richard Heathfield wrote:
>> On 02/10/15 11:36, Bartc wrote:
<snip>
>>> Having to copy&paste is nearly as much effort as writing the prototype.
>>
>> yy[^W]Wp[ESC]A;[ESC]
>>
>> Job done, with 9 keypresses, all of which are in kinaesthetic memory and
>> thus come quickly and naturally. It would take me perhaps two seconds to
>> perform the above operation, one second on a good day, maybe three on a
>> bad day. How is that "nearly as much effort as writing"
>
> Since I've no idea what that sequence does, I can't say how it compares
> with the copy&paste I would have to do.
Copy, switch window, paste, append to line, semicolon, return to command
mode.
>
> If that 9-key sequence does the following:
>
> Wherever you are in or around the function in question, it:
>
> (1) Locates the first line of the function that contains the signature
No.
> (2) Copies the contents of that line
Yes.
> (3) Removes the { on the end if there is one
No, because I wasn't stupid enough to put one there.
> (4) Adds a ";" at the end (but before any comment)
There isn't a comment there, so yes.
> (5) Opens the header file where all shared prototypes reside (perhaps
> per module, perhaps per project)
No, I already have that open in the other window.
> (6) Locates the old version of the prototype
If you already have the prototype, what's your problem? You don't even
need copy and paste. But locating the old version is hardly difficult:
/text_to_search_for[ENTER]
> (7) Replaces that line with new version
If you're replacing it, the easiest way is probably just to delete it
and then paste the new one.
> (8) Closes the header file and gets you back to what you were doing.
Why would I want to close the header? I develop the interface and the
implementation in parallel. That's common sense.
>
> Then I would be very impressed. Because the above is what usually needs
> to be done even using copy&paste. Even more work if the signature spans
> more than one line.
It is true that 2yy is slightly longer to type than yy, but it's hardly
a big deal. I am beginning to wonder whether you are not rather annoyed
at the amount of energy it takes to drink coffee. There's all that
tedious lifting the cup up to mouth level, and then you have to tip the
cup, and then there's all that arduous swallowing and stuff...
> (A bit less work if doing this on a batch of
> brand-new functions.)
It's hardly any work at all, either way.
> If the change involves switching between static and non-static, which
> means moving the prototype between module and header, or changing the
> name of the function (making it harder to locate the old prototype),
> then it would be more impressive still.
It doesn't do that, but it's hardly necessary - those tasks are trivial too.
> But it seems to me that you are agreeing that maintaining function
> prototypes and keeping them in sync is a pain, otherwise why bother seek
> out a method that reduces the effort to 2-3 seconds per function?
I didn't seek out such a method. Having read your complaint, I thought
"is it really such a big deal?" and then I thought about how I would do
it, and then I thought "no, that isn't really such a big deal". Your
argument is akin to "you must agree with me that moving two yards is a
pain, otherwise why bother to seek out a method that reduces the effort
to 2-3 strides?" In other words, it's just wrong-headed.
> That's little different to my using an automatic tool that does the same
> (my tool would do all functions in a module in some 30ms iirc, and I
> wouldn't accidentally miss one out either).
I'm not aware of the existence of such a tool. If you have one, why not
just use it? But I wouldn't bother with such a tool myself.
As for accidentally missing one out, well, that's why we have diagnostic
messages.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-02 18:04 +0100 |
| Message-ID | <mumdc2$p54$1@dont-email.me> |
| In reply to | #71611 |
On 02/10/2015 15:31, Richard Heathfield wrote:
> On 02/10/15 13:24, Bartc wrote:
> Why would I want to close the header? I develop the interface and the
> implementation in parallel. That's common sense.
If they are always in parallel, that suggests they are really part of
the same thing. If I write 'int fn(int,double)' in one window, and that
must always be *exactly matched* by 'int fn(int,double)' in another,
then it is ludicrous to have to maintain that correspondence by hand.
Even with copy&paste.
>>
>> Then I would be very impressed. Because the above is what usually needs
>> to be done even using copy&paste. Even more work if the signature spans
>> more than one line.
>
> It is true that 2yy is slightly longer to type than yy, but it's hardly
> a big deal. I am beginning to wonder whether you are not rather annoyed
> at the amount of energy it takes to drink coffee. There's all that
> tedious lifting the cup up to mouth level, and then you have to tip the
> cup, and then there's all that arduous swallowing and stuff...
Sorry, but it is still quite a big deal. That 9-key sequence isn't the
whole story. You have to /make the effort to create the prototype/; it's
easy to forget. If one exists, you have to remember to update it (and
the compiler may not report an error). You have to navigate to the start
of the function. You have to have followed certain style guidelines by
not having { on the same lines and not using a comment. You need the
right header open in another window and positioned in the right place.
If the linkage changes, the editing is messier. *And* you to be using
the right sort of editor.
This is all dull, tedious stuff which people would much rather not have
to bother with. It is also still error prone.
> It doesn't do that, but it's hardly necessary - those tasks are trivial
> too.
Pretty much everything can be trivialised like that. But usually people
have bigger things to worry about when coding; why even have to /think/
about generating the prototype?
In the coding I do now, generating any prototypes needed by a C compiler
takes 0 keystrokes and it is impossible to forget to do or to generate
mismatched or out-of-sync ones (it's automatic). That is not the case
when the still largely manually method you use.
>> That's little different to my using an automatic tool that does the same
>> (my tool would do all functions in a module in some 30ms iirc, and I
>> wouldn't accidentally miss one out either).
>
> I'm not aware of the existence of such a tool. If you have one, why not
> just use it? But I wouldn't bother with such a tool myself.
Yes, I use such tools. Others are asking about using them too.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-02 18:21 +0100 |
| Message-ID | <mumeaj$t8p$1@dont-email.me> |
| In reply to | #71625 |
On 02/10/15 18:04, Bartc wrote: > On 02/10/2015 15:31, Richard Heathfield wrote: >> On 02/10/15 13:24, Bartc wrote: > >> Why would I want to close the header? I develop the interface and the >> implementation in parallel. That's common sense. > > If they are always in parallel, that suggests they are really part of > the same thing. They are different aspects of the same thing. One is a declaration, which is all the compiler needs for compiling some other module that uses this one. The other is a definition, which contains the implementation, which the compiler only needs to see when compiling /this/ module. > If I write 'int fn(int,double)' in one window, and that > must always be *exactly matched* by 'int fn(int,double)' in another, > then it is ludicrous to have to maintain that correspondence by hand. > Even with copy&paste. I don't share your opinion. I think it's a very mild irritation, at worst. >>> Then I would be very impressed. Because the above is what usually needs >>> to be done even using copy&paste. Even more work if the signature spans >>> more than one line. >> >> It is true that 2yy is slightly longer to type than yy, but it's hardly >> a big deal. I am beginning to wonder whether you are not rather annoyed >> at the amount of energy it takes to drink coffee. There's all that >> tedious lifting the cup up to mouth level, and then you have to tip the >> cup, and then there's all that arduous swallowing and stuff... > > Sorry, but it is still quite a big deal. I disagree. I think this is a storm in a teacup. <snip> > In the coding I do now, generating any prototypes needed by a C compiler > takes 0 keystrokes and it is impossible to forget to do or to generate > mismatched or out-of-sync ones (it's automatic). That is not the case > when the still largely manually method you use. Then you have a (for you) perfect solution, so what are you complaining about? <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-02 21:04 +0100 |
| Message-ID | <mumnsq$4kr$1@dont-email.me> |
| In reply to | #71628 |
On 02/10/2015 18:21, Richard Heathfield wrote: > On 02/10/15 18:04, Bartc wrote: >> Sorry, but it is still quite a big deal. > > I disagree. I think this is a storm in a teacup. Because /you/ have found a good way of dealing with the requirement? How much would you trust someone else working on the same code to keep the headers updated? >> In the coding I do now, generating any prototypes needed by a C compiler >> takes 0 keystrokes and it is impossible to forget to do or to generate >> mismatched or out-of-sync ones (it's automatic). That is not the case >> when the still largely manually method you use. > > Then you have a (for you) perfect solution, so what are you complaining > about? I've found my way of dealing with this. And you've found your way of doing so. That doesn't mean the problem just goes away for everyone else. I'm making the points for their benefit. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-10-03 08:29 +0200 |
| Message-ID | <munsit$7e8$1@speranza.aioe.org> |
| In reply to | #71638 |
On 02.10.2015 22:04, Bartc wrote: > On 02/10/2015 18:21, Richard Heathfield wrote: >> On 02/10/15 18:04, Bartc wrote: [...] >>> In the coding I do now, generating any prototypes needed by a C compiler >>> takes 0 keystrokes and it is impossible to forget to do or to generate >>> mismatched or out-of-sync ones (it's automatic). That is not the case >>> when the still largely manually method you use. >> >> Then you have a (for you) perfect solution, so what are you complaining >> about? > > I've found my way of dealing with this. And you've found your way of > doing so. That doesn't mean the problem just goes away for everyone > else. I'm making the points for their benefit. It might be very subjective what's a good way to do coding; another thing is that it becomes a bit meta.. because of this, it can be difficult to think alternative ways of coding. It's kind of like juggling two things at a time, when coding itself requires a lot of focus, who needs another moving target? That said, I like the idea of generating prototypes automatically, and if some developers get together to do something and work smart, it wouldn't be much effort on each. -Morten
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-03 16:47 +0200 |
| Message-ID | <muopmb$dpd$1@dont-email.me> |
| In reply to | #71638 |
On 02/10/15 22:04, Bartc wrote: > On 02/10/2015 18:21, Richard Heathfield wrote: >> On 02/10/15 18:04, Bartc wrote: > >>> Sorry, but it is still quite a big deal. >> >> I disagree. I think this is a storm in a teacup. > > Because /you/ have found a good way of dealing with the requirement? How > much would you trust someone else working on the same code to keep the > headers updated? I don't use a particular set of keyboard shortcuts to maintain consistency between prototypes in a header and definitions in the source code. I might do it in different ways in different editors and different OS's. I might do it at different times - perhaps writing one side of the pair long before writing the other one. And I think the whole issue is a storm in a teacup. The time taken to make such copies is totally negligible in programming. The effort and time in maintaining good structure and modularisation, and in writing clear and useful headers and implementations, is spend in the thought processes, deciding what to put in the different files, writing clear comments (which are usually completely different in the header and implementation), and so on. Copying a single line per function is a tiny part of this. > >>> In the coding I do now, generating any prototypes needed by a C compiler >>> takes 0 keystrokes and it is impossible to forget to do or to generate >>> mismatched or out-of-sync ones (it's automatic). That is not the case >>> when the still largely manually method you use. >> >> Then you have a (for you) perfect solution, so what are you complaining >> about? > > I've found my way of dealing with this. And you've found your way of > doing so. That doesn't mean the problem just goes away for everyone > else. I'm making the points for their benefit. >
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-03 17:37 +0100 |
| Message-ID | <mup042$5ul$1@dont-email.me> |
| In reply to | #71665 |
On 03/10/2015 15:47, David Brown wrote: > On 02/10/15 22:04, Bartc wrote: >> On 02/10/2015 18:21, Richard Heathfield wrote: >>> On 02/10/15 18:04, Bartc wrote: >> >>>> Sorry, but it is still quite a big deal. >>> >>> I disagree. I think this is a storm in a teacup. >> >> Because /you/ have found a good way of dealing with the requirement? How >> much would you trust someone else working on the same code to keep the >> headers updated? > > I don't use a particular set of keyboard shortcuts to maintain > consistency between prototypes in a header and definitions in the source > code. I might do it in different ways in different editors and > different OS's. I might do it at different times - perhaps writing one > side of the pair long before writing the other one. > > And I think the whole issue is a storm in a teacup. The time taken to > make such copies is totally negligible in programming. The effort and > time in maintaining good structure and modularisation, and in writing > clear and useful headers and implementations, is spend in the thought > processes, deciding what to put in the different files, writing clear > comments (which are usually completely different in the header and > implementation), and so on. Copying a single line per function is a > tiny part of this. I suppose if your normal development environment consists of elaborate compilers like gcc, make files, shell scripts, dozens of other utilities each with /their/ own syntax, then small chores such as constantly keeping header files updated from corresponding definitions would seem insignificant. But /my/ development environment is nothing like that. Switching from function definition to header file and back again is a damn nuisance when in you're in the middle of a complicated bit of development involving dozens of functions and don't want to break concentration. (I also like prototypes to be logically grouped in a way that matches the definitions, so means extra work when moving definitions around.) I know you write Python, so imagine that every time you dashed off another function 'def', or modified or deleted an existing one, you also had to update a manifest file elsewhere. Your productivity would take a sudden dive! Thanks to how I work, I haven't need to worry about such details for a few years. But clearly most experts posting here enjoy doing it. I suppose if you're paid by the hour then that could be another reason for liking to make to string things out! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-03 17:54 +0100 |
| Message-ID | <mup152$9r7$1@dont-email.me> |
| In reply to | #71679 |
On 03/10/15 17:37, Bartc wrote: <snip> > I suppose if your normal development environment consists of elaborate > compilers like gcc, make files, shell scripts, dozens of other utilities > each with /their/ own syntax, then small chores such as constantly > keeping header files updated from corresponding definitions would seem > insignificant. Here's my workflow for multi-file projects: $ makegen foo bar baz > Makefile This is a trivial C program that generates a very simple makefile. I wrote it myself, and it really didn't take very long to write. A few minutes, at most - and that, some years ago. I've been using it ever since. $ gvim foo.c This starts up a text editor. I trust you don't consider a text editor to be elaborate. Within the text editor, I split the window, with the upper window showing foo.h and the lower window showing foo.c. You might consider multi-window editors to be elaborate. Personally, I don't. I've been using multi-window editors since, er, about 1989 (Multi-Edit), and I regard them as being (a) simple to use and (b) essential tools. When I'm ready to compile, I use Alt-Tab to switch round to my console window, and type: $ make foo.o Once bar.c and baz.c are in place, of course, I can just type: $ make I don't consider this to be an "elaborate" development environment. On the contrary, it's rather spartan. > But /my/ development environment is nothing like that. Switching from > function definition to header file and back again is a damn nuisance > when in you're in the middle of a complicated bit of development > involving dozens of functions and don't want to break concentration. <shrug> ^WW works for me. Of course, that only switches /to/ the header window. Then I have to type ^WW *again* to get back to the source code. But it's a burden I bear with fortitude. > (I also like prototypes to be logically grouped in a way that matches > the definitions, so means extra work when moving definitions around.) Okay, so you've developed a house style that requires you to do a little extra work for, presumably, a pay-off in clarity. Fair enough. In gvim, moving a block of lines is trivial and quick. > > I know you write Python, so imagine that every time you dashed off > another function 'def', or modified or deleted an existing one, you also > had to update a manifest file elsewhere. Your productivity would take a > sudden dive! > > Thanks to how I work, I haven't need to worry about such details for a > few years. But clearly most experts posting here enjoy doing it. I > suppose if you're paid by the hour then that could be another reason for > liking to make to string things out! You make the normal way sound terribly long-winded, but it really truly isn't. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-04 18:16 +0200 |
| Message-ID | <murj9t$8o2$1@dont-email.me> |
| In reply to | #71679 |
On 03/10/15 18:37, Bartc wrote: > On 03/10/2015 15:47, David Brown wrote: >> On 02/10/15 22:04, Bartc wrote: >>> On 02/10/2015 18:21, Richard Heathfield wrote: >>>> On 02/10/15 18:04, Bartc wrote: >>> >>>>> Sorry, but it is still quite a big deal. >>>> >>>> I disagree. I think this is a storm in a teacup. >>> >>> Because /you/ have found a good way of dealing with the requirement? How >>> much would you trust someone else working on the same code to keep the >>> headers updated? >> >> I don't use a particular set of keyboard shortcuts to maintain >> consistency between prototypes in a header and definitions in the source >> code. I might do it in different ways in different editors and >> different OS's. I might do it at different times - perhaps writing one >> side of the pair long before writing the other one. >> >> And I think the whole issue is a storm in a teacup. The time taken to >> make such copies is totally negligible in programming. The effort and >> time in maintaining good structure and modularisation, and in writing >> clear and useful headers and implementations, is spend in the thought >> processes, deciding what to put in the different files, writing clear >> comments (which are usually completely different in the header and >> implementation), and so on. Copying a single line per function is a >> tiny part of this. > > I suppose if your normal development environment consists of elaborate > compilers like gcc, make files, shell scripts, dozens of other utilities > each with /their/ own syntax, then small chores such as constantly > keeping header files updated from corresponding definitions would seem > insignificant. You have a very warped idea of how other people work. My usual development process involves a makefile which invokes a few utilities (like sed, cp, rm, mkdir - and occasionally python scripts, though almost never any shell scripts) as needed. But working with these things is a very small proportion of my effort. When I start a new project, I will make a copy of a Makefile from a similar project. I will usually modify it a little, changing project names, perhaps changing options for the exact microcontroller, changing the different build options it will handle (often I build different variants of the project simultaneously), and perhaps changing the source directory names. After that, I rarely need to bother with the Makefile. Building is done by ctrl-B from my IDE, or typing "make" from the command line if needed. I don't even need to bother about adding new files to the Makefile - source code is found automatically. While gcc is arguably an "elaborate" compiler, the habit of putting function prototypes in a header file is hardly gcc-specific. And if you need to work constantly in keeping your prototypes up to date, then I suggest you have a very poorly structured development process - I rarely change the prototypes in a module's header, because I am not in the habit of re-arranging a module's API on a regular basis. Most functions, of course, are static within the implementation - there are not prototypes (other than the one at the definition) to synchronise. And (I think I mentioned this earlier), it is perfectly possible to work on the header files with the prototypes, and the implementation file, at different times. Either one can be written first. > > But /my/ development environment is nothing like that. Switching from > function definition to header file and back again is a damn nuisance > when in you're in the middle of a complicated bit of development > involving dozens of functions and don't want to break concentration. Perhaps if you use an editor more sophisticated than Notepad, you will find it is not that big a problem. Any serious editor is quite happy with having headers and implementation files open at the same time, and visible at the same time - as well as having multiple editing windows onto the same file. It should also handle things like navigation between headers and source, definitions and prototypes, and bookmarks. > > (I also like prototypes to be logically grouped in a way that matches > the definitions, so means extra work when moving definitions around.) I like my prototypes to be logically grouped. I also like my definitions to be logically grouped. But the grouping does not have to be the same. That means there is no extra work moving them around - I just write them in the correct place. > > I know you write Python, so imagine that every time you dashed off > another function 'def', or modified or deleted an existing one, you also > had to update a manifest file elsewhere. Your productivity would take a > sudden dive! No, my productivity would soar if I could write prototypes in Python. The biggest problem I have with Python is that you don't have prototypes or other tools for compile-time checking. > > Thanks to how I work, I haven't need to worry about such details for a > few years. But clearly most experts posting here enjoy doing it. I > suppose if you're paid by the hour then that could be another reason for > liking to make to string things out! > I'll take that last statement as a joke, rather than an insult to all the professional developers in this group.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-04 18:13 +0100 |
| Message-ID | <murmja$m9l$1@dont-email.me> |
| In reply to | #71820 |
On 04/10/2015 17:16, David Brown wrote: > On 03/10/15 18:37, Bartc wrote: >> I suppose if your normal development environment consists of elaborate >> compilers like gcc, make files, shell scripts, dozens of other utilities >> each with /their/ own syntax, then small chores such as constantly >> keeping header files updated from corresponding definitions would seem >> insignificant. > > You have a very warped idea of how other people work. Yet, I am expected to have to deal with all that every time I need to build someone's open source project. > My usual > development process involves a makefile which invokes a few utilities > (like sed, cp, rm, mkdir - and occasionally python scripts, > While gcc is arguably an "elaborate" compiler, the habit of putting > function prototypes in a header file is hardly gcc-specific. No, but having to grapple with a recalcitrant compiler bristling with options might overshadow the effort of generating up-to-date headers. > And if you need to work constantly in keeping your prototypes up to > date, then I suggest you have a very poorly structured development > process - I rarely change the prototypes in a module's header, because I > am not in the habit of re-arranging a module's API on a regular basis. You work differently then. I need to add parameters, change a return type, make a static function global, consolidate two functions into one, or vice versa... Each type the prototype(s), wherever they happen to be, have to change. > Most functions, of course, are static within the implementation - there > are not prototypes (other than the one at the definition) to synchronise. Again that's not my experience. But I also use prototypes for static functions. Then I need pay no attention to the order that definitions occur in. >> But /my/ development environment is nothing like that. Switching from >> function definition to header file and back again is a damn nuisance >> when in you're in the middle of a complicated bit of development >> involving dozens of functions and don't want to break concentration. > > Perhaps if you use an editor more sophisticated than Notepad, you will > find it is not that big a problem. Both my editor and IDE are crude, but switching between related projects is a single keypress. I've designed out the concept of function prototypes as far as /I'm/ concerned (actually, the concept of header files too, now), so at least that part of it I don't need to deal with. > Any serious editor is quite happy > with having headers and implementation files open at the same time, and > visible at the same time (Non-serious ones too; you just have multiple instances.) - as well as having multiple editing windows > onto the same file. It should also handle things like navigation > between headers and source, definitions and prototypes, and bookmarks. I'm surprised that all these sophisticated tools you're always talking about, can't automate the generation of prototype headers without any manual intervention. Is there anything that a highly competent developer, whose time is valuable, can add to a function prototype that an automatic process couldn't? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-04 18:22 +0100 |
| Message-ID | <murn5n$oi2$1@dont-email.me> |
| In reply to | #71825 |
On 04/10/15 18:13, Bartc wrote: <snip> > I'm surprised that all these sophisticated tools you're always talking > about, can't automate the generation of prototype headers without any > manual intervention. No point. It's so easy to do by hand. It would be like automating the typing of the = character. > Is there anything that a highly competent > developer, whose time is valuable, can add to a function prototype that > an automatic process couldn't? For one thing, he can contribute the absence of a pointless and possibly error-prone automatic process. You seem to be determined to fill the proverbial much-needed gap. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-04 20:17 +0100 |
| Message-ID | <murtsp$lbc$1@dont-email.me> |
| In reply to | #71827 |
On 04/10/2015 18:22, Richard Heathfield wrote:
> On 04/10/15 18:13, Bartc wrote:
>
> <snip>
>
>> I'm surprised that all these sophisticated tools you're always talking
>> about, can't automate the generation of prototype headers without any
>> manual intervention.
>
> No point. It's so easy to do by hand. It would be like automating the
> typing of the = character.
I thought you needed 9 keystrokes (plus for certain conditions to be
true such as being at the right place)?
Automating "=" in a way that requires you to be in the right location
for the "=", and to invoke each insertion with a key-press, would be
pointless.
(";" might be a better candidate for automatic insertion, if it saves a
keystroke. When you're suffering from RSI later in life it might seem a
better idea than it does now. But I wouldn't be surprised if some
editors already do exactly this (insert ";" when Enter is pressed),
*and* automatically tab to the correct indent.)
>> Is there anything that a highly competent
>> developer, whose time is valuable, can add to a function prototype that
>> an automatic process couldn't?
> For one thing, he can contribute the absence of a pointless and possibly
> error-prone automatic process. You seem to be determined to fill the
> proverbial much-needed gap.
OK, you're saying that an automatic procedure could be more error prone
than doing it manually, by having to type a 9-key sequences hundreds of
times (plus all those conditions and needing to remember to actually do it)?
Just so we're clear!
Ian Collins might also like to know that his more automated 2-keystroke
macro to do the job might not be as reliable as your method.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-04 21:07 +0100 |
| Message-ID | <mus0qp$1lc$1@dont-email.me> |
| In reply to | #71841 |
On 04/10/15 20:17, Bartc wrote:
> On 04/10/2015 18:22, Richard Heathfield wrote:
>> On 04/10/15 18:13, Bartc wrote:
>>
>> <snip>
>>
>>> I'm surprised that all these sophisticated tools you're always talking
>>> about, can't automate the generation of prototype headers without any
>>> manual intervention.
>>
>> No point. It's so easy to do by hand. It would be like automating the
>> typing of the = character.
>
> I thought you needed 9 keystrokes (plus for certain conditions to be
> true such as being at the right place)?
"Like" doesn't mean "exactly equal to".
> Automating "=" in a way that requires you to be in the right location
> for the "=", and to invoke each insertion with a key-press, would be
> pointless.
Yep.
> (";" might be a better candidate for automatic insertion, if it saves a
> keystroke. When you're suffering from RSI later in life it might seem a
> better idea than it does now. But I wouldn't be surprised if some
> editors already do exactly this (insert ";" when Enter is pressed),
> *and* automatically tab to the correct indent.)
They'd have to be pretty clever to know when you /don't/ want a
semicolon, or they'd turn this:
verydescriptivename = otherverydescriptivename
+ thirdverydescriptivename;
into this:
verydescriptivename = otherverydescriptivename;
+ thirdverydescriptivename;;
>>> Is there anything that a highly competent
>>> developer, whose time is valuable, can add to a function prototype that
>>> an automatic process couldn't?
>
>> For one thing, he can contribute the absence of a pointless and possibly
>> error-prone automatic process. You seem to be determined to fill the
>> proverbial much-needed gap.
>
> OK, you're saying that an automatic procedure could be more error prone
> than doing it manually, by having to type a 9-key sequences hundreds of
> times (plus all those conditions and needing to remember to actually do
> it)?
I get that you think it's hard work. Do you get that I think it isn't?
You are trying to make it sound a lot harder than it really is, and I
don't see why you're trying to do that. Do you really, truly find it so
arduous, when almost nobody else seems to?
> Just so we're clear!
Well, no, we're not clear yet. You seem to be trying to ridicule a
manual process simply because it /is/ manual, by making it out to be
much more difficult and tedious than it actually is.
Okay, if you have hundreds to do at once, I would see your point. But
most developers with any sense /don't/ have hundreds to do at once,
because compiling is like voting - compile early, compile often - so we
generally do the prototypes in parallel with the implementation.
> Ian Collins might also like to know that his more automated 2-keystroke
> macro to do the job might not be as reliable as your method.
I think Ian Collins is more than capable of deciding for himself the
best way to add prototypes to his headers. I don't recall whether he
actually claimed to use a macro or whether he was simply saying it was
possible. But, however he does it, I bet he doesn't think of it as a
bottleneck.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-04 22:10 +0100 |
| Message-ID | <mus4ha$h50$1@dont-email.me> |
| In reply to | #71845 |
On 04/10/2015 21:07, Richard Heathfield wrote:
> On 04/10/15 20:17, Bartc wrote:
>> (";" might be a better candidate for automatic insertion, if it saves a
>> keystroke. When you're suffering from RSI later in life it might seem a
>> better idea than it does now. But I wouldn't be surprised if some
>> editors already do exactly this (insert ";" when Enter is pressed),
>> *and* automatically tab to the correct indent.)
>
> They'd have to be pretty clever to know when you /don't/ want a
> semicolon, or they'd turn this:
>
> verydescriptivename = otherverydescriptivename
> + thirdverydescriptivename;
>
> into this:
>
> verydescriptivename = otherverydescriptivename;
> + thirdverydescriptivename;;
I would expect an editor that can understand C syntax to do better than
just automatically insert ";" every time someone presses Enter.
Like the automatic tabbing which doesn't know it's reached the end of
the block and you have to correct it, sometimes it will get it wrong and
need cancelling.
It wouldn't be hard to have a few rules in place so that it gets it
right /most of the time/. (So, not when the last token on the line is
already ";" for example.) It would also work better when expressions are
split like this:
a = b +
c
instead of:
a = b
+ c
> I get that you think it's hard work.
No, more that it's unnecessary and error prone, no matter how much you
can reduce down to some small number of repetitive actions. Unless of
course those actions do end up properly automating the task.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-05 09:24 +1300 |
| Message-ID | <d7dg8mFehacU2@mid.individual.net> |
| In reply to | #71841 |
Bartc wrote: > > Ian Collins might also like to know that his more automated 2-keystroke > macro to do the job might not be as reliable as your method. Which macro would that be? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-04 22:15 +0100 |
| Message-ID | <mus4pn$i36$1@dont-email.me> |
| In reply to | #71847 |
On 04/10/2015 21:24, Ian Collins wrote: > Bartc wrote: >> >> Ian Collins might also like to know that his more automated 2-keystroke >> macro to do the job might not be as reliable as your method. > > Which macro would that be? You said this: > An reasonable editor or IDE can do the mechanical refactoring of the > function declaration and definition in a couple of keystrokes and/or > mouse clicks. Updating the function's callers is another story. Since it is impossible to do what is necessary in just two keystrokes, it must invoke some sort of command or macro to do the job. (I didn't mean a C macro.) -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 11 of 17 — ← Prev page 1 … 9 10 [11] 12 13 … 17 Next page →
Back to top | Article view | comp.lang.c
csiph-web