Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #63468 > unrolled thread

Merging .h and .c source files

Back to article view | Back to comp.lang.c

Contents

  Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 16:27 -0700
    Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 00:35 +0100
      Re: Merging .h and .c source files Reinhardt Behm <rbehm@hushmail.com> - 2015-06-18 12:51 +0800
        Re: Merging .h and .c source files Michael Sorn <invalid@example.com> - 2015-06-18 13:27 +0000
          Re: Merging .h and .c source files David Brown <david.brown@hesbynett.no> - 2015-06-18 15:38 +0200
          Re: Merging .h and .c source files gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-18 13:42 +0000
          Re: Merging .h and .c source files Reinhardt Behm <rbehm@hushmail.com> - 2015-06-18 22:47 +0800
      Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 06:21 -0700
      Re: Merging .h and .c source files "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 16:07 +0200
        Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 15:29 +0100
          Re: Merging .h and .c source files "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 16:48 +0200
            Re: Merging .h and .c source files raltbos@xs4all.nl (Richard Bos) - 2015-06-18 21:52 +0000
              Re: Merging .h and .c source files "Morten W. Petersen" <morphex@gmail.com> - 2015-06-19 03:57 +0200
                Re: Merging .h and .c source files raltbos@xs4all.nl (Richard Bos) - 2015-06-19 10:02 +0000
                  Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 11:24 +0100
                    Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-19 12:10 +0100
                      Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 13:24 +0100
                        Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-19 14:09 +0100
                          Re: Merging .h and .c source files "Morten W. Petersen" <morphex@gmail.com> - 2015-06-19 15:30 +0200
                            Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 17:34 +0100
                          Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 17:06 +0100
                            Re: Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-19 09:40 -0700
                              Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-19 18:12 +0100
                              Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-19 11:25 -0700
                                Re: Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-20 07:31 -0700
                                  Re: Merging .h and .c source files glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-20 17:07 +0000
                                    Re: Merging .h and .c source files "Charles Richmond" <numerist@aquaporin4.com> - 2015-06-23 17:44 -0500
                                      Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-24 01:48 +0100
                                  Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-20 12:37 -0700
                              Re: Merging .h and .c source files Robert Wessel <robertwessel2@yahoo.com> - 2015-06-19 22:04 -0500
                                Re: Merging .h and .c source files Les Cargill <lcargill99@comcast.com> - 2015-06-19 22:36 -0500
                                  Re: Merging .h and .c source files Robert Wessel <robertwessel2@yahoo.com> - 2015-06-20 01:23 -0500
                            Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-19 17:54 +0100
                              Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 19:45 +0100
                            Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-21 07:19 -0700
                    Re: Merging .h and .c source files Ian Collins <ian-news@hotmail.com> - 2015-06-20 08:52 +1200
                    Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 18:44 -0700
          Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 08:26 -0700
            Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 16:41 +0100
              Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-18 17:13 +0100
                Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 09:26 -0700
                  Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 18:03 +0100
                    Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 18:33 -0700
                  Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-18 10:28 -0700
                  Re: Merging .h and .c source files gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-18 17:28 +0000
                  Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-18 21:07 +0100
                    Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 15:04 -0700
                      Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 00:38 +0100
                        Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-19 01:00 +0100
                          Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-19 00:10 -0700
                          Re: Merging .h and .c source files mark.bluemel@gmail.com - 2015-06-19 00:56 -0700
                            Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 09:18 +0100
                  Re: Merging .h and .c source files John Bode <jfbode1029@gmail.com> - 2015-06-24 08:43 -0700
                    Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-24 11:15 -0700
                    Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 19:23 +0100
                      Re: Merging .h and .c source files James Kuyper <jameskuyper@verizon.net> - 2015-06-24 14:40 -0400
                        Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 19:45 +0100
                Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-18 10:19 -0700
                  Re: Merging .h and .c source files gwowen <gwowen@gmail.com> - 2015-06-19 05:29 -0700
                    Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-19 08:26 -0700
              Re: Merging .h and .c source files "Morten W. Petersen" <morphex@gmail.com> - 2015-06-19 04:08 +0200
              Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 17:53 -0700
                Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 18:40 -0700
                  Re: Merging .h and .c source files Udyant Wig <udyantw@gmail.com> - 2015-07-11 10:19 +0530
                    Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 15:59 -0700
                      Re: Merging .h and .c source files raltbos@xs4all.nl (Richard Bos) - 2015-07-13 18:50 +0000
                        Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 08:37 -0700
                          Re: Merging .h and .c source files raltbos@xs4all.nl (Richard Bos) - 2015-07-19 21:30 +0000
                            Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 09:46 -0700
                    Re: Merging .h and .c source files Richard Damon <Richard@Damon-Family.org> - 2015-07-11 20:08 -0400
                      Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 18:26 -0700
                      Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 08:38 -0700
                  Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 15:57 -0700
                    Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 16:30 -0700
                      Re: Merging .h and .c source files Ian Collins <ian-news@hotmail.com> - 2015-07-12 15:51 +1200
                        Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-12 06:03 -0700
                          Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 21:36 +0100
                            Re: Merging .h and .c source files gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-12 21:27 +0000
                          Re: Merging .h and .c source files Ian Collins <ian-news@hotmail.com> - 2015-07-13 10:00 +1200
                            Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-13 04:16 -0700
                              Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-07-13 12:47 +0100
                              Re: Merging .h and .c source files Ian Collins <ian-news@hotmail.com> - 2015-07-14 08:32 +1200
                              Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 11:33 -0700
                      Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 11:24 -0700
                        Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-15 12:29 -0700
                          Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 09:50 -0700
                    Re: Merging .h and .c source files raltbos@xs4all.nl (Richard Bos) - 2015-07-13 18:52 +0000
                      Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 08:52 -0700
                        Re: Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 20:33 -0700
                          Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 09:53 -0700
          Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 17:47 -0700
      Re: Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-18 11:18 -0700
        Re: Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-18 11:34 -0700
          Re: Merging .h and .c source files Morris Dovey <mrdovey@iedu.com> - 2015-06-18 15:59 -0500
        Re: Merging .h and .c source files Philipp Klaus Krause <pkk@spth.de> - 2015-06-19 12:46 +0200
      Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-18 19:23 +0100
    Re: Merging .h and .c source files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-06-18 07:48 -0600
    Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-18 18:27 +0100

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

