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 1 of 5  [1] 2 3 4 5  Next page →

#63468 — Merging .h and .c source files

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. 

But I'm not in charge of the compiler. How might the same thing
be done without the pragma?

One way would be to define a lot of macros - one per unit. That
is, in the combined foo.h + foo.c put
   #ifdef foo_body
at the end of the header and at the very end put
   #endif
Since most x_body are never defined this cuts off the header
just as the pragama does. But suppose I want to compile foo.
I need its body as well as its head.'

One way to do that is to send the compiler the little file
   #define foo_body
   #include "foo.c"
and away we go.  

[toc] | [next] | [standalone]

#63469

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?

>
> 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.

Such a scheme would often work (in the sense that the code could still 
compile), but it is not difficult to imagine circumstances in which it 
would not. For example, a static object or function is visible only 
within the Translation Unit in which it appears. This means that it is 
possible to have two static objects with the same name in different C 
files. If you then merge those two files into one, the names will now clash.

> But I'm not in charge of the compiler. How might the same thing
> be done without the pragma?

Badly (just the same as /with/ the pragma).

-- 
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]

#63475

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?
> 
>>
>> 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.
> 
> Such a scheme would often work (in the sense that the code could still
> compile), but it is not difficult to imagine circumstances in which it
> would not. For example, a static object or function is visible only
> within the Translation Unit in which it appears. This means that it is
> possible to have two static objects with the same name in different C
> files. If you then merge those two files into one, the names will now
> clash.
> 
>> But I'm not in charge of the compiler. How might the same thing
>> be done without the pragma?
> 
> Badly (just the same as /with/ the pragma).
> 

Reminds me of a program I got for maintenance. That moron had merged the 
whole source into one big (>500k) file because he believed it would run 
faster.
Well one operation was faster. I had to remove only one file. :-)

-- 
Reinhardt

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

#63507

Reinhardt Behm <rbehm@hushmail.com> wrote:
> Reminds me of a program I got for maintenance. That moron had merged the 
> whole source into one big (>500k) file because he believed it would run 
> faster.
> Well one operation was faster. I had to remove only one file. :-)

I hope you benchmarked the difference before calling him a moron,
since that merging has produced demonstrable improvements in other
programs. See < http://www.sqlite.org/amalgamation.html >.  For reference:

> In addition to making SQLite easier to incorporate into other
> projects, the amalgamation also makes it run faster. Many compilers
> are able to do additional optimizations on code when it is contained
> with in a single translation unit such as it is in the
> amalgamation. We have measured performance improvements of between 5
> and 10% when we use the amalgamation to compile SQLite rather than
> individual source files. The downside of this is that the additional
> optimizations often take the form of function inlining which tends
> to make the size of the resulting binary image larger.

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

#63508

On 18/06/15 15:27, Michael Sorn wrote:
> Reinhardt Behm <rbehm@hushmail.com> wrote:
>> Reminds me of a program I got for maintenance. That moron had merged the 
>> whole source into one big (>500k) file because he believed it would run 
>> faster.
>> Well one operation was faster. I had to remove only one file. :-)
> 
> I hope you benchmarked the difference before calling him a moron,
> since that merging has produced demonstrable improvements in other
> programs. See < http://www.sqlite.org/amalgamation.html >.  For reference:
> 
>> In addition to making SQLite easier to incorporate into other
>> projects, the amalgamation also makes it run faster. Many compilers
>> are able to do additional optimizations on code when it is contained
>> with in a single translation unit such as it is in the
>> amalgamation. We have measured performance improvements of between 5
>> and 10% when we use the amalgamation to compile SQLite rather than
>> individual source files. The downside of this is that the additional
>> optimizations often take the form of function inlining which tends
>> to make the size of the resulting binary image larger.

For a lot of code, inlining makes code smaller rather than larger.  In
particular, for any functions called only once (and many functions fall
into that category), inlining should make the code smaller - you avoid
any calling convention overhead, and allow the compiler to make other
optimisations such as constant propagation.  It is vital that such
single-use functions are marked "static" for this to be effective.

Full-program or link-time optimisation is an alternative to amalgamation
in order to achieve the same effect, though only amalgamation can give
you the "easier to incorporate into other projects" benefit.


But usually ease of maintenance is more important than the last few
percent speed improvements, and thus amalgamation is a bad idea.

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

#63509

