Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #147558 > unrolled thread
| Started by | DFS <nospam@dfs.com> |
|---|---|
| First post | 2019-11-03 17:39 -0500 |
| Last post | 2019-11-09 02:09 -0500 |
| Articles | 20 on this page of 112 — 21 participants |
Back to article view | Back to comp.lang.c
One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-03 17:39 -0500
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-04 00:20 +0000
Re: One works, the other doesn't? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-04 06:53 +0000
Re: One works, the other doesn't? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-04 09:45 -0500
Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-05 10:34 -0500
Re: One works, the other doesn't? mark.bluemel@gmail.com - 2019-11-05 07:45 -0800
Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-05 10:53 -0500
Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-05 08:04 -0800
Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-05 11:29 -0500
Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-05 23:24 +0100
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-05 23:06 +0000
Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-06 12:31 +1300
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-05 23:43 +0000
Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-06 12:54 +1300
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-06 01:35 +0000
Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-06 15:16 +1300
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-06 11:11 +0000
Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-06 01:59 -0800
Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-06 11:35 +0100
Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-06 08:57 -0800
Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-07 07:24 +1300
Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-06 22:59 +0100
Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-06 14:37 -0800
Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 00:58 +0100
Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-07 02:08 -0800
Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 15:43 +0100
Re: One works, the other doesn't? Robert Wessel <robertwessel2@yahoo.com> - 2019-11-07 16:15 -0600
Re: One works, the other doesn't? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-10 20:01 +0000
Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-11 15:26 +1300
Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-11 12:37 +0100
Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-07 07:21 +1300
Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-06 10:39 -0800
Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-07 07:47 +1300
Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-07 08:14 +1300
Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-06 12:30 -0800
Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 21:04 -0800
Re: One works, the other doesn't? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-09 01:37 -0800
Re: One works, the other doesn't? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-09 01:38 -0800
Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-10 08:32 +1300
Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 16:09 -0800
Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-29 11:33 +0100
Re: One works, the other doesn't? Öö Tiib <ootiib@hot.ee> - 2019-11-30 14:20 -0800
Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-12-01 12:15 +1300
Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-06 10:07 +0100
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-06 10:58 +0000
Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 10:05 +0100
Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-06 09:52 +0100
Re: One works, the other doesn't? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-06 00:56 -0800
Re: One works, the other doesn't? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-06 01:00 -0800
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-06 11:32 +0000
Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-06 23:11 +0100
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-06 23:22 +0000
Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 01:04 +0100
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 01:13 +0000
Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 10:22 +0100
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 11:51 +0000
Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 15:58 +0100
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 16:34 +0000
Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-07 12:40 -0500
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 17:57 +0000
Re: One works, the other doesn't? Keith Thompson <kst-u@mib.org> - 2019-11-07 21:14 -0800
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-08 09:45 +0000
Re: One works, the other doesn't? Keith Thompson <kst-u@mib.org> - 2019-11-08 09:56 -0800
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-08 19:47 +0000
Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-09 09:14 +1300
Re: One works, the other doesn't? Keith Thompson <kst-u@mib.org> - 2019-11-08 19:10 -0800
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-09 12:24 +0000
Like an old married couple... (Was: One works, the other doesn't?) gazelle@shell.xmission.com (Kenny McCormack) - 2019-11-08 20:25 +0000
Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 19:58 +0100
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 19:31 +0000
Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-08 08:56 +1300
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 20:06 +0000
Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-08 09:21 +1300
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 21:20 +0000
Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-08 10:28 +1300
Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 22:35 +0000
Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-09 09:22 +1300
Re: One works, the other doesn't? jadill33@gmail.com - 2019-11-07 08:37 -0800
Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-07 08:52 -0800
Re: One works, the other doesn't? jadill33@gmail.com - 2019-11-07 09:52 -0800
Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 20:04 +0100
Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 19:50 -0800
Re: One works, the other doesn't? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 18:05 +0100
Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-05 09:28 -0800
Re: One works, the other doesn't? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 19:02 +0100
Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-05 23:21 +0100
Re: One works, the other doesn't? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 18:36 +0100
Re: One works, the other doesn't? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-05 12:51 -0500
Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-05 18:35 -0500
Re: One works, the other doesn't? Barry Schwarz <schwarzb@delq.com> - 2019-11-05 17:53 -0800
Re: One works, the other doesn't? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-06 09:33 -0500
Re: One works, the other doesn't? Barry Schwarz <schwarzb@delq.com> - 2019-11-05 13:36 -0800
Re: One works, the other doesn't? jak <nospam@please.ty> - 2019-11-07 10:17 +0100
Re: One works, the other doesn't? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-07 12:19 +0000
Re: One works, the other doesn't? jak <nospam@please.ty> - 2019-11-07 18:59 +0100
Re: One works, the other doesn't? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-08 00:02 +0000
Re: One works, the other doesn't? jak <nospam@please.ty> - 2019-11-20 10:54 +0100
Re: One works, the other doesn't? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-20 11:14 +0000
Re: One works, the other doesn't? jak <nospam@please.ty> - 2019-11-20 13:22 +0100
Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 15:54 -0800
Re: One works, the other doesn't? Keith Thompson <kst-u@mib.org> - 2019-11-20 08:42 -0800
Re: One works, the other doesn't? Manfred <noname@add.invalid> - 2019-11-21 18:56 +0100
Re: One works, the other doesn't? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-22 01:07 +0000
Re: One works, the other doesn't? Manfred <noname@add.invalid> - 2019-11-22 15:27 +0100
Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 15:47 -0800
Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-07 18:41 -0500
Re: One works, the other doesn't? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 17:39 +0100
Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-05 11:47 -0500
Re: One works, the other doesn't? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 17:54 +0100
Re: One works, the other doesn't? luser droog <luser.droog@gmail.com> - 2019-11-05 09:00 -0800
Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 21:02 -0800
Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-09 02:09 -0500
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-29 11:33 +0100 |
| Message-ID | <qrqs5m$tqr$1@dont-email.me> |
| In reply to | #148204 |
On 29/11/2019 01:09, Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> On 09/11/2019 18:04, Tim Rentsch wrote: >> >>> Ian Collins <ian-news@hotmail.com> writes: >>> >>>> On 07/11/2019 07:39, Malcolm McLean wrote: >>>> >>>>> Test-driven development isn't feasible for us. >>>> >>>> What makes it unfeasible for you? >>> >>> Some people just don't like the taste of kool-aid. >> >> I know you find the concept of writing tested code hard to grasp, but >> others find it quite simple. > > I understand it just fine. And it's disappointing that you > chose to respond not on the substance of the subject but > instead just to make an ad hominem remark. A surefire way > of telling that someone is selling programming snake oil > is when they start saying things like "you just don't get > it." > > Incidentally, TDD != writing tested code. And I understand > that too. But go ahead and make some more ad hominem remarks > if it makes you feel better. > You started the ad hominem replies. Ian asked a specific question - "what makes TDD unfeasible for you?". The question wasn't directed at you, but this is Usenet - questions are for everyone. However, rather than saying why TDD is not suitable for your work, or why you think it might be unsuitable for others, you choose to mock it and its supporters with your "Kool-aid" comment. If you want to encourage a more technical discussion, that's fair enough - but please do so by example, rather than by hypocrisy and patronising posts.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-30 14:20 -0800 |
| Message-ID | <0ae9ddd3-9ef7-4732-8083-61c43c453eb7@googlegroups.com> |
| In reply to | #148278 |
On Friday, 29 November 2019 12:33:36 UTC+2, David Brown wrote: > On 29/11/2019 01:09, Tim Rentsch wrote: > > Ian Collins <ian-news@hotmail.com> writes: > > > >> On 09/11/2019 18:04, Tim Rentsch wrote: > >> > >>> Ian Collins <ian-news@hotmail.com> writes: > >>> > >>>> On 07/11/2019 07:39, Malcolm McLean wrote: > >>>> > >>>>> Test-driven development isn't feasible for us. > >>>> > >>>> What makes it unfeasible for you? > >>> > >>> Some people just don't like the taste of kool-aid. > >> > >> I know you find the concept of writing tested code hard to grasp, but > >> others find it quite simple. > > > > I understand it just fine. And it's disappointing that you > > chose to respond not on the substance of the subject but > > instead just to make an ad hominem remark. A surefire way > > of telling that someone is selling programming snake oil > > is when they start saying things like "you just don't get > > it." > > > > Incidentally, TDD != writing tested code. And I understand > > that too. But go ahead and make some more ad hominem remarks > > if it makes you feel better. > > > > You started the ad hominem replies. Ian asked a specific question - > "what makes TDD unfeasible for you?". The question wasn't directed at > you, but this is Usenet - questions are for everyone. However, rather > than saying why TDD is not suitable for your work, or why you think it > might be unsuitable for others, you choose to mock it and its supporters > with your "Kool-aid" comment. > > If you want to encourage a more technical discussion, that's fair enough > - but please do so by example, rather than by hypocrisy and patronising > posts. Tim is somehow getting incapable of realizing that what he himself wrote was just nothing of substance but empty insult. With such replies he loses face. But he was scholar of programming already in eighties. Maybe it is because of age.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-12-01 12:15 +1300 |
| Message-ID | <h4gbh0Fft80U2@mid.individual.net> |
| In reply to | #148204 |
On 29/11/2019 13:09, Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> On 09/11/2019 18:04, Tim Rentsch wrote: >> >>> Ian Collins <ian-news@hotmail.com> writes: >>> >>>> On 07/11/2019 07:39, Malcolm McLean wrote: >>>> >>>>> Test-driven development isn't feasible for us. >>>> >>>> What makes it unfeasible for you? >>> >>> Some people just don't like the taste of kool-aid. >> >> I know you find the concept of writing tested code hard to grasp, but >> others find it quite simple. > > I understand it just fine. And it's disappointing that you > chose to respond not on the substance of the subject but > instead just to make an ad hominem remark. A surefire way > of telling that someone is selling programming snake oil > is when they start saying things like "you just don't get > it." Yet another vacuous pot, kettle post... I received the answer I was looking for from the parson I was asking, so your unhelpful replay was of no value. > Incidentally, TDD != writing tested code. And I understand > that too. But go ahead and make some more ad hominem remarks > if it makes you feel better. I'm much happier writing code I know does what I intended it to do than code which I think will do what I intended it to do! -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-06 10:07 +0100 |
| Message-ID | <qpu2gq$7nk$1@dont-email.me> |
| In reply to | #147643 |
On 06/11/2019 00:43, Bart wrote: > On 05/11/2019 23:31, Ian Collins wrote: >> On 06/11/2019 12:06, Bart wrote: >>> On 05/11/2019 22:24, David Brown wrote: >>>> >>>> /Why/ are you using tcc? If you were developing on a tiny or ancient >>>> computer, I could understand it. But gcc is a vastly better compiler, >>>> especially during development. >>> >>> gcc is a bit of a dog, especially with larger programs, or you are >>> including some hefty headers. >>> >>> You want something nippy during development. >> >> You want to find as many issues in your code a quickly as possible >> during development. > > You also want as little distraction from non-issues as possible. I've > been left in the dark as to whether an executable has actually been > created or not because any 'error' message will be swamped by irrelevant > warnings. It doesn't matter if an executable was made or not (though failing to know if it succeeded is a testament to your lack of a decent build process). If you have warnings from your compiler, it means one of three things: 1. You have mistakes in your code. 2. You haven't used your tools correctly for the kind of code you want to write. 3. You are still in the middle of writing the base code, and are not yet ready to test the executable anyway. > And there will be plenty of warnings in unfinished code. > > I don't want to waste time dealing with warnings that will only be > temporary, or I know are not relevant or not important. > > If I run gcc with no options, I get fewer warnings, but it isn't > actually that much faster. > > As I said, it's a dog. > > (However I'm impressed by the 'geany' editor the OP uses and which I've > just downloaded. Not enough to use it (it doesn't have hard line stops), > but it makes my code look good even if it has no idea what language it is!) > >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-06 10:58 +0000 |
| Message-ID | <DHxwF.34191$xi6.28303@fx40.am4> |
| In reply to | #147655 |
On 06/11/2019 09:07, David Brown wrote: > On 06/11/2019 00:43, Bart wrote: >> On 05/11/2019 23:31, Ian Collins wrote: >>> On 06/11/2019 12:06, Bart wrote: >>>> On 05/11/2019 22:24, David Brown wrote: >>>>> >>>>> /Why/ are you using tcc? If you were developing on a tiny or ancient >>>>> computer, I could understand it. But gcc is a vastly better compiler, >>>>> especially during development. >>>> >>>> gcc is a bit of a dog, especially with larger programs, or you are >>>> including some hefty headers. >>>> >>>> You want something nippy during development. >>> >>> You want to find as many issues in your code a quickly as possible >>> during development. >> >> You also want as little distraction from non-issues as possible. I've >> been left in the dark as to whether an executable has actually been >> created or not because any 'error' message will be swamped by irrelevant >> warnings. > > It doesn't matter if an executable was made or not (though failing to > know if it succeeded is a testament to your lack of a decent build > process). If you have warnings from your compiler, it means one of > three things: > > 1. You have mistakes in your code. > 2. You haven't used your tools correctly for the kind of code you want > to write. > 3. You are still in the middle of writing the base code, and are not yet > ready to test the executable anyway. Have a look at the link to the file mu64.c I posted a few days ago. That's a Linux version; the very similar mc64.c Windows version will generate 18,000 files of warnings given these options: -Wall -Wextra -ansi -pedantic -Wformat-nonliteral -Wcast-align -Wpointer-arith -Wbad-function-cast -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Winline -Wundef -Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings -Wno-conversion -ffloat-store -O2 -std=c11 According to you, there are mistakes there and the program shouldn't run or it's not ready. But I've used that program via gcc with zero warnings, and it works perfectly for my purposes, and certainly for the purpose I posted it. So you're wrong. I as the programmer have stipulated a particular set of options as part of the 'make file' so that it is effectively part of the source code (namely 'gcc mc64.c -omc.exe'). If someone overrides that, then that is up to them. I'm sure I can play the same game with any substantial body of C code: find enough options to make it generate warnings and suggest that the program might be buggy.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-07 10:05 +0100 |
| Message-ID | <qq0moe$76e$1@dont-email.me> |
| In reply to | #147661 |
On 06/11/2019 11:58, Bart wrote: > On 06/11/2019 09:07, David Brown wrote: >> On 06/11/2019 00:43, Bart wrote: >>> On 05/11/2019 23:31, Ian Collins wrote: >>>> On 06/11/2019 12:06, Bart wrote: >>>>> On 05/11/2019 22:24, David Brown wrote: >>>>>> >>>>>> /Why/ are you using tcc? If you were developing on a tiny or ancient >>>>>> computer, I could understand it. But gcc is a vastly better >>>>>> compiler, >>>>>> especially during development. >>>>> >>>>> gcc is a bit of a dog, especially with larger programs, or you are >>>>> including some hefty headers. >>>>> >>>>> You want something nippy during development. >>>> >>>> You want to find as many issues in your code a quickly as possible >>>> during development. >>> >>> You also want as little distraction from non-issues as possible. I've >>> been left in the dark as to whether an executable has actually been >>> created or not because any 'error' message will be swamped by irrelevant >>> warnings. >> >> It doesn't matter if an executable was made or not (though failing to >> know if it succeeded is a testament to your lack of a decent build >> process). If you have warnings from your compiler, it means one of >> three things: >> >> 1. You have mistakes in your code. >> 2. You haven't used your tools correctly for the kind of code you want >> to write. >> 3. You are still in the middle of writing the base code, and are not yet >> ready to test the executable anyway. > > Have a look at the link to the file mu64.c I posted a few days ago. > > That's a Linux version; the very similar mc64.c Windows version will > generate 18,000 files of warnings given these options: > > -Wall -Wextra -ansi -pedantic -Wformat-nonliteral -Wcast-align > -Wpointer-arith -Wbad-function-cast -Wmissing-prototypes > -Wstrict-prototypes -Wmissing-declarations -Winline -Wundef > -Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings > -Wno-conversion -ffloat-store -O2 -std=c11 > > According to you, there are mistakes there and the program shouldn't run > or it's not ready. I gave you three options. Let's assume you think the code is finished, so 3 does not apply. Which option is appropriate will depend on which of these warnings trigger on the code. If "-Wwrite-strings" or "-Wbad-function-cast" is triggered, for example, then you have mistakes in your code. (Whether it is your compiler/translator that is wrong, or the source in your special language, I can't tell you.) If it is something like "-Wcast-align" or "-Wpointer-arith" that is triggered, then your code might be okay but very non-portable - then /you/ decide if it is 1 or 2. If it is "-Wmissing-prototypes", the code is written in a silly and risky style - again, you decide if that is 1 or 2. > > But I've used that program via gcc with zero warnings, and it works > perfectly for my purposes, and certainly for the purpose I posted it. > > So you're wrong. I as the programmer have stipulated a particular set of > options as part of the 'make file' so that it is effectively part of the > source code (namely 'gcc mc64.c -omc.exe'). No, I am not wrong here - you have (probably intentionally) misunderstood. If you are getting warnings from your compiler, one of the three options I gave above apply. If you /choose/ to disable warnings (and are happy with your code) then you are fixing problem 2 above - changing the way you use the tools so that you don't get warnings. > > If someone overrides that, then that is up to them. I'm sure I can play > the same game with any substantial body of C code: find enough options > to make it generate warnings and suggest that the program might be buggy. > >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-06 09:52 +0100 |
| Message-ID | <qpu1k7$33k$1@dont-email.me> |
| In reply to | #147638 |
On 06/11/2019 00:06, Bart wrote:
> On 05/11/2019 22:24, David Brown wrote:
>> On 05/11/2019 17:29, DFS wrote:
>>> On 11/5/2019 11:04 AM, Malcolm McLean wrote:
>>>> On Tuesday, 5 November 2019 15:52:48 UTC, DFS wrote:
>>>>> On 11/5/2019 10:45 AM, mark.bluemel@gmail.com wrote:
>>>>>> On Tuesday, 5 November 2019 15:34:32 UTC, DFS wrote:
>>>>>>
>>>>>>> printf("%.4s remove %d
>>>>>>> dupes\n",elapsedtime(start),arrsize-cnt);
>>>>>>
>>>>>> "%.4s" is a (slightly unusual) format specifier for a string.
>>>>>> It's a
>>>>>> totally unsuitable format specifier for a double value, which I think
>>>>>> is what elapsedtime() returns. I'd kind of expect it to fail, in some
>>>>>> unpredictable manner, as the printf routine tries to treat a
>>>>>> double as
>>>>>> a pointer-to-char and disappears into some abyss or other.
>>>>>
>>>>>
>>>>> Dude! It's a format specifier for a double (elapsed time), but I
>>>>> inadvertently dropped the f (should be .4fs, where the s is short for
>>>>> seconds).
>>>>>
>>>>> This was causing my program to fail, and I didn't look closely
>>>>> enough at
>>>>> that line. Now I'm golden - I think.
>>>>>
>>>>> Thanks for spotting it!
>>>>>
>>>> If you use a good modern IDE, it will warn you when the format string
>>>> and the arguments don't match.
>>>
>>>
>>> I'm using geany and Tiny C Compiler (Windows). Neither one catches
>>> it (I wouldn't expect Geany to).
>>>
>>
>> /Why/ are you using tcc? If you were developing on a tiny or ancient
>> computer, I could understand it. But gcc is a vastly better compiler,
>> especially during development.
>
> gcc is a bit of a dog, especially with larger programs, or you are
> including some hefty headers.
I can certainly agree that tcc is faster than gcc. I don't agree that
it is relevant. The OP is not writing large programs, he is not
including hefty headers, and he is not running on an ancient computer.
>
> You want something nippy during development. You can still run gcc with
> all its options every so often, or if stuck with some bug, or for
> production code to get the best performance.
Sometimes I wonder what you have been doing for the last several
decades. Do you just bash out code at the keyboard, fixing things until
you can persuade a compiler to make an executable, and expect any
problems to be detected by the end user? "It compiles, so it's ready to
ship?" Or do the keystrokes pour from your fingers like liquid gold,
without a hint of error?
What most of us do is known as "software development". It is a process,
done in a series of iterative stages. At each stage, there will be
problems and errors - your aim is to minimise the risk of such errors,
and maximise the chances of finding the errors before they progress to
the next stage. It is almost always more efficient to catch the errors
earlier rather than later.
That means when you are at the code writing stage, you want an editor or
IDE that will guide you and check for simple things. If you have missed
a close bracket in an expression, you want your editor to tell you
/now/, while you are concentrating on that code, not an hour later when
you are working on something completely different but tried a compile.
When you run your compiler, you want it to find as many potential errors
as it can. You want your compiler to tell you when you forgot to
initialise a variable before using it - you don't want to find out by
noticing an unrepeatable problem that sometimes happens at the
customer's site. And you want your compiler to tell you as much as it
can about the problem, and your IDE to let you jump directly to the
problem line in the code.
This is called "using the best tools for the job", and "knowing your
tools". It applies to any craft, not just programming.
So who gives a *beep* if the compiler takes 2 seconds rather than 0.2
seconds, when the better tool saves you hours, or your company's reputation?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-06 00:56 -0800 |
| Message-ID | <qpu1r3$18qt$1@gioia.aioe.org> |
| In reply to | #147651 |
On 11/6/2019 12:52 AM, David Brown wrote:
> On 06/11/2019 00:06, Bart wrote:
>> On 05/11/2019 22:24, David Brown wrote:
>>> On 05/11/2019 17:29, DFS wrote:
>>>> On 11/5/2019 11:04 AM, Malcolm McLean wrote:
>>>>> On Tuesday, 5 November 2019 15:52:48 UTC, DFS wrote:
>>>>>> On 11/5/2019 10:45 AM, mark.bluemel@gmail.com wrote:
>>>>>>> On Tuesday, 5 November 2019 15:34:32 UTC, DFS wrote:
>>>>>>>
>>>>>>>> printf("%.4s remove %d
>>>>>>>> dupes\n",elapsedtime(start),arrsize-cnt);
>>>>>>>
>>>>>>> "%.4s" is a (slightly unusual) format specifier for a string.
>>>>>>> It's a
>>>>>>> totally unsuitable format specifier for a double value, which I think
>>>>>>> is what elapsedtime() returns. I'd kind of expect it to fail, in some
>>>>>>> unpredictable manner, as the printf routine tries to treat a
>>>>>>> double as
>>>>>>> a pointer-to-char and disappears into some abyss or other.
>>>>>>
>>>>>>
>>>>>> Dude! It's a format specifier for a double (elapsed time), but I
>>>>>> inadvertently dropped the f (should be .4fs, where the s is short for
>>>>>> seconds).
>>>>>>
>>>>>> This was causing my program to fail, and I didn't look closely
>>>>>> enough at
>>>>>> that line. Now I'm golden - I think.
>>>>>>
>>>>>> Thanks for spotting it!
>>>>>>
>>>>> If you use a good modern IDE, it will warn you when the format string
>>>>> and the arguments don't match.
>>>>
>>>>
>>>> I'm using geany and Tiny C Compiler (Windows). Neither one catches
>>>> it (I wouldn't expect Geany to).
>>>>
>>>
>>> /Why/ are you using tcc? If you were developing on a tiny or ancient
>>> computer, I could understand it. But gcc is a vastly better compiler,
>>> especially during development.
>>
>> gcc is a bit of a dog, especially with larger programs, or you are
>> including some hefty headers.
>
> I can certainly agree that tcc is faster than gcc. I don't agree that
> it is relevant. The OP is not writing large programs, he is not
> including hefty headers, and he is not running on an ancient computer.
[...]
Fwiw, in the following thread:
https://groups.google.com/d/topic/comp.lang.c/a53VxN8cwkY/discussion
Well, my program runs on many different compilers now thanks to my
discussions with Bart.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-06 01:00 -0800 |
| Message-ID | <qpu23b$1b8q$1@gioia.aioe.org> |
| In reply to | #147652 |
On 11/6/2019 12:56 AM, Chris M. Thomasson wrote: > On 11/6/2019 12:52 AM, David Brown wrote: >> On 06/11/2019 00:06, Bart wrote: >>> On 05/11/2019 22:24, David Brown wrote: >>>> On 05/11/2019 17:29, DFS wrote: >>>>> On 11/5/2019 11:04 AM, Malcolm McLean wrote: >>>>>> On Tuesday, 5 November 2019 15:52:48 UTC, DFS wrote: >>>>>>> On 11/5/2019 10:45 AM, mark.bluemel@gmail.com wrote: >>>>>>>> On Tuesday, 5 November 2019 15:34:32 UTC, DFS wrote: [...] >> I can certainly agree that tcc is faster than gcc. I don't agree that >> it is relevant. The OP is not writing large programs, he is not >> including hefty headers, and he is not running on an ancient computer. > [...] > > Fwiw, in the following thread: > > https://groups.google.com/d/topic/comp.lang.c/a53VxN8cwkY/discussion > > Well, my program runs on many different compilers now thanks to my > discussions with Bart. > This one in particular, wrt getting my code to run on DMC: https://groups.google.com/d/msg/comp.lang.c/a53VxN8cwkY/w-sehZZmBwAJ
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-06 11:32 +0000 |
| Message-ID | <EbywF.36411$L91.11185@fx02.am4> |
| In reply to | #147651 |
On 06/11/2019 08:52, David Brown wrote: > On 06/11/2019 00:06, Bart wrote: > That means when you are at the code writing stage, you want an editor or > IDE that will guide you and check for simple things. If you have missed > a close bracket in an expression, you want your editor to tell you > /now/, while you are concentrating on that code, not an hour later when > you are working on something completely different but tried a compile. > > When you run your compiler, you want it to find as many potential errors > as it can. You want your compiler to tell you when you forgot to > initialise a variable before using it - you don't want to find out by > noticing an unrepeatable problem that sometimes happens at the > customer's site. And you want your compiler to tell you as much as it > can about the problem, and your IDE to let you jump directly to the > problem line in the code. > > This is called "using the best tools for the job", and "knowing your > tools". It applies to any craft, not just programming. > > So who gives a *beep* if the compiler takes 2 seconds rather than 0.2 > seconds, when the better tool saves you hours, or your company's reputation? Your post is contradictory. First you advocate using one tool to tell you as soon as possible that something is amiss in your code. But then you are suggesting that it doesn't matter how long the main compiler, the second tool, takes to build it! You don't seem to realise you are effectively using a very fast mini compiler front-end within your editor. There I guess it might matter if if didn't report something until several seconds later. Some of use are using the one tool for both purposes: using a dumb editor [but which can syntax-hilite my language], then running a fast compiler to check it. It just means the compiler is invoked manually (Ctrl-Z to save the file, and compile the project, E to edit the file containing the error at the error line, if there is a problem.) Here, the compiler doing a quick check is the same one that will generate the executable if it finds nothing wrong. BTW I write 100% my own tools. So I guess I know them pretty well...
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-06 23:11 +0100 |
| Message-ID | <qpvgdq$mg4$1@dont-email.me> |
| In reply to | #147663 |
On 06/11/2019 12:32, Bart wrote: > On 06/11/2019 08:52, David Brown wrote: >> On 06/11/2019 00:06, Bart wrote: > >> That means when you are at the code writing stage, you want an editor or >> IDE that will guide you and check for simple things. If you have missed >> a close bracket in an expression, you want your editor to tell you >> /now/, while you are concentrating on that code, not an hour later when >> you are working on something completely different but tried a compile. >> >> When you run your compiler, you want it to find as many potential errors >> as it can. You want your compiler to tell you when you forgot to >> initialise a variable before using it - you don't want to find out by >> noticing an unrepeatable problem that sometimes happens at the >> customer's site. And you want your compiler to tell you as much as it >> can about the problem, and your IDE to let you jump directly to the >> problem line in the code. >> >> This is called "using the best tools for the job", and "knowing your >> tools". It applies to any craft, not just programming. >> >> So who gives a *beep* if the compiler takes 2 seconds rather than 0.2 >> seconds, when the better tool saves you hours, or your company's >> reputation? > > Your post is contradictory. > > First you advocate using one tool to tell you as soon as possible that > something is amiss in your code. > > But then you are suggesting that it doesn't matter how long the main > compiler, the second tool, takes to build it! That is not contradictory, and it is not what I said. You want your tools to tell you about problems at the earliest possible stage. So an IDE, and tools run directly by it (such as cppcheck) are useful. You don't necessarily want to build all the time. A C compilation that takes a few seconds is not a burden on development, but you are still jumping back and forth between the editor and your compiler output window or list of errors and warnings. And an IDE-based ask-you-type checker will be optimised for that job - it will aim to show the problem there at the point in the code you are working on (usually without even having to save the code). So if you have forgotten a close brackets, you'll get a highlight at the relevant point - the compiler might give you hundreds of errors from that point onwards. They do different kinds of checks (with some overlap), with different emphases. Use both. > > You don't seem to realise you are effectively using a very fast mini > compiler front-end within your editor. No, I am not. It is a parser - not a compiler front-end. Different IDE's and tools vary in how much parsing they do, but they are often far from being complete language front-ends. > There I guess it might matter if > if didn't report something until several seconds later. You /want/ a few seconds delay. You don't want the wiggly red lines to appear just because you haven't finished typing the line. > > Some of use are using the one tool for both purposes: using a dumb > editor [but which can syntax-hilite my language], then running a fast > compiler to check it. It just means the compiler is invoked manually > (Ctrl-Z to save the file, and compile the project, E to edit the file > containing the error at the error line, if there is a problem.) I suggest using a better editor, and a better compiler. However, I can do that - because I use a well established language. > > Here, the compiler doing a quick check is the same one that will > generate the executable if it finds nothing wrong. > > BTW I write 100% my own tools. So I guess I know them pretty well...
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-06 23:22 +0000 |
| Message-ID | <5BIwF.44883$vV6.32008@fx17.am4> |
| In reply to | #147682 |
On 06/11/2019 22:11, David Brown wrote: > On 06/11/2019 12:32, Bart wrote: > You want your tools to tell you about problems at the earliest possible > stage. So an IDE, and tools run directly by it (such as cppcheck) are > useful. You still seem to be thinking of building in terms of some batch job which you try to avoid as much as possible. With a heavyweight compiler, that is understandable. > You don't necessarily want to build all the time. A C compilation that > takes a few seconds is not a burden on development, but you are still > jumping back and forth between the editor and your compiler output > window or list of errors and warnings. And an IDE-based ask-you-type > checker will be optimised for that job - it will aim to show the problem > there at the point in the code you are working on (usually without even > having to save the code). So if you have forgotten a close brackets, > you'll get a highlight at the relevant point - the compiler might give > you hundreds of errors from that point onwards. Let me put it another way: you seem to understand the disadvantages of a sluggish compiler and the overwhelming output it can generate from the most trivial typo. So instead you do what I do: use a nippier compiler like Tiny C. Only not explicitly; you use the equivalent inside your tool which does the same job. > They do different kinds of checks (with some overlap), with different > emphases. Use both. > >> >> You don't seem to realise you are effectively using a very fast mini >> compiler front-end within your editor. > > No, I am not. It is a parser - not a compiler front-end. Same result: you give it source code, and it tells you where there is something wrong. (I could couple my editor and compiler more closely so that I don't need to save, but I haven't bothered. Although there is also an extra complication in that any error might not be in the file I'm editing, but in an imported module. Then it is simpler to keep them looser. Making the coupling however is not hard.) > You /want/ a few seconds delay. You don't want the wiggly red lines to > appear just because you haven't finished typing the line. That's what would drive me up the wall. But sometimes you are doing a massive restructuring, and it will not be ready to attempt compiling for a long time. > I suggest using a better editor, and a better compiler. However, I can > do that - because I use a well established language. Well I generally use a better language, because I can do that.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-07 01:04 +0100 |
| Message-ID | <qpvn2u$qml$1@dont-email.me> |
| In reply to | #147687 |
On 07/11/2019 00:22, Bart wrote: > On 06/11/2019 22:11, David Brown wrote: >> On 06/11/2019 12:32, Bart wrote: > >> You want your tools to tell you about problems at the earliest >> possible stage. So an IDE, and tools run directly by it (such as >> cppcheck) are useful. > > You still seem to be thinking of building in terms of some batch job > which you try to avoid as much as possible. With a heavyweight compiler, > that is understandable. > You do like to misunderstand everything, don't you? >> You don't necessarily want to build all the time. A C compilation >> that takes a few seconds is not a burden on development, but you are >> still jumping back and forth between the editor and your compiler >> output window or list of errors and warnings. And an IDE-based >> ask-you-type checker will be optimised for that job - it will aim to >> show the problem there at the point in the code you are working on >> (usually without even having to save the code). So if you have >> forgotten a close brackets, you'll get a highlight at the relevant >> point - the compiler might give you hundreds of errors from that point >> onwards. > > > Let me put it another way: you seem to understand the disadvantages of a > sluggish compiler and the overwhelming output it can generate from the > most trivial typo. > > So instead you do what I do: use a nippier compiler like Tiny C. Only > not explicitly; you use the equivalent inside your tool which does the > same job. > Look, TCC is a limited toy. It doesn't do the job serious programmers need for development tools. It was never intended for that - it is made to be able to do compilations of finished, developed code even though you have a very limited host. (And it was made as a test, a learning/teaching tool, and a demonstration of compact compiler design.) You enjoy your toys - your home made ones, and favourite tiny little programs. Maybe they are okay for your hobby coding. I program professionally, so I use the best tools I can get for the job. Since these tools mostly happen to be zero cost, they are suitable for non-professionals too - but for only people who are actually interested in doing good development work.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-07 01:13 +0000 |
| Message-ID | <ddKwF.118673$ZO5.23938@fx26.am4> |
| In reply to | #147691 |
On 07/11/2019 00:04, David Brown wrote: > On 07/11/2019 00:22, Bart wrote: > Look, TCC is a limited toy. It doesn't do the job serious programmers > need for development tools. It was never intended for that - it is made > to be able to do compilations of finished, developed code even though > you have a very limited host. So why was it made fast? (And it was made as a test, a > learning/teaching tool, and a demonstration of compact compiler design.) From the web: "TinyCC (aka TCC) is a small but hyper fast C compiler. Unlike other C compilers, it is meant to be self-sufficient: you do not need an external assembler or linker because TCC does that for you. TCC compiles so fast that even for big projects Makefiles may not be necessary. TCC not only supports ANSI C, but also most of the new ISO C99 standard and many GNUC extensions. TCC can also be used to make C scripts, i.e. pieces of C source that you run as a Perl or Python script. Compilation is so fast that your script will be as fast as if it was an executable. TCC can also automatically generate memory and bound checks while allowing all C pointers operations. TCC can do these checks even if non patched libraries are used. With libtcc, you can use TCC as a backend for dynamic code generation." My own product is much more limited (not full C99, targets only Win64, various omissions and bugs), but has its own advantages, such as being more self-contained then tcc (ie. a single file), making it ultra-simple to run from anywhere, copy, download etc. Or send someone program source code, just add one extra file that is the compiler. > You enjoy your toys - your home made ones, and favourite tiny little > programs. Maybe they are okay for your hobby coding. I program > professionally, so I use the best tools I can get for the job. Since > these tools mostly happen to be zero cost, they are suitable for > non-professionals too - but for only people who are actually interested > in doing good development work. You just don't get it. You have a finished, working C application, but you inadvertently use tcc to compile the binary for a customer rather than gcc. Will they be able to tell the difference?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-07 10:22 +0100 |
| Message-ID | <qq0np1$cgc$1@dont-email.me> |
| In reply to | #147694 |
On 07/11/2019 02:13, Bart wrote: > On 07/11/2019 00:04, David Brown wrote: >> On 07/11/2019 00:22, Bart wrote: > >> Look, TCC is a limited toy. It doesn't do the job serious programmers >> need for development tools. It was never intended for that - it is >> made to be able to do compilations of finished, developed code even >> though you have a very limited host. > > So why was it made fast? It doesn't do much (in comparison to bigger compilers), so it can be small and fast. In particular, as far as I know it doesn't do any kind of inter-procedural analysis, which is something that takes a lot of time and resources in a compiler but is very important for both optimisation and static analysis. It does not handle multiple languages, multiple targets and multiple devices within a family - so it does not need the layers of abstraction in between stages. As I have said before, I think it is impressive how much TCC can do in such a small code space and run time. But it is not the tool to use for development. > > (And it was made as a test, a >> learning/teaching tool, and a demonstration of compact compiler design.) > > From the web: > > "TinyCC (aka TCC) is a small but hyper fast C compiler. Unlike other C > compilers, it is meant to be self-sufficient: you do not need an > external assembler or linker because TCC does that for you. > > TCC compiles so fast that even for big projects Makefiles may not be > necessary. That only applies if you don't know what Makefiles are for, and how project management works. Or if you only write "hello, world" programs. > > TCC not only supports ANSI C, but also most of the new ISO C99 standard > and many GNUC extensions. And there are lots of things it doesn't support. (Again, let me say that it is impressive how much it supports.) > > TCC can also be used to make C scripts, i.e. pieces of C source that you > run as a Perl or Python script. Compilation is so fast that your script > will be as fast as if it was an executable. Pointless. It is a fine gimmick. > > TCC can also automatically generate memory and bound checks while > allowing all C pointers operations. TCC can do these checks even if non > patched libraries are used. > > With libtcc, you can use TCC as a backend for dynamic code generation." That is a feature that might have some uses. > > My own product is much more limited (not full C99, targets only Win64, > various omissions and bugs), but has its own advantages, such as being > more self-contained then tcc (ie. a single file), making it ultra-simple > to run from anywhere, copy, download etc. > > Or send someone program source code, just add one extra file that is the > compiler. > >> You enjoy your toys - your home made ones, and favourite tiny little >> programs. Maybe they are okay for your hobby coding. I program >> professionally, so I use the best tools I can get for the job. Since >> these tools mostly happen to be zero cost, they are suitable for >> non-professionals too - but for only people who are actually >> interested in doing good development work. > > You just don't get it. You have a finished, working C application, but > you inadvertently use tcc to compile the binary for a customer rather > than gcc. Will they be able to tell the difference? > Whoosh! Did you hear that? It was the sound of my point flying /way/ over your head. We are talking about /software development/. It is a process - the art of making quality code that solves a specified problem. You use the best tools you can get to aid you in writing code that is clear, correct, maintainable, and efficient. You use tools that help you write /good/ code - not just something that happens to work in your first quick tests. Those tools include good editors, good debuggers, good source code management, good build systems, good documentation, good compilers, good linters, good review processes, etc. Once you have the good code written, you might be able to compile it with TCC if you want. That would be a handy feature if you think people will want to compile it on a Raspberry Pi 1. But you use gcc, clang, or other quality, feature-rich tools during development. Would anyone notice if the final binary is compiled with TCC rather than gcc ? That depends. Modern x86 cpus excel at running poor quality machine code at high speed, and often any excess instructions can be run while the cpu is waiting for external memory anyway. So for a lot of code, differences in optimisation make little difference to wall-clock run times. For more demanding code that requires higher speed and more calculations, yes the difference can be easily noticeable. (This is very different from embedded systems, where the optimisation in size and run-time is much more visible. But TCC doesn't support them anyway.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-07 11:51 +0000 |
| Message-ID | <izTwF.228690$LT2.137023@fx21.am4> |
| In reply to | #147702 |
On 07/11/2019 09:22, David Brown wrote:
> On 07/11/2019 02:13, Bart wrote:
>> So why was it made fast?
>
> It doesn't do much (in comparison to bigger compilers), so it can be
> small and fast. In particular, as far as I know it doesn't do any kind
> of inter-procedural analysis, which is something that takes a lot of
> time and resources in a compiler but is very important for both
> optimisation and static analysis. It does not handle multiple
> languages, multiple targets and multiple devices within a family - so it
> does not need the layers of abstraction in between stages.
So if using TCC to develop C programs for x86, x64, ARM and ARM64, it's
no good because it doesn't support 996 other processors, and it isn't
part of a product chain that can also compile C++, Ada and Fortran?
It sounds to me like, if that is how you can streamline a compiler, then
what's the problem?
> As I have said before, I think it is impressive how much TCC can do in
> such a small code space and run time.
(For 'impressive', look at LuaJIT, which is a 225KB executable that
appears to be a complete Lua implementation with a tracing JIT compiler.
C source is a nightmare though...)
> But it is not the tool to use for
> development.
Yes you keep saying that. But not everyone is you with your very
exacting requirements.
>> TCC compiles so fast that even for big projects Makefiles may not be
>> necessary.
>
> That only applies if you don't know what Makefiles are for, and how
> project management works. Or if you only write "hello, world" programs.
My projects aren't that big, but they're a long way from being hello,
world programs. Yet they don't need makefiles. The biggest one is built
like this:
C:\qcc>mm qq
Compiling qq.m to qq.exe
Which processes 56 files totalling 56,000 lines. 'mm.exe' is a bare
compiler. While, getting back to C, I can build Seed7 like this:
C:\seed79\src>bcc @s7
....
where s7 is simply a list of the modules that are needed. This will also
work with gcc and lcc (depending on whether compiler-specific options
are inside that @ file).
Makefiles are not the only fruit.
Some like to streamline and simplify, your propaganda which dismisses
such simplifications and promotes ever more complex and bigger tools
doesn't help that.
>> TCC can also be used to make C scripts, i.e. pieces of C source that you
>> run as a Perl or Python script. Compilation is so fast that your script
>> will be as fast as if it was an executable.
>
> Pointless. It is a fine gimmick.
It is a great gimmick. You want to encourage people to use C? Then make
it as effortless as running a script. With tcc's -run option, I couldn't
find out how to pass parameters to the compiled program, but I can do
the same thing in mine:
First, create a suitable one-file C program to make for a simple
example, like a C compiler:
C:\cx>mc -c cc
Compiling cc.m to cc.c
Now, compile and then run that C compiler, but as a bonus, tell it to
also run the program that it will compile:
C:\cx>bcc cc -run : hello -run
Compiling cc.c to cc.exe
Compiling hello.c to hello.exe
Hello World!
You have to admit this is impressive, and something rather difficult
with gcc. This took 0.33 seconds (tcc would be around 0.2 seconds), on a
machine that is 1/4 the speed of Ian Collins' (one he thinks is not fast).
Imagine that every time you wanted to run gcc, you had to build gcc from
scratch first.
>> With libtcc, you can use TCC as a backend for dynamic code generation."
>
> That is a feature that might have some uses.
Well I use tcc as a backend (for compiling my language on Linux via an
intermediate C target), but I just use tcc itself, not libtcc, ie. is
not integrated, but it runs as if integrated.
The default compiler that is invoked is gcc, but only because that is
always present, while tcc is optional. I will change it I think so that
it will check for tcc and run that in preference.
tcc is a good match for my compiler, because they are both very fast. If
using gcc, it's like hitting a brick wall as soon as it starts gcc, even
using -O0. Eg (mu.ma is a 25Kloc compiler in my language):
osboxes@osboxes:~$ time ./mu2 -tcc mu.ma
Compiling mu.m to mu
Invoking C compiler: tcc -omu mu.c -lm -ldl
real 0m0.241s
osboxes@osboxes:~$ time ./mu2 -gcc mu.ma
Compiling mu.m to mu
Invoking C compiler: gcc -omu mu.c -lm -ldl
real 0m3.126s
osboxes@osboxes:~$ time ./mu2 -opt -gcc mu.ma
Compiling mu.m to mu
Invoking C compiler: gcc -O3 -omu mu.c -lm -ldl
real 0m15.763s
With gcc it takes 12 times as long, but the program isn't any faster. To
make it worthwhile, you have to optimise it, and that takes 60 times as
long (-O2 might be a little quicker).
It's a no-brainer, isn't it?
> We are talking about /software development/. It is a process - the art
> of making quality code that solves a specified problem.
Yes, I know. I used to write software for paying customers.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-07 15:58 +0100 |
| Message-ID | <qq1bed$109$1@dont-email.me> |
| In reply to | #147706 |
On 07/11/2019 12:51, Bart wrote: > On 07/11/2019 09:22, David Brown wrote: >> On 07/11/2019 02:13, Bart wrote: > >>> So why was it made fast? >> >> It doesn't do much (in comparison to bigger compilers), so it can be >> small and fast. In particular, as far as I know it doesn't do any kind >> of inter-procedural analysis, which is something that takes a lot of >> time and resources in a compiler but is very important for both >> optimisation and static analysis. It does not handle multiple >> languages, multiple targets and multiple devices within a family - so it >> does not need the layers of abstraction in between stages. > > So if using TCC to develop C programs for x86, x64, ARM and ARM64, it's > no good because it doesn't support 996 other processors, and it isn't > part of a product chain that can also compile C++, Ada and Fortran? I said the limited features are one of the reasons tcc can be small and fast. > > It sounds to me like, if that is how you can streamline a compiler, then > what's the problem? > >> As I have said before, I think it is impressive how much TCC can do in >> such a small code space and run time. > > (For 'impressive', look at LuaJIT, which is a 225KB executable that > appears to be a complete Lua implementation with a tracing JIT compiler. > C source is a nightmare though...) > >> But it is not the tool to use for >> development. > > Yes you keep saying that. But not everyone is you with your very > exacting requirements. > >>> TCC compiles so fast that even for big projects Makefiles may not be >>> necessary. >> >> That only applies if you don't know what Makefiles are for, and how >> project management works. Or if you only write "hello, world" programs. > > My projects aren't that big, but they're a long way from being hello, > world programs. Yet they don't need makefiles. The biggest one is built > like this: > > C:\qcc>mm qq > Compiling qq.m to qq.exe > > Which processes 56 files totalling 56,000 lines. 'mm.exe' is a bare > compiler. While, getting back to C, I can build Seed7 like this: > > C:\seed79\src>bcc @s7 > .... > > where s7 is simply a list of the modules that are needed. This will also > work with gcc and lcc (depending on whether compiler-specific options > are inside that @ file). > > Makefiles are not the only fruit. We are talking about C, not your private language. Non-negligible projects need some kind of build process. Makefiles are one way to express these - there are other ways. The point is that "the compiler is so fast you don't need a Makefile" is a complete misunderstanding on the purpose of Makefiles - they are not just about the efficiency of incremental builds. If I want fast compilation for incremental builds, I can use ccache - it will tear through C files in a fraction of the time tcc takes, when re-compiling the same code (and the same options). I still need a Makefile, because build procedures are important. > > Some like to streamline and simplify, your propaganda which dismisses > such simplifications and promotes ever more complex and bigger tools > doesn't help that. > >>> TCC can also be used to make C scripts, i.e. pieces of C source that you >>> run as a Perl or Python script. Compilation is so fast that your script >>> will be as fast as if it was an executable. >> >> Pointless. It is a fine gimmick. > > It is a great gimmick. You want to encourage people to use C? No, I don't. I am happy that people use C where C is appropriate, but I think both programmers and their programs would be better off if C was used a lot less and by a lot fewer people. It is regularly used in cases where it is not the best language for the task, and regularly used by people who don't really understand it. C is an excellent language for some tasks, and it is a useful language for a lot of programmers to know - but it is not a language for beginners, and it is not a language to use unless it really is the right choice. > Then make > it as effortless as running a script. With tcc's -run option, I couldn't > find out how to pass parameters to the compiled program, but I can do > the same thing in mine: > > First, create a suitable one-file C program to make for a simple > example, like a C compiler: > > C:\cx>mc -c cc > Compiling cc.m to cc.c > > Now, compile and then run that C compiler, but as a bonus, tell it to > also run the program that it will compile: > > C:\cx>bcc cc -run : hello -run > Compiling cc.c to cc.exe > Compiling hello.c to hello.exe > Hello World! > > You have to admit this is impressive, and something rather difficult > with gcc. This took 0.33 seconds (tcc would be around 0.2 seconds), on a > machine that is 1/4 the speed of Ian Collins' (one he thinks is not fast). > Yes, it is impressive. I used to be able to juggle 5 balls - that's impressive too. Neither is a useful trick for programming work. > Imagine that every time you wanted to run gcc, you had to build gcc from > scratch first. > Imagine if you had to rebuild your car's engine every time you filled up with petrol. What is your point here, other than giving our imaginations a little exercise? > >>> With libtcc, you can use TCC as a backend for dynamic code generation." >> >> That is a feature that might have some uses. > > Well I use tcc as a backend (for compiling my language on Linux via an > intermediate C target), but I just use tcc itself, not libtcc, ie. is > not integrated, but it runs as if integrated. > > The default compiler that is invoked is gcc, but only because that is > always present, while tcc is optional. I will change it I think so that > it will check for tcc and run that in preference. > > tcc is a good match for my compiler, because they are both very fast. If > using gcc, it's like hitting a brick wall as soon as it starts gcc, even > using -O0. Eg (mu.ma is a 25Kloc compiler in my language): The requirements for a compiler handling generated code are very different from what you want from a compiler as a development tool.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-07 16:34 +0000 |
| Message-ID | <KIXwF.401247$7ei.266197@fx36.am4> |
| In reply to | #147713 |
On 07/11/2019 14:58, David Brown wrote: > On 07/11/2019 12:51, Bart wrote: >> Makefiles are not the only fruit. > > We are talking about C, not your private language. My second example was for C. > Non-negligible > projects need some kind of build process. Makefiles are one way to > express these - there are other ways. The point is that "the compiler > is so fast you don't need a Makefile" is a complete misunderstanding on > the purpose of Makefiles - they are not just about the efficiency of > incremental builds. > > If I want fast compilation for incremental builds, I can use ccache - it > will tear through C files in a fraction of the time tcc takes, when > re-compiling the same code (and the same options). I still need a > Makefile, because build procedures are important. I believe the point of that feature is that it is so fast, that you don't need to bother with makefiles which specify dependencies so that it can work out what needs compiling and what doesn't. And neither do you need a tool like 'ccache', which I understand gets its speed by avoiding doing any work as much as possible. With build-from-scratch times of a fraction of a second, depending on project size and machine speed, there's no point. > Yes, it is impressive. I used to be able to juggle 5 balls - that's > impressive too. Neither is a useful trick for programming work. In my work which is based around whole-project compilation, it /is/ useful. >> Imagine that every time you wanted to run gcc, you had to build gcc from >> scratch first. >> > > Imagine if you had to rebuild your car's engine every time you filled up > with petrol. What is your point here, other than giving our > imaginations a little exercise? That's pretty much what happens with every scripting language. Why are /they/ rebuilding their engines every time? >> tcc is a good match for my compiler, because they are both very fast. If >> using gcc, it's like hitting a brick wall as soon as it starts gcc, even >> using -O0. Eg (mu.ma is a 25Kloc compiler in my language): > > The requirements for a compiler handling generated code are very > different from what you want from a compiler as a development tool. You're getting close to acknowledging that small, fast compilers may possibly be of utility after all.
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2019-11-07 12:40 -0500 |
| Message-ID | <DGYwF.7482$aI.7291@fx44.iad> |
| In reply to | #147719 |
On 11/7/2019 11:34 AM, Bart wrote:
> On 07/11/2019 14:58, David Brown wrote:
> You're getting close to acknowledging that small, fast compilers may
> possibly be of utility after all.
Wanted to mention something. Until last night I was using tcc in Geany.
It was blazing fast as always. Click the Compile button and bam!
But I wanted to try gcc in Geany, so:
1. added <path>\MSYS2\usr\bin to Path
2. went to Geany | Build | Set Build commands and changed the Compile
setting from:
tcc -Wall -c "%f"
to
gcc -Wall -c "%f"
And found that if your code doesn't have the <Windows.h> include, it's
also very fast to compile with gcc from Geany.
Your compilations are probably more complicated than mine, but you might
try it, if you're gonna use Geany.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-07 17:57 +0000 |
| Message-ID | <YVYwF.401248$7ei.277876@fx36.am4> |
| In reply to | #147727 |
On 07/11/2019 17:40, DFS wrote: > On 11/7/2019 11:34 AM, Bart wrote: >> On 07/11/2019 14:58, David Brown wrote: > >> You're getting close to acknowledging that small, fast compilers may >> possibly be of utility after all. > > > Wanted to mention something. Until last night I was using tcc in Geany. > It was blazing fast as always. Click the Compile button and bam! > > But I wanted to try gcc in Geany, so: > > 1. added <path>\MSYS2\usr\bin to Path > > 2. went to Geany | Build | Set Build commands and changed the Compile > setting from: > > tcc -Wall -c "%f" > to > gcc -Wall -c "%f" > > > And found that if your code doesn't have the <Windows.h> include, Tcc's treatment is a bit of a cheat, as its windows.h file is one header of 26K lines, while gcc's windows.h file involves nearly 100 headers, hundreds of nested #includes, and 200K lines (all IIRC). it's > also very fast to compile with gcc from Geany. Did you try optimising? Ie. use -O1, -O2 or -O3 flags. > Your compilations are probably more complicated than mine, but you might > try it, if you're gonna use Geany. I can't remember the exact gcc compilation speeds, but it might be something over 10K lines per second unoptimised, and maybe 3-5K lines per second optimised. (Tiny C might be half a million. All timings apply to my PC.) So on small programs of a few hundred lines, the differences are not significant, except the overheads of gcc (start-up time etc) might be noticed. (On Windows I tend to use my own C compiler, which is perhaps half the speed of tcc, but generated code is a little better, so 59 seconds vs. tcc's 69 seconds for this test.)
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web