Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #127943 > unrolled thread
| Started by | bartc <bc@freeuk.com> |
|---|---|
| First post | 2018-03-17 16:07 +0000 |
| Last post | 2018-03-21 12:19 +0000 |
| Articles | 20 on this page of 125 — 24 participants |
Back to article view | Back to comp.lang.c
Dropping C bartc <bc@freeuk.com> - 2018-03-17 16:07 +0000
Re: Dropping C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-18 00:41 +0800
Re: Dropping C Richard Damon <Richard@Damon-Family.org> - 2018-03-17 19:54 -0400
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-18 13:19 +1300
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 02:42 -0700
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-18 01:28 +0000
Re: Dropping C Richard Damon <Richard@Damon-Family.org> - 2018-03-17 21:41 -0400
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-18 11:25 +0000
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 04:33 -0700
Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-19 00:05 +0100
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 00:24 +0000
Re: Dropping C Richard Damon <Richard@Damon-Family.org> - 2018-03-18 21:15 -0400
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 19:00 -0700
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-19 14:04 +0100
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-19 06:08 -0700
Re: Dropping C supercat@casperkitty.com - 2018-03-19 14:29 -0700
Re: Dropping C Noob <root@127.0.0.1> - 2018-03-19 14:34 +0100
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-19 06:39 -0700
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-19 15:17 +0100
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 15:03 +0000
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-19 15:36 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 17:01 +0000
Re: Dropping C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-03-19 12:14 -0600
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 19:15 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-20 08:20 +1300
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 20:47 +0000
Re: Dropping C Lowell Gilbert <lgusenet@be-well.ilk.org> - 2018-03-19 18:00 -0400
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 22:17 +0000
Re: Dropping C Reinhardt Behm <rbehm@hushmail.com> - 2018-03-20 09:34 +0800
Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-21 07:54 +0100
Re: Dropping C Robert Wessel <robertwessel2@yahoo.com> - 2018-03-21 04:10 -0500
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-21 11:08 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-21 11:18 +0000
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-21 05:28 -0700
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-21 12:13 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-21 12:26 +0000
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-21 15:55 +0000
Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-21 20:15 +0100
Re: Dropping C Keith Thompson <kst-u@mib.org> - 2018-03-21 12:45 -0700
Re: Dropping C supercat@casperkitty.com - 2018-03-21 13:46 -0700
Killfiles (Was: Dropping C) gazelle@shell.xmission.com (Kenny McCormack) - 2018-03-21 21:42 +0000
Re: Killfiles (Was: Dropping C) Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-22 04:22 -0700
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-21 20:21 +0000
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-21 22:21 -0700
Re: Dropping C Reinhardt Behm <rbehm@hushmail.com> - 2018-03-20 09:32 +0800
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 10:01 +1300
Re: Dropping C luser droog <luser.droog@gmail.com> - 2018-03-20 16:01 -0700
Re: Dropping C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-03-19 13:41 -0600
Re: Dropping C luser droog <luser.droog@gmail.com> - 2018-03-19 12:52 -0700
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-19 20:15 +0000
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-19 20:38 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-19 22:00 +0100
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 01:45 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-20 03:05 +0100
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 21:09 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-20 18:26 +1300
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 10:58 +0000
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-20 14:22 +0100
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-20 13:58 +0000
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-20 17:14 +0100
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 16:31 +0000
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-20 17:14 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 07:31 +1300
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 18:51 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 08:01 +1300
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-20 19:03 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 19:22 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 08:25 +1300
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 19:33 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 09:34 +1300
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-20 19:49 +0000
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-21 11:27 +0100
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 01:27 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-19 17:03 +0100
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-19 23:13 +0100
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-20 00:23 +0100
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 00:55 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-20 02:29 +0100
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 02:04 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-20 03:31 +0100
Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-21 20:18 +0100
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-21 21:32 +0100
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-21 20:52 +0000
Re: Dropping C supercat@casperkitty.com - 2018-03-21 14:38 -0700
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-21 23:08 +0100
Re: Dropping C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-22 13:37 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 15:41 +0100
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-22 14:58 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 17:37 +0100
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-22 17:09 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 18:27 +0100
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-22 17:35 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 18:46 +0100
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-22 18:22 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 19:38 +0100
Re: Dropping C jameskuyper@verizon.net - 2018-03-22 12:19 -0700
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-22 20:23 +0000
Re: Dropping C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-03-23 06:10 -0700
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-23 14:54 +0100
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-23 16:55 +0100
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-23 17:46 +0100
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-24 02:50 +0100
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-24 02:54 +0100
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-22 16:43 +0000
Re: Dropping C Keith Thompson <kst-u@mib.org> - 2018-03-22 10:39 -0700
Re: Dropping C Robert Wessel <robertwessel2@yahoo.com> - 2018-03-22 11:47 -0500
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-24 00:59 -0700
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 15:07 +0000
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-19 15:37 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 17:16 +0000
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-19 20:30 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 21:24 +0000
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-19 23:06 +0000
Re: Dropping C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-20 14:04 +0000
Re: Dropping C supercat@casperkitty.com - 2018-03-19 15:32 -0700
Re: Dropping C Robert Wessel <robertwessel2@yahoo.com> - 2018-03-19 19:03 -0500
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 02:13 +0000
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-20 14:25 +0100
Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-21 18:36 +0100
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-19 23:33 +0100
Re: Dropping C supercat@casperkitty.com - 2018-03-19 16:34 -0700
Re: Dropping C asetofsymbols@gmail.com - 2018-03-20 00:58 -0700
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-20 01:10 -0700
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-19 14:25 +1300
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-21 12:19 +0000
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-23 17:46 +0100 |
| Message-ID | <p93b15$hof$1@dont-email.me> |
| In reply to | #128247 |
On 23/03/18 16:55, GOTHIER Nathan wrote: > On Fri, 23 Mar 2018 14:54:49 +0100 > David Brown <david.brown@hesbynett.no> wrote: > >> C has few enough features for keeping code organised, modular and >> structured - it is simply idiotic to pick such a tedious, inefficient >> and unsafe code organisation and fail to use the programming tools >> available. > > Do you have more arguments than insults? > No, I think these comments on the "one file per function" stand fine by themselves. I'd be surprised if other people find it hard to see the many disadvantages of such a structure, so there is no need to go into details. (I /can/ give details, of course, if people want them.) You are free to organise your code as you want - and I am free to think it is an absurd way to do it. It is almost certainly not the /worst/ way to organise code (putting everything in a single file is arguably worse, at least if the project is not tiny, and I have seen some jumbles that were a complete mess). There is one place I have seen an approximate "one file per function" organisation - and that is for libraries designed long ago for minimal code size, before compilers and linkers were smarter, for situations where most users will only want a few functions out of a big library. Even then, however, you would usually have multiple functions in a file if they were naturally used together, and if you had sub-functions that were not exported but were only used locally by one exported function, then these would be given as static functions in the same file.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2018-03-24 02:50 +0100 |
| Message-ID | <20180324025002.e9ffc7d7ad1b4f8cc4fce677@gmail.com> |
| In reply to | #128209 |
On Thu, 22 Mar 2018 18:22:43 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> I am talking about static functions not objects. If you have only one
> function per file you can't use static (i.e. "non-global")
> functions. I was just saying that seems a step too far for me. I
> could understand a rule that was one function wither external linkage
> per file, but not the more absolute one function per file.
Actually you can use static functions with only one function definiton
by source file.
According to the standard in 5.1.1.1:
"A source file together with all the headers and source files included
via the preprocessing directive #include is known as a [preprocessing
translation unit]. After preprocessing, a preprocessing translation
unit is called a [translation unit]."
I just made the following test:
/* pfunc1.c */
#if (defined(PFUNC1) == 0)
#define PFUNC1 1
static int pfunc1(void)
{
int x = 0;
return x;
}
#endif
/* func.c */
#if (defined(FUNC) == 0)
#define FUNC 1
#include "pfunc1.c"
int func(void)
{
int x = pfunc1();
return x;
}
#endif
c89 -c pfunc.c
readelf -s pfunc.o
It appears in the symbol table that pfunc1 is "local" whereas func is
"global".
--
GOTHIER Nathan
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2018-03-24 02:54 +0100 |
| Message-ID | <20180324025408.a8267ef475de05c39501bd65@gmail.com> |
| In reply to | #128209 |
On Thu, 22 Mar 2018 18:22:43 +0000 Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > I am talking about static functions not objects. If you have only one > function per file you can't use static (i.e. "non-global") > functions. I was just saying that seems a step too far for me. I > could understand a rule that was one function wither external linkage > per file, but not the more absolute one function per file. c89 -c func.c readelf -s func.o Typo. -- GOTHIER Nathan
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-03-22 16:43 +0000 |
| Message-ID | <t2RsC.45725$LZ3.37146@fx35.iad> |
| In reply to | #128193 |
bartc <bc@freeuk.com> writes: >On 22/03/2018 14:41, GOTHIER Nathan wrote: >> On 22 Mar 2018 13:37:18 GMT >> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: >> >> >>> On the other hand, jigsaw puzzles are meant as an amusing way of >>> complicating the process of looking at a pretty picture ... >> >> Fortunately source files are more like Lego bricks than puzzle >> pieces. :-) > >Do you really have each function in its own file? > >You must have many thousands of such files floating around then. Aren't >they organised into modules? > >Are they split up into separate 'modules' using directories? (Which >seems to be complicated way of implementing a normal 'source file'.) Here's an example source tree browser with thousands of source files. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/?h=v4.16-rc6 I suggest you spend some time studying it to see how large portable codebases are managed.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-22 10:39 -0700 |
| Message-ID | <ln370sovr6.fsf@kst-u.example.com> |
| In reply to | #128198 |
scott@slp53.sl.home (Scott Lurndal) writes:
> bartc <bc@freeuk.com> writes:
[...]
>>Do you really have each function in its own file?
>>
>>You must have many thousands of such files floating around then. Aren't
>>they organised into modules?
>>
>>Are they split up into separate 'modules' using directories? (Which
>>seems to be complicated way of implementing a normal 'source file'.)
>
> Here's an example source tree browser with thousands of source files.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/?h=v4.16-rc6
>
> I suggest you spend some time studying it to see how large portable codebases
> are managed.
That's the Linux kernel. It has multiple functions per source file, so
it's not relevant to bart's question, which was specifically about
having each function in its own source file.
--
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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-03-22 11:47 -0500 |
| Message-ID | <qbn7bdhlvopfc6cnq3qrbcukiic0jhr2h7@4ax.com> |
| In reply to | #128193 |
On Thu, 22 Mar 2018 14:58:51 +0000, bartc <bc@freeuk.com> wrote: >On 22/03/2018 14:41, GOTHIER Nathan wrote: >> On 22 Mar 2018 13:37:18 GMT >> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: >> >> >>> On the other hand, jigsaw puzzles are meant as an amusing way of >>> complicating the process of looking at a pretty picture ... >> >> Fortunately source files are more like Lego bricks than puzzle >> pieces. :-) > >Do you really have each function in its own file? > >You must have many thousands of such files floating around then. Aren't >they organised into modules? > >Are they split up into separate 'modules' using directories? (Which >seems to be complicated way of implementing a normal 'source file'.) > >How you do refer to one function from another - how does the compiler >get at that file that the function is in? Are there special header files >containing hundreds of include statements? > >Or the files grouped somehow so that they form larger translation units? >(It would be hard to refer to static function in its own file otherwise.) > >If you have to #include each file, do you run into problems with the >include search algorithm, where if you misspell the name, or the file is >missing, it will end up silently using the wrong version from elsewhere? > >What happens when you rename a function; you have to rename the file >too? (And its #include line.) > >Suppose you want to use the same name function in different parts of the >program (ie. different modules when you do things 'normally'); are you >obliged to use sub-directories? > >Does an #include line then have to include both subdirectory name /and/ >the name of function? Or are there different levels of include files so >you include one inside a subdirectory, and that one includes all the >files there? > >What file do you submit to a compiler? Or do you have to compile >thousands of files? > >The whole thing sounds both completely crazy and a total nightmare. While I personally think that in most cases a single function per source file is a bit too small a standard, keeping the individual source files pretty small is crucial for a medium or large sized project with multiple developers.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-24 00:59 -0700 |
| Message-ID | <0bec9c47-412f-465f-b634-c7208a21cfeb@googlegroups.com> |
| In reply to | #128193 |
On Thursday, March 22, 2018 at 7:58:51 AM UTC-7, Bart wrote: > On 22/03/2018 14:41, GOTHIER Nathan wrote: > > On 22 Mar 2018 13:37:18 GMT > > Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: > > > > > >> On the other hand, jigsaw puzzles are meant as an amusing way of > >> complicating the process of looking at a pretty picture ... > > > > Fortunately source files are more like Lego bricks than puzzle > > pieces. :-) > > Do you really have each function in its own file? > > You must have many thousands of such files floating around then. Aren't > they organised into modules? > > Are they split up into separate 'modules' using directories? (Which > seems to be complicated way of implementing a normal 'source file'.) > > How you do refer to one function from another - how does the compiler > get at that file that the function is in? Are there special header files > containing hundreds of include statements? > > Or the files grouped somehow so that they form larger translation units? > (It would be hard to refer to static function in its own file otherwise.) > > If you have to #include each file, do you run into problems with the > include search algorithm, where if you misspell the name, or the file is > missing, it will end up silently using the wrong version from elsewhere? > > What happens when you rename a function; you have to rename the file > too? (And its #include line.) > > Suppose you want to use the same name function in different parts of the > program (ie. different modules when you do things 'normally'); are you > obliged to use sub-directories? > > Does an #include line then have to include both subdirectory name /and/ > the name of function? Or are there different levels of include files so > you include one inside a subdirectory, and that one includes all the > files there? > > What file do you submit to a compiler? Or do you have to compile > thousands of files? > > The whole thing sounds both completely crazy and a total nightmare. > > -- > bartc Linux offers the least to the least. You've proven that it is David 'The Flooder' Brown. What kushal bhattacharya does is certainly more error resistant. Give a case study of a profitable enterprise that has made its fortune by not caring about its customers and services. -- Curious how these posts are made? www.youtube.com/watch?v=0ZNxaaKD7-c
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-19 15:07 +0000 |
| Message-ID | <dnQrC.46794$Il7.3609@fx46.am4> |
| In reply to | #127996 |
On 19/03/2018 13:34, Noob wrote: > On 19/03/2018 01:24, bartc wrote: > >> Sorry but I've never found it comfortable nor productive writing C >> with its many annoyances that I've listed from time to time. > > It makes no sense to me that you spend so much time criticizing C > in a C newsgroup. What do you hope to achieve? > > It's fine for you to enjoy other languages. Why are you trying > to convince us that C sucks? > That's not so hard to do, because it seems to be generally agreed that many of C's design choices /do/ suck. Except my list of such things is much longer than other people's.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-03-19 15:37 +0000 |
| Message-ID | <KOQrC.13910$qM7.7763@fx29.iad> |
| In reply to | #128002 |
bartc <bc@freeuk.com> writes: >On 19/03/2018 13:34, Noob wrote: >> On 19/03/2018 01:24, bartc wrote: >> >>> Sorry but I've never found it comfortable nor productive writing C >>> with its many annoyances that I've listed from time to time. >> >> It makes no sense to me that you spend so much time criticizing C >> in a C newsgroup. What do you hope to achieve? >> >> It's fine for you to enjoy other languages. Why are you trying >> to convince us that C sucks? >> > >That's not so hard to do, because it seems to be generally agreed that >many of C's design choices /do/ suck. Generally agreed by you and the kitty, perhaps, but not by the rest of the world.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-19 17:16 +0000 |
| Message-ID | <NfSrC.254622$K43.16500@fx31.am4> |
| In reply to | #128005 |
On 19/03/2018 15:37, Scott Lurndal wrote: > bartc <bc@freeuk.com> writes: >> On 19/03/2018 13:34, Noob wrote: >>> On 19/03/2018 01:24, bartc wrote: >>> >>>> Sorry but I've never found it comfortable nor productive writing C >>>> with its many annoyances that I've listed from time to time. >>> >>> It makes no sense to me that you spend so much time criticizing C >>> in a C newsgroup. What do you hope to achieve? >>> >>> It's fine for you to enjoy other languages. Why are you trying >>> to convince us that C sucks? >>> >> >> That's not so hard to do, because it seems to be generally agreed that >> many of C's design choices /do/ suck. > > Generally agreed by you and the kitty, perhaps, but not by the rest of the world. Which means, what, that: * Allowing both = and == in expressions was a good idea * The inside-out type declaration syntax was a good idea * Allowing () parameter lists was a good idea * Always requiring break inside case blocks was a good idea * Having loop-break and switch-break clash was a good idea * Allowing uint64_t, unsigned long long, long unsigned long int, int unsigned long long etc etc for the same primitive word type was a good idea * Allowing const const const const int const const (to mean a single const int) was a good idea * Allowing long int const typedef T was a good idea. * Allowing typedef void F(int,int); was a good idea (how many know what it means?) * NOT having a scoped, named constant value of any type was a good idea * Having separate namespaces for struct/enum and everything else except labels was a good idea ... I can keep this up for hours. People tolerate C because at this level there are too few choices (there is C++ which is even worse). But they shouldn't make out it is a perfect language where nothing sucks. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-03-19 20:30 +0000 |
| Message-ID | <87o9jj24gq.fsf@bsb.me.uk> |
| In reply to | #128012 |
bartc <bc@freeuk.com> writes: <snip> >>> On 19/03/2018 13:34, Noob wrote: <snip> >>>> It makes no sense to me that you spend so much time criticizing C >>>> in a C newsgroup. What do you hope to achieve? <snip> > ... I can keep this up for hours. I don't think anyone is in any doubt about that, but none of your replies have answered the question above. The answer could be very simple (maybe you just enjoy winding people up), or it could be very grand (you think you can build a coalition to achieve some goal or other), but there's been no answer so far. (Note that I don't think you owe any one an answer -- I'm just commenting that there has been none.) > People tolerate C because at this level there are too few choices > (there is C++ which is even worse). But they shouldn't make out it is > a perfect language where nothing sucks. This sort if misrepresentation of other people's views, and the fact that you've complained about Python on comp.lang.python, points to it being simply a form of entertainment. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-19 21:24 +0000 |
| Message-ID | <0UVrC.28792$e52.18314@fx25.am4> |
| In reply to | #128029 |
On 19/03/2018 20:30, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: > <snip> >>>> On 19/03/2018 13:34, Noob wrote: > <snip> >>>>> It makes no sense to me that you spend so much time criticizing C >>>>> in a C newsgroup. What do you hope to achieve? > <snip> >> ... I can keep this up for hours. > > I don't think anyone is in any doubt about that, but none of your > replies have answered the question above. The answer could be very > simple (maybe you just enjoy winding people up) I get the impression it's more the other way around. , or it could be very > grand (you think you can build a coalition to achieve some goal or > other), but there's been no answer so far. (Note that I don't think you > owe any one an answer -- I'm just commenting that there has been none.) Sadly I don't think anything I say will persuade anyone about anything nor encourage anyone else to develop anything new. And with lots of new languages developed on a large scale, this corner concerned with low-level programming has gotten even smaller. >> People tolerate C because at this level there are too few choices >> (there is C++ which is even worse). But they shouldn't make out it is >> a perfect language where nothing sucks. > > This sort if misrepresentation of other people's views, and the fact > that you've complained about Python on comp.lang.python, points to it > being simply a form of entertainment. That's a language I no longer get, if the threads I see in that group are representative of how people use it. If you submit any code that dares to actually do any work (and to do so in a clear, simple manner), then it's declared 'non-Pythonic'. It seems to have grown into a monster designed to be able to write as short and as cryptic programs as possible. I would have recommended it as a beginner's language a few years ago, but now I don't know what there is. (Apart from my stuff...) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-03-19 23:06 +0000 |
| Message-ID | <877eq71x90.fsf@bsb.me.uk> |
| In reply to | #128036 |
bartc <bc@freeuk.com> writes: > On 19/03/2018 20:30, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: >> <snip> >>>>> On 19/03/2018 13:34, Noob wrote: >> <snip> >>>>>> It makes no sense to me that you spend so much time criticizing C >>>>>> in a C newsgroup. What do you hope to achieve? >> <snip> >>> ... I can keep this up for hours. >> >> I don't think anyone is in any doubt about that, but none of your >> replies have answered the question above. The answer could be very >> simple (maybe you just enjoy winding people up) > > I get the impression it's more the other way around. > > , or it could be very >> grand (you think you can build a coalition to achieve some goal or >> other), but there's been no answer so far. (Note that I don't think you >> owe any one an answer -- I'm just commenting that there has been none.) > > Sadly I don't think anything I say will persuade anyone about anything > nor encourage anyone else to develop anything new. Oh well, I though you might like to say. Obviously not. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-03-20 14:04 +0000 |
| Message-ID | <slrnpb257i.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #128036 |
On Mon, 2018-03-19, bartc wrote: > On 19/03/2018 20:30, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: ... >>> People tolerate C because at this level there are too few choices >>> (there is C++ which is even worse). But they shouldn't make out it is >>> a perfect language where nothing sucks. >> >> This sort if misrepresentation of other people's views, and the fact >> that you've complained about Python on comp.lang.python, points to it >> being simply a form of entertainment. > > That's a language I no longer get, if the threads I see in that group > are representative of how people use it. Now and then I find myself agreeing with bartc, and this is one such occasion. Python is no longer as simple as once promised, and people (on clp at least) seem to enjoy their new toys too much. Of course, I don't complain endlessly in the newsgroup; I just visit it more rarely than I used to. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-19 15:32 -0700 |
| Message-ID | <0422cf79-be22-4aae-924c-03b74f4f09ea@googlegroups.com> |
| In reply to | #128012 |
On Monday, March 19, 2018 at 12:16:41 PM UTC-5, Bart wrote: > * Allowing typedef void F(int,int); was a good idea (how many know what > it means?) Exploiting that within header files could have greatly reduced build times on systems with floppies or other media that are slow relative to the CPU. Many functions will often have similar signatures, and using such a typedef would avoid the need to prototype them individually. Curiously, however, header files almost never do that. A tool that could take a human-readable header file and produce one that would behave identically while being much smaller could greatly improve build times, but I don't think I've seen one that would come anywhere near to optimal compression.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-03-19 19:03 -0500 |
| Message-ID | <4tj0bdl6iphgsso2l30ocm41bqls9ioj5l@4ax.com> |
| In reply to | #128047 |
On Mon, 19 Mar 2018 15:32:12 -0700 (PDT), supercat@casperkitty.com wrote: >On Monday, March 19, 2018 at 12:16:41 PM UTC-5, Bart wrote: >> * Allowing typedef void F(int,int); was a good idea (how many know what >> it means?) > >Exploiting that within header files could have greatly reduced build >times on systems with floppies or other media that are slow relative to >the CPU. Many functions will often have similar signatures, and using >such a typedef would avoid the need to prototype them individually. > >Curiously, however, header files almost never do that. A tool that >could take a human-readable header file and produce one that would behave >identically while being much smaller could greatly improve build times, >but I don't think I've seen one that would come anywhere near to optimal >compression. Pre-compiled headers pretty much solve that problem, although they do impose a few constraints on your development environment.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2018-03-20 02:13 +0000 |
| Message-ID | <weq1c3KhskkYpsW9x3VTy8bF6qO4k@bongo-ra.co> |
| In reply to | #128057 |
On Mon, 19 Mar 2018 19:03:32 -0500 Robert Wessel <robertwessel2@yahoo.com> wrote: > Pre-compiled headers pretty much solve that problem, although they do > impose a few constraints on your development environment. What's a precompiled header in the context of C ?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-20 14:25 +0100 |
| Message-ID | <p8r23i$vbb$2@dont-email.me> |
| In reply to | #128069 |
On 20/03/18 03:13, Spiros Bousbouras wrote: > On Mon, 19 Mar 2018 19:03:32 -0500 > Robert Wessel <robertwessel2@yahoo.com> wrote: >> Pre-compiled headers pretty much solve that problem, although they do >> impose a few constraints on your development environment. > > What's a precompiled header in the context of C ? > It is the same as a precompiled header in the context of C++ - but as C compilation is generally fast enough (and much faster than C++ compilation with a lot of header template libraries), it is rarely worth the effort in C.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2018-03-21 18:36 +0100 |
| Message-ID | <p8u563$uoj$1@dont-email.me> |
| In reply to | #128047 |
Le 19/03/2018 à 23:32, supercat@casperkitty.com a écrit :
> Curiously, however, header files almost never do that. A tool that
> could take a human-readable header file and produce one that would behave
> identically while being much smaller could greatly improve build times,
> but I don't think I've seen one that would come anywhere near to optimal
> compression.
>
I have developped such a tool for massaging MSVC header files into C
header files.
This tool eliminates all extraneous, non standard constructs, and
reduces file size by
1) Eliminates all unneeded whjite space and comments
2) Eliminates all identifiers from prototypes
int fn(
int firstArgument,
char *secondArgument
);
becomes
int fn(int,char *);
2) Compresses immediate constants to its smallest text representation:
#define foo 0x00000001
becomes
#define foo 1
and many other small things. It achieves compression levels comparable
to zip, with the advantage that the compressed file is still readable.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-19 23:33 +0100 |
| Message-ID | <p8pdre$psf$1@dont-email.me> |
| In reply to | #128012 |
On 19/03/18 18:16, bartc wrote: > On 19/03/2018 15:37, Scott Lurndal wrote: >> bartc <bc@freeuk.com> writes: >>> On 19/03/2018 13:34, Noob wrote: >>>> On 19/03/2018 01:24, bartc wrote: >>>> >>>>> Sorry but I've never found it comfortable nor productive writing C >>>>> with its many annoyances that I've listed from time to time. >>>> >>>> It makes no sense to me that you spend so much time criticizing C >>>> in a C newsgroup. What do you hope to achieve? >>>> >>>> It's fine for you to enjoy other languages. Why are you trying >>>> to convince us that C sucks? >>>> >>> >>> That's not so hard to do, because it seems to be generally agreed that >>> many of C's design choices /do/ suck. >> >> Generally agreed by you and the kitty, perhaps, but not by the rest >> of the world. > > Which means, what, that: > > * Allowing both = and == in expressions was a good idea Many people find that neat for particular idioms. I'm not keen on using "=" in expressions myself, but it is occasionally a good way to write the code. And having it allowed by the language is not a problem, assuming you use appropriate development tools. > > * The inside-out type declaration syntax was a good idea Type declaration is usually fine in C. If it is getting complicated or unclear, just use typedef's to simplify it. > > * Allowing () parameter lists was a good idea ? > > * Always requiring break inside case blocks was a good idea Ah, there I agree with you. See - it happens sometimes! > > * Having loop-break and switch-break clash was a good idea > > * Allowing uint64_t, unsigned long long, long unsigned long int, > int unsigned long long etc etc for the same primitive word type > was a good idea I would prefer the type system there to be somewhat different. That does not mean I think it is "generally agreed". > > * Allowing const const const const int const const (to mean a single > const int) was a good idea That is absolutely fine as far as I can see. > > * Allowing long int const typedef T was a good idea. That is an obsolete feature, one that I have never seen in real code, and one that is easily caught by compiler warnings or IDEs. As an obsoleted feature in the standards, you have grounds for saying there is general agreement that it is a bad idea. I would have been happier to see this an many other obsoleted features banned outright in C99 or C11. > > * Allowing typedef void F(int,int); was a good idea (how many know what > it means?) It defines a typedef for a function type. Usually I typedef pointers to function types, but people have different preferences here. I never use a function pointer parameter without such a typedef - and I give parameter names in the typedef too. > > * NOT having a scoped, named constant value of any type was a good idea Constants in C are somewhat limited, I agree - they are better in C++. > > * Having separate namespaces for struct/enum and everything else except > labels was a good idea > > ... I can keep this up for hours. We know. However, while some of your points are good, the majority of them are just silly (I have seen your lists). Certainly they are very far from being "generally agreed". > > People tolerate C because at this level there are too few choices (there > is C++ which is even worse). But they shouldn't make out it is a perfect > language where nothing sucks. > Nobody I have seen claims C is perfect. Many people - most people here - think it is good enough to be useful for a variety of purposes. Most think it is not going to change, no matter how much moaning and wailing goes on - and most think it is /good/ that there is little change because its stability and constancy is one of the language's most important features. And most people are happy to find ways to handle the quirks of the language that they like least - such as by using sensible development tools or writing their code in a way that makes sense.
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web