In article <mlugva$ap8$1@dont-email.me>,
Michael Sorn  <invalid@example.com> wrote:
>Reinhardt Behm <rbehm@hushmail.com> wrote:
>> Reminds me of a program I got for maintenance. That moron had merged the 
>> whole source into one big (>500k) file because he believed it would run 
>> faster.
>> Well one operation was faster. I had to remove only one file. :-)
>
>I hope you benchmarked the difference before calling him a moron,
>since that merging has produced demonstrable improvements in other
>programs. See < http://www.sqlite.org/amalgamation.html >.  For reference:

In a compiled language like C - especially in C, where we know it's just
textual inclusion - it can't make a difference.  N.B.  It might make the
compilation faster (no argument there), but it can't affect the runtime
speed.

In interpreted languages (like SQL), it certainly could matter.

P.S.  Yes, I know that C doesn't require that include files be files.  I
expect Kiki to point this out any second now.  But we all know that in all
serious implementations, they are.

P.P.S.  Also, of course, this may be different in C++, but that, as Kiki
will also point out any second now, is a differnt language and not the one
we discuss here.

-- 
"The smart way to keep people passive and obedient is to strictly limit the
spectrum of acceptable opinion, but allow very lively debate within that
spectrum...."

     - Noam Chomsky, The Common Good -

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

#63518

Michael Sorn wrote:

> Reinhardt Behm <rbehm@hushmail.com> wrote:
>> Reminds me of a program I got for maintenance. That moron had merged the
>> whole source into one big (>500k) file because he believed it would run
>> faster.
>> Well one operation was faster. I had to remove only one file. :-)
> 
> I hope you benchmarked the difference before calling him a moron,
> since that merging has produced demonstrable improvements in other
> programs. See < http://www.sqlite.org/amalgamation.html >.  For reference:
> 

Also it was at a time (15y ago) when compilers where not so clever that it 
would create any improvements. And his arguments where only based on unbased 
wild assumption.

The program did not need any speed improvements. It usually crashed quite 
fast.

A total rewrite of the mess made the program run faster without crashes.

-- 
Reinhardt

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

#63506

On Thursday, June 18, 2015 at 12:35:23 AM UTC+1, 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.
> 
One of the mistakes that C++ made was that the header no longer represents
the interface. Actually it does, but it's the interface the compiler needs to
see, not the one that's of interest to the human programmer.
C++ programmers coming to C often don't understand how to set up a
header correctly, and declarations that should be private and internal to
the dot C file are often included.

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

#63512

On 18.06.2015 01: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?

Or use emacs.  I think emacs works on Mac OS X as well as Linux and
on Windows through Cygwin or as a Windows program.

If you run emacs, press Ctrl-x 2, it splits into two screens.  You
can then press Ctrl-x 3 in one of those screens, and it will split
the other way.

Although maybe the need to split a screen is a sign that something
is wrong, either being stressed out and tired or that whatever
you're doing is too complicated.  Something along the lines of
that if a C function goes beyond the bottom of the editor window
vertically means one should consider if it should be refactored.

-Morten

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

#63515

On 18/06/15 15:07, Morten W. Petersen wrote:
> On 18.06.2015 01: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?
>
> Or use emacs.  I think emacs works on Mac OS X as well as Linux and
> on Windows through Cygwin or as a Windows program.

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.

> If you run emacs, press Ctrl-x 2, it splits into two screens.  You
> can then press Ctrl-x 3 in one of those screens, and it will split
> the other way.

The vim equivalents are :sp or :vsp

> Although maybe the need to split a screen is a sign that something
> is wrong, either being stressed out and tired or that whatever
> you're doing is too complicated.

I disagree. It can be quite handy to see a header and a source at the 
same time. It can even be quite handy to split a C file, so that one 
window shows the function and the other window shows where you're 
constructing a call to that function. (I do that a lot.)

> Something along the lines of
> that if a C function goes beyond the bottom of the editor window
> vertically means one should consider if it should be refactored.

I keep hearing that, and I do see the point, but in practice I don't 
have a problem with /long/ functions. For me, the limit is not the 
physical number of lines but the complexity of the function. Obviously 
to some extent they are related, but I wouldn't split a function up 
*only* because it happened to spill over the size of the editor window. 
(I might split it up for other reasons, though.)

-- 
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]

#63519

On 18.06.2015 16:29, Richard Heathfield wrote:
> On 18/06/15 15:07, Morten W. Petersen wrote:
[...]
>> Or use emacs.  I think emacs works on Mac OS X as well as Linux and
>> on Windows through Cygwin or as a Windows program.
>
> 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.