#65477

On 13/07/2015 12:16, Malcolm McLean wrote:
> On Sunday, July 12, 2015 at 11:00:31 PM UTC+1, Ian Collins wrote:
>> Malcolm McLean wrote:
>>
>>> In my current job I've been asked to make every if statement
>>> control a block rather than a single line. So I achieve that
>>> by pressing the requisite keys. I don't set up the editor to
>>> enforce the style, and it would be a nuisance when I work on
>>> private code which isn't written with that convention - partly
>>> because I tend to avoid ? :, my preferred style makes heavy use
>>> of one line ifs.
>>
>> So pick a decent editor that allows you to associate styles with projects.
>>
> I don't have time to fiddle about with text editors playing with options
> for associating  settings with projects.

In 1994 I solved that problem by buying a portable notebook computer 
that I could take with me when visiting clients.

Apart from having everything I needed on it, it means I didn't have to 
use the clients' keyboards with their funny foreign layouts, which 
really slowed me down.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#65518

Malcolm McLean wrote:
> On Sunday, July 12, 2015 at 11:00:31 PM UTC+1, Ian Collins wrote:
>> Malcolm McLean wrote:
>>
>>> In my current job I've been asked to make every if statement
>>> control a block rather than a single line. So I achieve that
>>> by pressing the requisite keys. I don't set up the editor to
>>> enforce the style, and it would be a nuisance when I work on
>>> private code which isn't written with that convention - partly
>>> because I tend to avoid ? :, my preferred style makes heavy use
>>> of one line ifs.
>>
>> So pick a decent editor that allows you to associate styles with projects.
>>
> I don't have time to fiddle about with text editors playing with options
> for associating  settings with projects.

So you would rather spend your time laying all your code out by hand 
instead of focusing on writing the code and letting the machine do the 
donkey work?  I suppose you do all your laundry bay hand because you 
don't have time to fiddle about with washing machines?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#65646

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Sunday, July 12, 2015 at 11:00:31 PM UTC+1, Ian Collins wrote:
>> Malcolm McLean wrote:
>>
>>> In my current job I've been asked to make every if statement
>>> control a block rather than a single line.  So I achieve that
>>> by pressing the requisite keys.  I don't set up the editor to
>>> enforce the style, and it would be a nuisance when I work on
>>> private code which isn't written with that convention - partly
>>> because I tend to avoid ? :, my preferred style makes heavy use
>>> of one line ifs.
>>
>> So pick a decent editor that allows you to associate styles with projects.
>
> I don't have time to fiddle about with text editors playing with options
> for associating  settings with projects.

