Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #77503 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2015-12-01 12:52 +0000 |
| Last post | 2015-12-01 12:24 -0800 |
| Articles | 20 on this page of 151 — 24 participants |
Back to article view | Back to comp.lang.c
// comments and \ BartC <bc@freeuk.com> - 2015-12-01 12:52 +0000
Re: // comments and \ me <self@example.org> - 2015-12-01 13:08 +0000
Re: // comments and \ Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-01 08:20 -0500
Re: // comments and \ me <self@example.org> - 2015-12-01 13:36 +0000
Re: // comments and \ Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-01 09:03 -0500
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 14:14 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 07:40 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 08:55 -0800
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 17:15 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 09:58 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 18:11 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 10:18 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 18:20 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 11:07 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 11:39 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 12:33 -0800
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 01:05 +0000
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 19:30 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-01 20:59 +0100
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-01 15:22 -0500
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 20:37 +0000
Re: // comments and \ Robert Wessel <robertwessel2@yahoo.com> - 2015-12-01 14:56 -0600
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-01 22:11 +0100
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 03:01 -0800
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 00:45 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 07:52 -0700
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 15:19 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 08:29 -0700
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 15:35 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 09:21 -0700
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 16:41 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 10:15 -0700
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 17:24 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 17:43 +0000
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 03:05 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-02 11:40 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-02 04:29 -0800
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 19:11 +0000
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-01 20:43 +0000
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 21:04 +0000
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-01 21:16 +0000
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 03:12 -0800
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-02 11:52 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-02 04:40 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-02 13:55 +0100
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-02 13:56 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-02 15:24 +0100
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 06:54 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-02 16:40 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-02 18:24 +0000
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-02 20:27 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 23:22 -0800
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-03 00:57 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-03 23:44 +0000
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-03 21:17 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 00:43 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 20:32 -0600
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 16:06 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-05 13:10 -0600
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 10:18 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-06 14:26 -0600
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-03 12:45 +0100
Re: // comments and \ raltbos@xs4all.nl (Richard Bos) - 2015-12-04 11:45 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-04 04:20 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 14:20 +0100
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-04 10:05 -0500
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 17:31 +0100
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 17:24 -0600
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-04 18:50 -0500
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 20:34 -0600
Re: // comments and \ raltbos@xs4all.nl (Richard Bos) - 2015-12-10 20:40 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-04 09:36 -0800
Re: // comments and \ Richard Damon <Richard@Damon-Family.org> - 2015-12-05 09:05 -0500
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 17:42 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-06 22:23 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-07 21:59 +0000
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 15:50 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-05 18:17 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 10:01 +0000
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-06 03:05 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 04:07 -0800
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-06 04:37 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 05:05 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-06 12:19 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 13:59 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 06:09 -0800
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-06 07:30 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 18:55 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-06 12:23 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-06 12:22 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 21:06 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-05 13:14 -0600
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 10:09 +0000
Re: // comments and \ mark.bluemel@gmail.com - 2015-12-03 06:15 -0800
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-02 08:28 -0700
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 09:01 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-02 21:52 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 16:55 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-03 13:11 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-03 23:21 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 11:22 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 01:12 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 20:39 -0600
Re: // comments and \ raltbos@xs4all.nl (Richard Bos) - 2015-12-04 11:14 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-04 12:25 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 14:23 +0100
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 09:00 -0800
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 19:46 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 20:36 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 20:37 -0700
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 14:26 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 14:32 +0000
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 14:52 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-01 16:15 +0100
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 15:28 +0000
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 01:26 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 09:12 -0800
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 19:17 +0000
Re: // comments and \ Robert Wessel <robertwessel2@yahoo.com> - 2015-12-01 12:32 -0600
Re: // comments and \ Nobody <nobody@nowhere.invalid> - 2015-12-02 00:01 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 07:08 -0800
Re: // comments and \ Nobody <nobody@nowhere.invalid> - 2015-12-02 21:05 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 14:22 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 14:48 -0800
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 23:37 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 17:10 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-02 19:24 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-03 04:10 +0000
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 21:49 -0800
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-03 07:28 -0700
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 09:12 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 06:53 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 15:41 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-03 15:56 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 16:44 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-03 17:29 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 19:10 -0800
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 21:59 -0800
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 07:52 -0700
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 09:21 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 17:26 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 10:50 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 10:49 -0800
Re: // comments and \ Geoff <geoff@invalid.invalid> - 2015-12-01 11:34 -0800
Re: // comments and \ David Thompson <dave.thompson2@verizon.net> - 2015-12-22 06:44 -0500
Re: // comments and \ "Charles Richmond" <numerist@aquaporin4.com> - 2015-12-23 14:35 -0600
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-23 13:00 -0800
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-23 16:58 -0500
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-23 14:21 -0800
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-23 16:55 -0500
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-01 12:24 -0800
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-04 11:22 +0100 |
| Message-ID | <n3rpd7$1k3$1@dont-email.me> |
| In reply to | #77782 |
On 04/12/15 00:21, Jorgen Grahn wrote: > On Thu, 2015-12-03, David Brown wrote: >> On 03/12/15 01:55, Keith Thompson wrote: >>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes: >>>> On Wed, 2015-12-02, Keith Thompson wrote: >>> [...] >>>>> (SVN, as I understand it, >>>>> doesn't support branches directly; there are conventions that >>>>> involve making copies of the entire source tree, which SVN is able >>>>> to store efficiently.) >>>> >>>> If that's true, then it's ironic: CVS has poor branching support, and >>>> that was the primary flaw that SVN was supposed to fix. > ... >> SVN was designed to fix a great number of flaws (or at least, perceived >> flaws) in CVS. As far as I know, branching was not the main issue. To >> me, the main issue is that CVS works file-by-file, while SVN works as >> transactions on the whole repository. > > A focus on branching was how I percieved it back then, but > it might have been > a) The people I was talking to (on comp.software.config-mgmt). > b) Besides CVS, I was used to ClearCase which had good branching > support (but very different from Git's) which I used all the > time. That was the main flaw in CVS, as far as I was concerned. > Different people use different models for these things. Some people use branching all the time in svn - but most users don't do it much. Part of this may also be the type of development tools you use along with the files. If you are using a big all-inclusive IDE with project management, etc., then switching branches is typically not a streamlined task - the IDE likes to think that /it/ is in control of all the files, not an external program. But non-branching development (make changes, save, compile, test, check-in) works smoothly. On the other hand, if you are working with make, and editors made with a multi-tool environment in mind, then swapping files in and out with branches is going to be fine.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-05 01:12 +0000 |
| Message-ID | <slrnn64efn.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77801 |
On Fri, 2015-12-04, David Brown wrote: > On 04/12/15 00:21, Jorgen Grahn wrote: >> On Thu, 2015-12-03, David Brown wrote: >>> On 03/12/15 01:55, Keith Thompson wrote: >>>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes: >>>>> On Wed, 2015-12-02, Keith Thompson wrote: >>>> [...] >>>>>> (SVN, as I understand it, >>>>>> doesn't support branches directly; there are conventions that >>>>>> involve making copies of the entire source tree, which SVN is able >>>>>> to store efficiently.) >>>>> >>>>> If that's true, then it's ironic: CVS has poor branching support, and >>>>> that was the primary flaw that SVN was supposed to fix. >> ... >>> SVN was designed to fix a great number of flaws (or at least, perceived >>> flaws) in CVS. As far as I know, branching was not the main issue. To >>> me, the main issue is that CVS works file-by-file, while SVN works as >>> transactions on the whole repository. >> >> A focus on branching was how I percieved it back then, but >> it might have been >> a) The people I was talking to (on comp.software.config-mgmt). >> b) Besides CVS, I was used to ClearCase which had good branching >> support (but very different from Git's) which I used all the >> time. That was the main flaw in CVS, as far as I was concerned. >> > > Different people use different models for these things. Some people use > branching all the time in svn - but most users don't do it much. In a way, I like the latter approach. At least you won't fall into the trap where different teams work in different directions and forget to integrate their changes with each other. But sometimes you need to have a little time without disturbances from the outside. Back when CVS was the best free revision control tool, people spent a lot of energy trying to make branching work. The problem was keeping track of the baseline of branches -- the merge algorithm needs to know the latest common ancestor of two branches, but CVS didn't keep track of that. > Part of this may also be the type of development tools you use along > with the files. If you are using a big all-inclusive IDE with project > management, etc., then switching branches is typically not a streamlined > task - the IDE likes to think that /it/ is in control of all the files, > not an external program. If an IDE works that way, I think it's unsuitable for general use in a real project. IMO, an IDE which doesn't integrate with version control is a joke. Eclipse seems to work, with some glitches. I've seen coworkers use it, and the only problem seems to be that when you switch branches, it pops up a dialogue for each file: "OMG! This file suddenly changed! Should I panic or not?" Emacs (and I suppose other sane editors) is aware that there are other programs which may change files. > But non-branching development (make changes, save, compile, test, > check-in) works smoothly. On the other hand, if you are working > with make, and editors made with a multi-tool environment in mind, > then swapping files in and out with branches is going to be fine. Especially if the version control tool handles file modification time the way Git does. With ClearCase, you always had to 'make clean' when you switched branches, since files could get an /older/ modification time when their contents changed. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-12-04 20:39 -0600 |
| Message-ID | <n3tib4$vku$1@dont-email.me> |
| In reply to | #77865 |
Jorgen Grahn wrote: > On Fri, 2015-12-04, David Brown wrote: >> On 04/12/15 00:21, Jorgen Grahn wrote: >>> On Thu, 2015-12-03, David Brown wrote: >>>> On 03/12/15 01:55, Keith Thompson wrote: >>>>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes: >>>>>> On Wed, 2015-12-02, Keith Thompson wrote: >>>>> [...] >>>>>>> (SVN, as I understand it, >>>>>>> doesn't support branches directly; there are conventions that >>>>>>> involve making copies of the entire source tree, which SVN is able >>>>>>> to store efficiently.) >>>>>> >>>>>> If that's true, then it's ironic: CVS has poor branching support, and >>>>>> that was the primary flaw that SVN was supposed to fix. >>> ... >>>> SVN was designed to fix a great number of flaws (or at least, perceived >>>> flaws) in CVS. As far as I know, branching was not the main issue. To >>>> me, the main issue is that CVS works file-by-file, while SVN works as >>>> transactions on the whole repository. >>> >>> A focus on branching was how I percieved it back then, but >>> it might have been >>> a) The people I was talking to (on comp.software.config-mgmt). >>> b) Besides CVS, I was used to ClearCase which had good branching >>> support (but very different from Git's) which I used all the >>> time. That was the main flaw in CVS, as far as I was concerned. >>> >> >> Different people use different models for these things. Some people use >> branching all the time in svn - but most users don't do it much. > > In a way, I like the latter approach. At least you won't fall into > the trap where different teams work in different directions and forget > to integrate their changes with each other. But sometimes you need to > have a little time without disturbances from the outside. > > Back when CVS was the best free revision control tool, people spent a > lot of energy trying to make branching work. I just never had problems with this, but I grew up doing manual merges. > The problem was keeping > track of the baseline of branches -- the merge algorithm needs to know > the latest common ancestor of two branches, but CVS didn't keep track > of that. > No, it did not, but it wasn't a huge pain to do manually. The team was small enough that we'd basically coordinate commits out of band of the version control system. >> Part of this may also be the type of development tools you use along >> with the files. If you are using a big all-inclusive IDE with project >> management, etc., then switching branches is typically not a streamlined >> task - the IDE likes to think that /it/ is in control of all the files, >> not an external program. > > If an IDE works that way, I think it's unsuitable for general use in a > real project. IMO, an IDE which doesn't integrate with version > control is a joke. > *Sigh*. I don't completely agree, but again, my work flow is such that I don't worry about manual merges ( for which vi is best, IMO ). > Eclipse seems to work, with some glitches. I've seen coworkers use > it, and the only problem seems to be that when you switch branches, it > pops up a dialogue for each file: "OMG! This file suddenly changed! > Should I panic or not?" > Heh. Yep. Although I've always run different branches in different directories. > Emacs (and I suppose other sane editors) is aware that there are other > programs which may change files. > >> But non-branching development (make changes, save, compile, test, >> check-in) works smoothly. On the other hand, if you are working >> with make, and editors made with a multi-tool environment in mind, >> then swapping files in and out with branches is going to be fine. > > Especially if the version control tool handles file modification time > the way Git does. With ClearCase, you always had to 'make clean' when > you switched branches, since files could get an /older/ modification > time when their contents changed. > Yep. ClearCase is really better for managing document version control than source code. > /Jorgen > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-12-04 11:14 +0000 |
| Message-ID | <56617573.3806640@news.xs4all.nl> |
| In reply to | #77527 |
Richard Heathfield <rjh@cpax.org.uk> wrote: > On 01/12/15 16:21, Joe Pfeiffer wrote: > > > > I like [ // comments ] for two reasons -- > > > > I don't have to look for the end of a comment block. It's just a block > > of // > > Syntax colouring? :-) Syntax colouring doesn't work on print-outs. Me, I use /* */ for a semantic comment on a section of code, // for a quick clarification of a single detail. Richard
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-12-04 12:25 +0000 |
| Message-ID | <n3s0jc$qr2$1@dont-email.me> |
| In reply to | #77807 |
On 04/12/15 11:14, Richard Bos wrote: <snip> > Syntax colouring doesn't work on print-outs. Yes it does. All you need is a box of crayons and a bored six-year-old. -- 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-12-04 14:23 +0100 |
| Message-ID | <n3s40o$8gk$2@dont-email.me> |
| In reply to | #77807 |
On 04/12/15 12:14, Richard Bos wrote: > Richard Heathfield <rjh@cpax.org.uk> wrote: > >> On 01/12/15 16:21, Joe Pfeiffer wrote: >>> >>> I like [ // comments ] for two reasons -- >>> >>> I don't have to look for the end of a comment block. It's just a block >>> of // >> >> Syntax colouring? :-) > > Syntax colouring doesn't work on print-outs. It doesn't work very well if your colour scheme is yellow-on-black. But colour printers are fairly common these days, and even with black-and-white printers, grey levels can be useful (like comments in grey). > > Me, I use /* */ for a semantic comment on a section of code, // for a > quick clarification of a single detail. > > Richard >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-01 09:00 -0800 |
| Message-ID | <lnr3j6umsc.fsf@kst-u.example.com> |
| In reply to | #77525 |
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
>> For some reason, //
>> comments are enormously popular.)
>
> I like them for two reasons --
>
> I don't have to look for the end of a comment block. It's just a block
> of //
Agreed, I prefer end-of-line comments for that reason.
> If I'm in the throes of debugging I can comment out a bunch of code with
> /* */ without a comment throwing in a monkey wrench.
You can also use "#if 0" and "#endif" for that. Or you can insert
"//" at the beginning of each line (if your editor makes that an O(N)
operation, you need a better editor).
I have a script that surrounds a block of text with "#if 0" and
"#endif /* 0 */", and also inserts a "*" at the beginning of
each line, so I can see at a glance that the block is disabled.
Another script reverses that.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-01 19:46 +0000 |
| Message-ID | <87h9k2c5p6.fsf@bsb.me.uk> |
| In reply to | #77522 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 01/12/15 15:29, Joe Pfeiffer wrote: >> [...] I don't think I've *ever* seen >> a continued // comment before this thread. > > I first heard of it in about 1991/2, in C++ rather than C. The product > was Oracle Data Query, and the problem code looked something like > this: > > foo(path); // for unit testing, use c:\odq\dev\ut\foo\ > bar(); > baz(); > > and the code jumped straight from foo() to baz() without ever entering > bar(). It took a *long* time to spot the problem, The compiler did not warn you? No one looking at the code knew the rule? It seems like such an old chestnut to me that I'm a bit surprised. > after which the > house style guidelines were amended to outlaw // comments. Why not outlaw \ at the end of a comment line? Indeed, since everyone working on the code has to know the style guide, why not use it to educate everyone and include "remember, \ at the end of a line marks a continuation -- only use it when you mean to"? (As you might have guessed, I dislike dumbed-down style guides as much as you dislike // comments.) <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-12-01 20:36 +0000 |
| Message-ID | <n3l08k$t5i$1@dont-email.me> |
| In reply to | #77554 |
On 01/12/15 19:46, Ben Bacarisse wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >> On 01/12/15 15:29, Joe Pfeiffer wrote: >>> [...] I don't think I've *ever* seen >>> a continued // comment before this thread. >> >> I first heard of it in about 1991/2, in C++ rather than C. The product >> was Oracle Data Query, and the problem code looked something like >> this: >> >> foo(path); // for unit testing, use c:\odq\dev\ut\foo\ >> bar(); >> baz(); >> >> and the code jumped straight from foo() to baz() without ever entering >> bar(). It took a *long* time to spot the problem, > > The compiler did not warn you? It wasn't my code, but no, no warning was issued. (I have no doubt that C++ diagnostics have improved over the intervening years.) > No one looking at the code knew the rule? Yes, but the team whose code it was simply didn't associate the MS-DOS (and Windows 3.1) path separator with the line splicing character. They looked and looked at the two lines, and they just tuned out the comment mentally - if they looked at it at all, all they saw was a pathname, which obviously had nothing to do with the problem. (Non-obviously it did, as it turned out.) They did /eventually/ see the problem, of course, but I remember Steve telling me it took a couple of *days*. > It seems like such an old chestnut to me that I'm a bit > surprised. 23 years ago, it was a slightly younger chestnut. > >> after which the >> house style guidelines were amended to outlaw // comments. > > Why not outlaw \ at the end of a comment line? Fair question. I don't know the answer. I'm not sure it was even raised. > (As you might have guessed, I dislike dumbed-down style guides as much > as you dislike // comments.) Actually, I have nothing against them in C++. If they'd been in C90, I'd have been perfectly happy with them in C. As for style guides, the first step an experienced programmer should take on being given a style guide is to annotate a copy with 50 suggestions for improvement and submit it to the project manager. You won't win all 50, but you can normally get rid of 10 or 15 Really Daft Ideas quite easily. -- 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 | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2015-12-01 20:37 -0700 |
| Message-ID | <1by4ddcygc.fsf@pfeifferfamily.net> |
| In reply to | #77522 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 01/12/15 15:29, Joe Pfeiffer wrote: >> [...] I don't think I've *ever* seen >> a continued // comment before this thread. > > I first heard of it in about 1991/2, in C++ rather than C. The product > was Oracle Data Query, and the problem code looked something like > this: > > foo(path); // for unit testing, use c:\odq\dev\ut\foo\ > bar(); > baz(); > > and the code jumped straight from foo() to baz() without ever entering > bar(). It took a *long* time to spot the problem, after which the > house style guidelines were amended to outlaw // comments. (I doubt > very much whether that is still the case, though. For some reason, // > comments are enormously popular.) It took me a while to figure out why this bugged me -- this isn't a continued // comment in the sense of deliberately using \ to continue a comment to the next line (as I meant), this is being bitten by an unintended consequence of the syntax. It seems like the right way to fix this in a style guide is by requiring that quotes in comments be quoted, eg foo(path); // for unit testing, use "c:\odq\dev\ut\foo\"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-01 14:26 +0000 |
| Message-ID | <n3kahr$2h2$1@dont-email.me> |
| In reply to | #77503 |
On 01/12/2015 13:19, Stefan Ram wrote:
> BartC <bc@freeuk.com> writes:
>> // this is a comment ... \
>> puts("Hi!");
>> But, is there any reason for it to behave this way?
>
> The reason is /you/. After all, /you/ chose
> to use this language »C«.
...
> Choose another language and get another behavior.
Actually I /was/ using another language when it bit me (Nasm). (I wonder
where they got the idea from...?)
> And you surely know at that point in time that:
>
> »5.1.1.2 Translation phases
> 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.
>
> 3. The source file is decomposed into preprocessing
> tokens) and sequences of white-space characters
> (including comments).«
OK, so it does this because of X, Y and Z. But that doesn't mean it
makes practical sense.
(I then started thinking about why C needs line continuation anyway,
outside of multi-line macros, since it's free-format and newlines are
just white space. And I discovered this:
int million = 1000000;
can be split across lines like so:
i\
nt mill\
ion = 1\
0\
0\
00\
00;
While ++a can written as:
+\
+a
So \ can be be used to split tokens across lines. I never knew that!
(And probably not likely to find out /why/, except that it says so in
the standard.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-12-01 14:32 +0000 |
| Message-ID | <n3kata$43k$1@dont-email.me> |
| In reply to | #77510 |
On 01/12/15 14:26, BartC wrote: <snip> > So \ can be be used to split tokens across lines. I never knew that! > (And probably not likely to find out /why/, except that it says so in > the standard.) Macros have to be on a single line, or the preprocessor gets confused. On some systems there can be a maximum source code line length (IBM mainframe editors spring to mind). Sometimes we want to write macros that are longer than that maximum. Line splicing allows us to do this without upsetting the preprocessor. -- 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-12-01 14:52 +0000 |
| Message-ID | <n3kc2m$8q7$1@dont-email.me> |
| In reply to | #77510 |
On 01/12/2015 14:33, Stefan Ram wrote: > BartC <bc@freeuk.com> writes: >> And probably not likely to find out /why/ > > I am sure the first thing you tried in order to find out why > is to do the obvious: read the rationale of the committee, the > > Rationale for > International Standard > Programming Languages > C > > Revision 2 > 20 October 1999 > > . But for some reason you must have missed the paragraph: > > »A backslash immediately before a newline has long > been used to continue string literals, as well as > preprocessing command lines. In the interest of easing > machine generation of C, and of transporting code to > machines with restrictive physical line lengths, the C89 > Committee generalized this mechanism to permit any token > to be continued by interposing a backslash/newline > sequence.«, 5.1.1.2l29 There are two kinds of tokens where you might not have a choice in limiting how long they might be. One is string literals, but these can already be split up into multiple strings. The other is floating point constants that are very large or very small. But the limited precision available means they are probably best written in scientific notation. Then there are multiple leading zeros on integer constants (which will be octal). And identifiers so long that they have to be split into more or more segments across multiple lines! So I'm struggling to see a real need to for splitting up tokens with \. I'm not sure what is meant by a restricted line length; some display units may have such a restriction but the data being displayed won't (it would use scrolling or wrapping). So, is token-splitting there to cater for one of those rare machines (to compile in this case rather than to execute on), which doesn't actually exist anywhere? Even if there was such a need, what happens when someone acquires normal C source from elsewhere, and tries to use it on one of these machines which a 16-character hard limit on line lengths; it just wouldn't work unless the source is heavily edited to add \ everywhere. The idea is senseless IMO. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-01 16:15 +0100 |
| Message-ID | <n3kdev$ecg$1@dont-email.me> |
| In reply to | #77515 |
On 01/12/15 15:52, BartC wrote: > On 01/12/2015 14:33, Stefan Ram wrote: >> BartC <bc@freeuk.com> writes: >>> And probably not likely to find out /why/ >> >> I am sure the first thing you tried in order to find out why >> is to do the obvious: read the rationale of the committee, the >> >> Rationale for >> International Standard >> Programming Languages >> C >> >> Revision 2 >> 20 October 1999 >> >> . But for some reason you must have missed the paragraph: >> >> »A backslash immediately before a newline has long >> been used to continue string literals, as well as >> preprocessing command lines. In the interest of easing >> machine generation of C, and of transporting code to >> machines with restrictive physical line lengths, the C89 >> Committee generalized this mechanism to permit any token >> to be continued by interposing a backslash/newline >> sequence.«, 5.1.1.2l29 > > There are two kinds of tokens where you might not have a choice in > limiting how long they might be. > > One is string literals, but these can already be split up into multiple > strings. > > The other is floating point constants that are very large or very small. > But the limited precision available means they are probably best written > in scientific notation. > > Then there are multiple leading zeros on integer constants (which will > be octal). And identifiers so long that they have to be split into more > or more segments across multiple lines! > > So I'm struggling to see a real need to for splitting up tokens with \. > The rational mentions machine-generated C code. As far as I can guess, the idea of being able to spit /anything/ with \ is to allow automatic line splits without any parsing. So if you wanted to limit your line lengths to 40 characters (for example), then you could write a simple program that reads each line of the original source, and splits them into groups of 39 characters with a \ tagged on the end. It can probably be done with a couple of lines of awk or perl. And if you have a C code generator of some kind, it would be easy to have such a filter on the output routines. But if you have to ensure that "++" is split either before or after the token, and not in the middle, then you need parsing of some kind. I agree that no sane programmer would split tokens with \ when writing the code manually. > I'm not sure what is meant by a restricted line length; some display > units may have such a restriction but the data being displayed won't (it > would use scrolling or wrapping). Some editors have restrictions on line length. Perhaps some OS's do too - although they are not so common now, some systems stored files in specific fixed formats, that could have maximum line lengths. Normally, of course, you would just manually split the line at an appropriate point - you only need the \ for multi-line macros. And if you avoid // comments in such multi-line macros, you have avoided the problem. > > So, is token-splitting there to cater for one of those rare machines (to > compile in this case rather than to execute on), which doesn't actually > exist anywhere? It is an effect of the choice of translation phase used. > > Even if there was such a need, what happens when someone acquires normal > C source from elsewhere, and tries to use it on one of these machines > which a 16-character hard limit on line lengths; it just wouldn't work > unless the source is heavily edited to add \ everywhere. The idea is > senseless IMO. > Call it "historical" or "outdated" rather than senseless. And simply avoid mixing // and a trailing \ on the same line.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-12-01 15:28 +0000 |
| Message-ID | <n3ke5j$h43$1@dont-email.me> |
| In reply to | #77515 |
On 01/12/15 14:52, BartC wrote: <snip> > I'm not sure what is meant by a restricted line length; some display > units may have such a restriction but the data being displayed won't (it > would use scrolling or wrapping). Consider, for example, source code stored in a PDS under TSO, with an LRECL of 80 (not unusual). LRECL of 80 means you *cannot have* physical source lines longer than 80 characters. (At some sites, LRECL is set to an even more restrictive 72 characters.) > So, is token-splitting there to cater for one of those rare machines (to > compile in this case rather than to execute on), which doesn't actually > exist anywhere? "You don't use one" and "doesn't actually exist anywhere" are not actually synonymous. "There are more things in heaven and earth, Horatio, /Than are dreamt of in your philosophy." - Hamlet I.v. > Even if there was such a need, what happens when someone acquires normal > C source from elsewhere, and tries to use it on one of these machines > which a 16-character hard limit on line lengths; it just wouldn't work > unless the source is heavily edited to add \ everywhere. 16 is a bit strong. 80 and 72 are fairly common, and macros longer than 72 characters aren't that uncommon, alas. It gets worse. On some PC-to-mainframe file transfer programs, the ASCII-to-EBCDIC converter gets the "wrong" EBCDIC codes for square brackets [] - that is, after translation to EBCDIC, the square brackets do not have the EBCDIC code points that the C compiler recognises as being square brackets. Some sites deal with this by using trigraphs (which are horrible, although it's surprising how quickly one adapts to them), and other sites deal with it by preprocessing their C source before sending it up to the mainframe - the preprocessing consists of translating [ and ] into the code points that will, after conversion to EBCDIC, be the "right" codes for square brackets. And I well remember a project in which /both/ these solutions were used, with the developers making the choice themselves on a case-by-case basis! > The idea is senseless IMO. Lots of things that seem senseless were considered the best solution *at the time*. To me, it seems rather daft to have \r\n as a newline character, but *at the time* it made sense to do that, and such constructs often survive either through inertia or on the grounds that it ain't broke so don't fix it (where "it ain't broke" means, for example, "we're getting the right numbers out of the payroll system"). -- 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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-12-02 01:26 +0000 |
| Message-ID | <n3lhc1$oun$1@speranza.aioe.org> |
| In reply to | #77520 |
Richard Heathfield <rjh@cpax.org.uk> wrote: > On 01/12/15 14:52, BartC wrote: > <snip> >> I'm not sure what is meant by a restricted line length; some display >> units may have such a restriction but the data being displayed won't (it >> would use scrolling or wrapping). > Consider, for example, source code stored in a PDS under TSO, with an > LRECL of 80 (not unusual). LRECL of 80 means you *cannot have* physical > source lines longer than 80 characters. (At some sites, LRECL is set to > an even more restrictive 72 characters.) The tradition was LRECL=80, but ignore the last eight. That went back to, at least, the 704 card reader reading a card row into two 36 bit words. The IBM PL/I compilers allow you to specify which columns are part of the input to be compiled. I don't know if C compilers do that. (snip) > It gets worse. On some PC-to-mainframe file transfer programs, the > ASCII-to-EBCDIC converter gets the "wrong" EBCDIC codes for square > brackets [] - that is, after translation to EBCDIC, the square brackets > do not have the EBCDIC code points that the C compiler recognises as > being square brackets. Square brackets go back at least to the TN print train used with S/360, but somehow other code points were added later. > Some sites deal with this by using trigraphs > (which are horrible, although it's surprising how quickly one adapts to > them), and other sites deal with it by preprocessing their C source > before sending it up to the mainframe - the preprocessing consists of > translating [ and ] into the code points that will, after conversion to > EBCDIC, be the "right" codes for square brackets. And I well remember a > project in which /both/ these solutions were used, with the developers > making the choice themselves on a case-by-case basis! There are two printable ASCII characters not in EBCDIC: ^ and ~. There are two printable EBCDIC characters not in ASCII, logical not and cent sign. Usually the translations map those, but not always in the same way. >> The idea is senseless IMO. > Lots of things that seem senseless were considered the best solution *at > the time*. To me, it seems rather daft to have \r\n as a newline > character, but *at the time* it made sense to do that, and such > constructs often survive either through inertia or on the grounds that > it ain't broke so don't fix it (where "it ain't broke" means, for > example, "we're getting the right numbers out of the payroll system"). As far as I know, DEC's fault. I believe it goes back to paper tape and printing on ASR33 terminals. It always seemd a mistake to me. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-01 09:12 -0800 |
| Message-ID | <lnk2oyum8f.fsf@kst-u.example.com> |
| In reply to | #77515 |
BartC <bc@freeuk.com> writes:
[...]
> So I'm struggling to see a real need to for splitting up tokens with \.
"Doc, it hurts when I do this!"
[...]
> Even if there was such a need, what happens when someone acquires normal
> C source from elsewhere, and tries to use it on one of these machines
> which a 16-character hard limit on line lengths; it just wouldn't work
> unless the source is heavily edited to add \ everywhere. The idea is
> senseless IMO.
A conforming compiler must support at least 4095 characters in a
single source line (the limit was 509 in C90). So you won't find
a C implementation that limits lines to 16 characters. But even
if you did, you could insert the \ characters automatically.
You've read the rationale by now. Given that there's *some* need
for line continuation, would you want an elaborate set of rules
to ensure that it's only used when it's sensible? Who decides
what's sensible, and how much work should the compiler have to do
to enforce the restrictions? IMHO it's better to have a simple general
rule.
Don't expect the language rules to prevent you from writing ugly code.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-01 19:17 +0000 |
| Message-ID | <87si3mc725.fsf@bsb.me.uk> |
| In reply to | #77530 |
Keith Thompson <kst-u@mib.org> writes: > BartC <bc@freeuk.com> writes: > [...] >> So I'm struggling to see a real need to for splitting up tokens with \. > > "Doc, it hurts when I do this!" > > [...] > >> Even if there was such a need, what happens when someone acquires normal >> C source from elsewhere, and tries to use it on one of these machines >> which a 16-character hard limit on line lengths; it just wouldn't work >> unless the source is heavily edited to add \ everywhere. The idea is >> senseless IMO. > > A conforming compiler must support at least 4095 characters in a > single source line (the limit was 509 in C90). So you won't find > a C implementation that limits lines to 16 characters. That limit is for a logical source line. I can't see any minimum for the physical source line length so the hypothetical implementation with a 16-character limit seems theoretically possible. > But even > if you did, you could insert the \ characters automatically. Yes, though you'd have to take care not to split either a multi-byte character or a trigraph. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-12-01 12:32 -0600 |
| Message-ID | <prpr5bp5qnm2fm78lhvq02p9nalkjotsn5@4ax.com> |
| In reply to | #77515 |
On Tue, 1 Dec 2015 14:52:18 +0000, BartC <bc@freeuk.com> wrote: >On 01/12/2015 14:33, Stefan Ram wrote: >> BartC <bc@freeuk.com> writes: >>> And probably not likely to find out /why/ >> >> I am sure the first thing you tried in order to find out why >> is to do the obvious: read the rationale of the committee, the >> >> Rationale for >> International Standard >> Programming Languages >> C >> >> Revision 2 >> 20 October 1999 >> >> . But for some reason you must have missed the paragraph: >> >> »A backslash immediately before a newline has long >> been used to continue string literals, as well as >> preprocessing command lines. In the interest of easing >> machine generation of C, and of transporting code to >> machines with restrictive physical line lengths, the C89 >> Committee generalized this mechanism to permit any token >> to be continued by interposing a backslash/newline >> sequence.«, 5.1.1.2l29 > >There are two kinds of tokens where you might not have a choice in >limiting how long they might be. > >One is string literals, but these can already be split up into multiple >strings. I believe the merging of adjacent string literals was a C89 invention (or at least not universal practice before then).
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.invalid> |
|---|---|
| Date | 2015-12-02 00:01 +0000 |
| Message-ID | <pan.2015.12.02.00.01.54.875000@nowhere.invalid> |
| In reply to | #77510 |
On Tue, 01 Dec 2015 14:26:16 +0000, BartC wrote: > OK, so it does this because of X, Y and Z. But that doesn't mean it > makes practical sense. Well, if you look at the translation phases, it's a fairly basic layering of protocols. The lowest level being the mapping between the external encoding and the source character set, plus conversion of trigraphs. Line continuations are the next lowest level after that. The point of layering is that code operating at a particular layer doesn't need to "understand" the layers above it. So e.g. a code generator or VCS client which needs to write files on a system which limits lines to 80 characters only needs to undertand encodings and trigraphs (so that it doesn't try to break a line in the middle of one). With that knowledge, it can just insert backslash-newline pairs as necessary to stay within the 80-character limit. It doesn't need to know about any higher-level syntax, because that doesn't come into play until line continuations have been processed. Also: a consequence of the fact that the encoding is even lower-level than continuations is that the compiler (or preprocessor) has to know the encoding. While UTF-8 and all of the ISO-8859-* encodings use \x5c as the backslash character, that isn't the case for many of the national dialects of ISO-646 (ASCII), nor for Shift-JIS where \x5c is used both as a single-byte character (where it's the Yen currency symbol) and as the second byte of multi-byte characters. Consequently, C source code using such encodings can result in // comments "consuming" the following line if the compiler treats the code as ISO-646-US (aka US-ASCII) or ISO-8859-*.
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web