Well, it could be nice to have a newsgroup in one buffer and the
code(s) in question in the others. :D

>> If you run emacs, press Ctrl-x 2, it splits into two screens.  You
>> can then press Ctrl-x 3 in one of those screens, and it will split
>> the other way.
>
> The vim equivalents are :sp or :vsp

Yeah yeah.  Then you also have vi and nano, etc etc.

>> Although maybe the need to split a screen is a sign that something
>> is wrong, either being stressed out and tired or that whatever
>> you're doing is too complicated.
>
> I disagree. It can be quite handy to see a header and a source at the
> same time. It can even be quite handy to split a C file, so that one
> window shows the function and the other window shows where you're
> constructing a call to that function. (I do that a lot.)
>
>> Something along the lines of
>> that if a C function goes beyond the bottom of the editor window
>> vertically means one should consider if it should be refactored.
>
> I keep hearing that, and I do see the point, but in practice I don't
> have a problem with /long/ functions. For me, the limit is not the
> physical number of lines but the complexity of the function. Obviously
> to some extent they are related, but I wouldn't split a function up
> *only* because it happened to spill over the size of the editor window.
> (I might split it up for other reasons, though.)

Yeah.  Then again some things belong in a /bin/sh file and things
go on and on.

It sounds like you know what you're doing so you know the "exceptions
to the rules" then.

-Morten

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

#63558

"Morten W. Petersen" <morphex@gmail.com> wrote:

> On 18.06.2015 16:29, Richard Heathfield wrote:
> > On 18/06/15 15:07, Morten W. Petersen wrote:
> [...]
> >> If you run emacs, press Ctrl-x 2, it splits into two screens.  You
> >> can then press Ctrl-x 3 in one of those screens, and it will split
> >> the other way.
> >
> > The vim equivalents are :sp or :vsp
> 
> Yeah yeah.  Then you also have vi and nano, etc etc.

Yes, and some of us even use actual, functioning _editors_...

Richard

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

#63566

On 18.06.2015 23:52, Richard Bos wrote:
> "Morten W. Petersen" <morphex@gmail.com> wrote:
>
>> On 18.06.2015 16:29, Richard Heathfield wrote:
>>> On 18/06/15 15:07, Morten W. Petersen wrote:
>> [...]
>>>> If you run emacs, press Ctrl-x 2, it splits into two screens.  You
>>>> can then press Ctrl-x 3 in one of those screens, and it will split
>>>> the other way.
>>>
>>> The vim equivalents are :sp or :vsp
>>
>> Yeah yeah.  Then you also have vi and nano, etc etc.
>
> Yes, and some of us even use actual, functioning _editors_...

Yes, and..?

-Morten

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

#63584

"Morten W. Petersen" <morphex@gmail.com> wrote:

> On 18.06.2015 23:52, Richard Bos wrote:
> > "Morten W. Petersen" <morphex@gmail.com> wrote:
> >> On 18.06.2015 16:29, Richard Heathfield wrote:
> >>> On 18/06/15 15:07, Morten W. Petersen wrote:
> >> [...]
> >>>> If you run emacs, press Ctrl-x 2, it splits into two screens.  You
> >>>> can then press Ctrl-x 3 in one of those screens, and it will split
> >>>> the other way.
> >>>
> >>> The vim equivalents are :sp or :vsp
> >>
> >> Yeah yeah.  Then you also have vi and nano, etc etc.
> >
> > Yes, and some of us even use actual, functioning _editors_...
> 
> Yes, and..?

We find these a useful alternative to the abovementioned monstrosities.

Richard

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

#63585

On 19/06/15 11:02, Richard Bos wrote:
> "Morten W. Petersen" <morphex@gmail.com> wrote:
>> On 18.06.2015 23:52, Richard Bos wrote:
>> > "Morten W. Petersen" <morphex@gmail.com> wrote:
>> >>
>> >> Yeah yeah.  Then you also have vi and nano, etc etc.
>> >
>> > Yes, and some of us even use actual, functioning _editors_...
>>
>> Yes, and..?
>
> We find these a useful alternative to the abovementioned monstrosities.

De gustibus non est disputandum. Out of all of the editors I've used: 
XEDIT, edlin, edit, Multi-Edit, Brief, a wide variety of built-into-IDE 
editors, Notepad, Notepad++, pico, nano, emacs, and of course we must 
never forget the classic too-numerous-to-be-mentioned-here... I have 
found *none* of them to be as usable, powerful, and flexible as [g]vim.