To me this sounds like bad process.  Time spent sharpening a tool
often results in productivity gains with fairly short payback
periods, and a text editor is one of the most used tools in a
software developer's tool chest.  To make this statement categorically
seems more like prejudice than a reasoned and informed position.
However I won't try to dissuade you, just noting my impressions
in case anyone is interested.

[toc] | [prev] | [next] | [standalone]

#65645

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Saturday, July 11, 2015 at 11:57:33 PM UTC+1, Tim Rentsch wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>>> Customising an editor is a last resort.
>>
>> A rather narrow-minded and unenlightened viewpoint.
>
> No, it's fundamental to bad software design.

Your viewpoint is fundamental to bad software design?
(just kidding..)

> Most programs inherently have a lot of essentially arbitrary settings,
> for which there isn't a clear convention.  The trick of good design
> is to set these settings so that they match the conventions, and
> are usable.  That's hard, so lazy programmers who don't know anything
> about ergonomics typically put in options.  So users waste a lot
> of time setting the options, not knowing how to unset them,
> wondering why the program doesn't behave as it ought (because the
> wrong options are set).  Technical support desks despair, often it's
> necessary to set all the configurations to some known value before
> any support can be given.
>
> Customisation should be rare.  Things need to work as is, out
> of the box.  [snip]

I agree customization should be rare.  I don't agree that
customizing is a last restort.  Also note that I am not
talking about users in general, but only about users who
are C software developers, who are generally more able
and competent to do such things.  And you snipped an important
part of my earlier comments in the message you are responding
to:

>> I understand your reaction, but it shouldn't be a deal-breaker.
>> Any response that emacs exhibits can be customized (ie, by a
>> user) so that it doesn't occur.  Someone might complain the
>> the barrier to modification is too high, and that might be
>> a fair reaction, but first I think they should try to see
>> what it takes to perform the customization.  IME emacs does
>> have a few annoying behaviors, but these are comparatively
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> rare and they are easily turn-offable.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The underlined text undercuts your comments.

> I don't have time to fiddle with text editors on every computer
> I use.

I'm not suggesting that you do that, or that anyone do it;  only
that they should make an earnest effort actually trying it out
before proclaiming that it's too hard or too much effort.  Also,
since emacs is available on most platforms likely to be used for
software development, any effort put in to customizing it will
carry over to those other systems with essentially no effort
(just copying over a .emacs file).  (From what I understand, the
same applies to vim and its configuration file or whatever they
call it, but I am not a vim expert so I can't say for sure.  In
any case I don't think emacs is the only editing application
where customizing on one platform immediately carries over to
other platforms.)

[toc] | [prev] | [next] | [standalone]

#65648

On Wednesday, July 15, 2015 at 7:24:55 PM UTC+1, Tim Rentsch wrote:
>
>  (From what I understand, the
> same applies to vim and its configuration file or whatever they
> call it, but I am not a vim expert so I can't say for sure. 
>
So there you have it.
You've got to be a vim "expert" before you can make the most basic
statement about its capabilities.

[toc] | [prev] | [next] | [standalone]

#66017

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Wednesday, July 15, 2015 at 7:24:55 PM UTC+1, Tim Rentsch wrote:
>
>>  (From what I understand, the
>> same applies to vim and its configuration file or whatever they
>> call it, but I am not a vim expert so I can't say for sure. 
>
> So there you have it.
> You've got to be a vim "expert" before you can make the most basic
> statement about its capabilities.

That is a mischaracterization.  I don't think further elaboration
is necessary.

[toc] | [prev] | [next] | [standalone]

#65509

Tim Rentsch <txr@alumni.caltech.edu> wrote:

> You are, as you often do, confusing what you want with
> what other people want.  And I have to tell you, it
> is f****** annoying.  Please stop it.

No, Tim, _you_ are. Because this...

> I don't
> "fire emacs up" in order to edit a file - I routinely
> run it immediately after logging in, and simply leave
> it running.

...is not feasible for 99.999% of normal users.

Richard

[toc] | [prev] | [next] | [standalone]

#65630

raltbos@xs4all.nl (Richard Bos) writes:

> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>
>> You are, as you often do, confusing what you want with
>> what other people want.  And I have to tell you, it
>> is f****** annoying.  Please stop it.
>
> No, Tim, _you_ are.

I don't know why you think that.  I haven't said anything about
what other people want, only about what I want.  I know other
people like using other editors, and I'm not saying they
shouldn't.  So I don't think I'm confusing the two different
questions.  Do you still think I am?  If so can you say why?

> Because this...
>
>> I don't
>> "fire emacs up" in order to edit a file - I routinely
>> run it immediately after logging in, and simply leave
>> it running.
>
> ...is not feasible for 99.999% of normal users.

In the newsgroup here I am concerned only with C software
developers.  Based on comments from other people here that number
seems high for that group.  Do you think that 99.999% of C
software developers would find running emacs constantly
unfeasible?  If you do can you say why?

[toc] | [prev] | [next] | [standalone]

#65677

On Wednesday, July 15, 2015 at 8:52:27 AM UTC-7, Tim Rentsch wrote:
> raltbos@xs4all.nl (Richard Bos) writes:
> 
> > Tim Rentsch <txr@alumni.caltech.edu> wrote:
> >
> >> You are, as you often do, confusing what you want with
> >> what other people want.  And I have to tell you, it
> >> is f****** annoying.  Please stop it.
> >
> > No, Tim, _you_ are.
> 
> I don't know why you think that.  I haven't said anything about
> what other people want, only about what I want.  I know other
> people like using other editors, and I'm not saying they
> shouldn't.  So I don't think I'm confusing the two different
> questions.  Do you still think I am?  If so can you say why?
> 
> > Because this...
> >
> >> I don't
> >> "fire emacs up" in order to edit a file - I routinely
> >> run it immediately after logging in, and simply leave
> >> it running.
> >
> > ...is not feasible for 99.999% of normal users.
> 
> In the newsgroup here I am concerned only with C software
> developers.  Based on comments from other people here that number
> seems high for that group.  Do you think that 99.999% of C
> software developers would find running emacs constantly
> unfeasible?  If you do can you say why?

I turn off my machine when I'm not using it so constantly is not
an option. I don't use emacs but I do, more or less, keep Firefox
running all the time. Emacs would be just as easy. I could setup
a boot script to bring up Firefox but I haven't bothered.

I do have one minor problem I have to click my new wireless mouse to
get the machine to recognize it. 

[toc] | [prev] | [next] | [standalone]

#66018

David Kleinecke <dkleinecke@gmail.com> writes:

> On Wednesday, July 15, 2015 at 8:52:27 AM UTC-7, Tim Rentsch wrote:
>> raltbos@xs4all.nl (Richard Bos) writes:
>>
>>> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>>>
>>>> You are, as you often do, confusing what you want with
>>>> what other people want.  And I have to tell you, it
>>>> is f****** annoying.  Please stop it.
>>>
>>> No, Tim, _you_ are.
>>
>> I don't know why you think that.  I haven't said anything about
>> what other people want, only about what I want.  I know other
>> people like using other editors, and I'm not saying they
>> shouldn't.  So I don't think I'm confusing the two different
>> questions.  Do you still think I am?  If so can you say why?
>>
>>> Because this...
>>>
>>>> I don't
>>>> "fire emacs up" in order to edit a file - I routinely
>>>> run it immediately after logging in, and simply leave
>>>> it running.
>>>
>>> ...is not feasible for 99.999% of normal users.
>>
>> In the newsgroup here I am concerned only with C software
>> developers.  Based on comments from other people here that number
>> seems high for that group.  Do you think that 99.999% of C
>> software developers would find running emacs constantly
>> unfeasible?  If you do can you say why?
>
> I turn off my machine when I'm not using it so constantly is not
> an option.  [snip]

I know some people operate in that mode but I think it is
less common for active software developers.

[toc] | [prev] | [next] | [standalone]

#65211

Richard Heathfield <rjh@cpax.org.uk> writes:

> [.. emacs ..]
>
> A few years ago, someone told this group about a company that was
> distributing a "vim reference t-shirt" with lots of handy commands
> printed *upside-down* on the front of the shirt (pull the shirt out
> and forward a bit, and then look down to look up).  Ben Pfaff responded
> by asking whether they also did a reference tent, for emacs users.

Not needed, because emacs has a good interactive help facility
built-in.

[toc] | [prev] | [next] | [standalone]

#63543

On Wednesday, June 17, 2015 at 4:35:23 PM UTC-7, Richard Heathfield wrote:
> On 18/06/15 00:27, David Kleinecke wrote:
> > Why would anybody want to merge, say, foo.h and foo.c into a
> > single file?
> 
> Perhaps they would wish to do so because they haven't understood the 
> difference between the two. A source (or multiple sources) and header, 
> between them, form a module. The header contains the details of the 
> interface, and the source(s) contain(s) the implementation.
> 
> > It's a matter of making the source code readable. It is awkward
> > to have to always continually look at foo.h when you are reading
> > foo.c.
> 
> gvim foo.c
> :sp foo.h
> 
> Job done.
> 
> > I usually paste foo.h into foo.c (making it, probably,
> > uncompilable) to make foo.c readable.
> 
> Yes, you could do that - or you could learn how to use a multi-window 
> editor such as, well, almost all of them really. What are you using to 
> read source - Notepad?
 
gedit

[toc] | [prev] | [next] | [standalone]

#63545

On Thursday, June 18, 2015 at 11:18:18 AM UTC-7, David Kleinecke wrote:
> On Wednesday, June 17, 2015 at 4:35:23 PM UTC-7, Richard Heathfield wrote:
> > On 18/06/15 00:27, David Kleinecke wrote:
> > > Why would anybody want to merge, say, foo.h and foo.c into a
> > > single file?
> > 
> > Perhaps they would wish to do so because they haven't understood the 
> > difference between the two. A source (or multiple sources) and header, 
> > between them, form a module. The header contains the details of the 
> > interface, and the source(s) contain(s) the implementation.
> > 
> > > It's a matter of making the source code readable. It is awkward
> > > to have to always continually look at foo.h when you are reading
> > > foo.c.
> > 
> > gvim foo.c
> > :sp foo.h
> > 
> > Job done.
> > 
> > > I usually paste foo.h into foo.c (making it, probably,
> > > uncompilable) to make foo.c readable.
> > 
> > Yes, you could do that - or you could learn how to use a multi-window 
> > editor such as, well, almost all of them really. What are you using to 
> > read source - Notepad?
>  
> gedit

Most of my thinking is based on the Gtk+ and related packages. 

I could open two windows and show both files but it's more trouble 
than importing the .h file bodily. Generally I am not comparing files
but reading one or the other. Having the header at the top of the
source text makes it easy to find definitions that made in the header.

But I am interested in readibility and, to me at least, readability
means one continous text (even if I hypertext around in it).

I think a program should present everything that is assumed first and
those assumptions are presently being split into two files. I would like
to see that "problem" (as I see it) fixed. 

[toc] | [prev] | [next] | [standalone]

#63555

On 6/18/15 1:34 PM, David Kleinecke wrote:

> Most of my thinking is based on the Gtk+ and related packages.
>
> I could open two windows and show both files but it's more trouble
> than importing the .h file bodily. Generally I am not comparing files
> but reading one or the other. Having the header at the top of the
> source text makes it easy to find definitions that made in the header.
>
> But I am interested in readibility and, to me at least, readability
> means one continous text (even if I hypertext around in it).
>
> I think a program should present everything that is assumed first and
> those assumptions are presently being split into two files. I would like
> to see that "problem" (as I see it) fixed.

We all make our own choices. :-)

I normally have a gvim window open with an open tab for each of the 
header files I need;

I have another gvim window open with an open tab for each of the source 
files I need;

sometimes I use another gvim window (rather than tab) so that I can edit 
one source module while being able to see the others.

I usually have a bash window open, with tabs for each of the man files 
to which I want to refer, and at least one tab for compiling and executing;

and I frequently have a PostScript viewer window open so I can refer to 
the C spec whenever a man page seems inadequate to answer a question.

I chose hardware that lets me work with eight non-overlapping windows 
each displaying 106 80-character lines of text. Yes, old habits die hard 
- but this lash-up works pretty well for me. :-)