Multi-Edit was very good. So was Brief. But I haven't seen hide nor hair 
of them for a number of years, or should I say decades? I liked MSVC6's 
Intellisense - that was very good indeed. Do MS still do Intellisense?

-- 
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]

#63589

On 19/06/2015 11:24, Richard Heathfield wrote:
> On 19/06/15 11:02, Richard Bos wrote:
>> "Morten W. Petersen" <morphex@gmail.com> wrote:
>>> On 18.06.2015 23:52, Richard Bos wrote:
>>> > "Morten W. Petersen" <morphex@gmail.com> wrote:
>>> >>
>>> >> Yeah yeah.  Then you also have vi and nano, etc etc.
>>> >
>>> > Yes, and some of us even use actual, functioning _editors_...
>>>
>>> Yes, and..?
>>
>> We find these a useful alternative to the abovementioned monstrosities.
>
> De gustibus non est disputandum. Out of all of the editors I've used:
> XEDIT, edlin, edit, Multi-Edit, Brief, a wide variety of built-into-IDE
> editors, Notepad, Notepad++, pico, nano, emacs, and of course we must
> never forget the classic too-numerous-to-be-mentioned-here... I have
> found *none* of them to be as usable, powerful, and flexible as [g]vim.

I use mostly my own small, very crude editors which have hardly changed 
since the eighties. They are bereft of most of the advanced features 
people seem to expect these days. However I seem to manage fine with them!

Most other editors I've tried fail the Bart Test: in the middle of a 
line, press and hold Backspace. Instead of stopping at the beginning of 
the current line, invariably they will carry and and delete much of the 
previous one or two lines as well before you've noticed!

This is bizarre behaviour in a *programmer's* editor, as most source 
languages are line-oriented. (It might be OK if you're working on a 
paragraph of a novel where the words flow from one line to another and 
are part of the same sentence.)

My own editors pass of course.

(I've just tried Vim, which I had to install on my Ubuntu system as 
apparently it wasn't included amongst the 150,000 files already present. 
So, 24.8MB of extra disk space later (my own editor is 0.06MB), I try my 
test on it and of course it also fails, as expected, but with an extra 
twist: it doesn't delete anything! This must be the read-only mode that 
has been mentioned.

So if someone decides to edit a rude word by backspacing over it and 
replacing it with a more innocuous one, they'd better be paying 
attention to the screen!)

-- 
Bartc

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

#63591

Bartc <bc@freeuk.com> writes:
<snip>
> Most other editors I've tried fail the Bart Test: in the middle of a
> line, press and hold Backspace. Instead of stopping at the beginning
> of the current line, invariably they will carry and and delete much of
> the previous one or two lines as well before you've noticed!

Rather than duplicate so much effort by writing your own, you could use
a programmable editor:

(global-set-key [backspace]
                (lambda ()
                  (interactive)
                  (unless (looking-at "^") (backward-delete-char 1))))

The result is you can build up the configuration for a single tool that
fits all your peculiarities like a glove.

(Obviously your own editor now does exactly what you want so I'm not
talking specifically to you -- the advice is to anyone thinking of
investing that effort now.)

<snip>
-- 
Ben.

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

#63596

On 19/06/2015 13:24, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
> <snip>
>> Most other editors I've tried fail the Bart Test: in the middle of a
>> line, press and hold Backspace. Instead of stopping at the beginning
>> of the current line, invariably they will carry and and delete much of
>> the previous one or two lines as well before you've noticed!
>
> Rather than duplicate so much effort by writing your own, you could use
> a programmable editor:
>
> (global-set-key [backspace]
>                  (lambda ()
>                    (interactive)
>                    (unless (looking-at "^") (backward-delete-char 1))))
>
> The result is you can build up the configuration for a single tool that
> fits all your peculiarities like a glove.

Which is not that much different from 'writing your own'! Except you now 
have to learn a new language and a new set of APIs.

(Your code snippet suggests the entire file is stored, conceptually at 
least, as a single string. My current editor stores it as separate 
lines, ie. as one string per line. Then accidentally crossing line 
boundaries is much harder. My entire approach seems different from 
anyone else's.)

Another problem is that for someone who largely uses their own syntax, 
other things, such as even the minimal syntax highlighting I use, also 
need changing. That part can get complicated (how to scroll down a 
function at a time for example?).

Then there is the highlighting used by every editor on the planet except 
mine, where you go to some trouble to mark a specific block of text, but 
then the slightest wrong move, or you switch windows then switch back to 
the editor by clicking somewhere with a mouse, and the highlighting 
vanishes, if you're lucky, otherwise the text itself disappears and you 
have to hope that Ctrl Z can get it back.

This sort of thing is going to take a *lot* of customisation to fix.

There was one thing in particular (other than ends of lines not being 
hard stops) that used to annoy me a lot: you edit a file and save it. 
Then you come back to it and it's forgotten where you were and you have 
to start from the top. Now more editors are smart enough to remember 
position, but mine have always done that.

When switching rapidly from one file to another, it is essential that it 
remembers where you were. Having lots of windows into separate files is 
not the same thing. (I use windows into separate projects.)

Anyway, my point is it can be easier to write your own editor to do 
exactly what you want, rather than try and customise someone else's.

(20 years ago I needed to write a 300-page manual and we couldn't afford 
to hire someone. I tried MS Word, but even then it had a mind of its own 
and it was difficult get to it to do what you wanted. It was much easier 
to write some code to take some marked-up text (using my editor, or 
course), and process that, complete with in-line diagrams, images and 
some program code. Eventually it ended up sent to a Postscript printer 
and it looked beautiful.

I could have spent the same few weeks struggling with Word before 
throwing the whole machine, with printer attached, through the window in 
frustration.)

-- 
Bartc

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

#63600

On 19.06.2015 15:09, Bartc wrote:
> On 19/06/2015 13:24, Ben Bacarisse wrote:
>> Bartc <bc@freeuk.com> writes:
>> <snip>
>>> Most other editors I've tried fail the Bart Test: in the middle of a
>>> line, press and hold Backspace. Instead of stopping at the beginning
>>> of the current line, invariably they will carry and and delete much of
>>> the previous one or two lines as well before you've noticed!
>>
>> Rather than duplicate so much effort by writing your own, you could use
>> a programmable editor:
>>
>> (global-set-key [backspace]
>>                  (lambda ()
>>                    (interactive)
>>                    (unless (looking-at "^") (backward-delete-char 1))))
>>
>> The result is you can build up the configuration for a single tool that
>> fits all your peculiarities like a glove.
>
> Which is not that much different from 'writing your own'! Except you now
> have to learn a new language and a new set of APIs.

Writing your editor could be a useful and good exercise.  I guess
any programmer should have one or more pet projects, but there is
always a backside to having completely custom code.  The developer
is the only one who knows the code and it kinda sucks to be close
to the deadline and then the editor breaks in some way.

However, I've programmed very little lisp, and the "configuration" above
makes perfect sense to me.  The "^" is line start, and is something
commonly used in grep and other *nix programs.

And lambda is known from many different languages, and so on, things
are pretty self-explanatory.

But, I was wondering Ben, do you know how to make emacs update the
font-lock-mode faster?  I'm on a fairly fast desktop computer and
sometimes when commenting out a block of code for example, it takes
a little while before the colors reflect what's going on.

And I have to say, syntax highlighting is one of the really useful
enhancements as it gives more information about the code and what's
going on.

-Morten

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

#63621

"Morten W. Petersen" <morphex@gmail.com> writes:

> On 19.06.2015 15:09, Bartc wrote:
>> On 19/06/2015 13:24, Ben Bacarisse wrote:
>>> Bartc <bc@freeuk.com> writes:
>>> <snip>
>>>> Most other editors I've tried fail the Bart Test: in the middle of a
>>>> line, press and hold Backspace. Instead of stopping at the beginning
>>>> of the current line, invariably they will carry and and delete much of
>>>> the previous one or two lines as well before you've noticed!
>>>
>>> Rather than duplicate so much effort by writing your own, you could use
>>> a programmable editor
<snip>
> Writing your editor could be a useful and good exercise.

Sure.  I think everyone my age, has because all those decades ago the
editors were bad and the objective was simple.  Now there are good ones
and I want Unicode support, multiple file encodings, automatic
encryption/decryption, syntax highlighting for dozens of languages,
etc., etc...

> But, I was wondering Ben, do you know how to make emacs update the
> font-lock-mode faster?

Try gnu.emacs.help

-- 
Ben.

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

Page 1 of 5  [1] 2 3 4 5  Next page →

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

csiph-web