-- 
Morris Dovey
http://www.iedu.com/Solar

[toc] | [prev] | [next] | [standalone]

#63588

On 18.06.2015 20:18, David Kleinecke wrote:
> On Wednesday, June 17, 2015 at 4:35:23 PM UTC-7, Richard Heathfield wrote:
>> On 18/06/15 00:27, David Kleinecke wrote:
>>> Why would anybody want to merge, say, foo.h and foo.c into a
>>> single file?
>>
>> Perhaps they would wish to do so because they haven't understood the 
>> difference between the two. A source (or multiple sources) and header, 
>> between them, form a module. The header contains the details of the 
>> interface, and the source(s) contain(s) the implementation.
>>
>>> It's a matter of making the source code readable. It is awkward
>>> to have to always continually look at foo.h when you are reading
>>> foo.c.
>>
>> gvim foo.c
>> :sp foo.h
>>
>> Job done.
>>
>>> I usually paste foo.h into foo.c (making it, probably,
>>> uncompilable) to make foo.c readable.
>>
>> Yes, you could do that - or you could learn how to use a multi-window 
>> editor such as, well, almost all of them really. What are you using to 
>> read source - Notepad?
>  
> gedit
> 

I also often use gedit. But I definitely prefer having the .h in one
gedit tab and the .c in another. Scrolling within one big file seems
like more effort to me than switching between tabs.

Philipp

[toc] | [prev] | [next] | [standalone]

#63544

On 18/06/2015 00:35, Richard Heathfield wrote:
> On 18/06/15 00:27, David Kleinecke wrote:
>> Why would anybody want to merge, say, foo.h and foo.c into a
>> single file?
>
> Perhaps they would wish to do so because they haven't understood the
> difference between the two. A source (or multiple sources) and header,
> between them, form a module. The header contains the details of the
> interface, and the source(s) contain(s) the implementation.
>
>> It's a matter of making the source code readable. It is awkward
>> to have to always continually look at foo.h when you are reading
>> foo.c.
>
> gvim foo.c
> :sp foo.h
>
> Job done.
>
>> I usually paste foo.h into foo.c (making it, probably,
>> uncompilable) to make foo.c readable.
>
> Yes, you could do that - or you could learn how to use a multi-window
> editor such as, well, almost all of them really. What are you using to
> read source - Notepad?

You don't need a multi-window editor. Just multiple windows. Then 
Notepad would work too. (There is also Notepad++, more programmer 
oriented, but I've never used it.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#63511

David Kleinecke <dkleinecke@gmail.com> writes:

> Why would anybody want to merge, say, foo.h and foo.c into a
> single file?
>
> It's a matter of making the source code readable. It is awkward
> to have to always continually look at foo.h when you are reading
> foo.c. I usually paste foo.h into foo.c (making it, probably,
> uncompilable) to make foo.c readable.

You either have a decidedly idiosyncratic notion of what makes code
readable, or have encountered some very odd .h files.

[toc] | [prev] | [next] | [standalone]

#63536

On 18/06/2015 00:27, David Kleinecke wrote:
> Why would anybody want to merge, say, foo.h and foo.c into a
> single file?
>
> It's a matter of making the source code readable. It is awkward
> to have to always continually look at foo.h when you are reading
> foo.c. I usually paste foo.h into foo.c (making it, probably,
> uncompilable) to make foo.c readable.
>
> If I were in charge of the compiler I would invent a pragma
>     #pragma end_of_inclusion
> and convert all my .h .c pairs into a single file (.c most likely)
> starting with .h material then the pragma and then .c material.
> The semantics are that if a file is being included including
> stops at the pragma. This is equivalent to what is usually done
> today.

I had exactly that feature in an old script language of mine. I called 
it 'endinclude'.

Applied to C, you would include "module.c" instead of "module.h". 
"module.c" would have 'endinclude' following the declarations that you 
wanted shared.

(But now I use a proper import system.)

-- 
Bartc

[toc] | [prev] | [standalone]

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

Back to top | Article view | comp.lang.c

csiph-web