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 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-11-07 07:24 +1300 |
| Message-ID | <h2ghenFq967U8@mid.individual.net> |
| In reply to | #147671 |
On 07/11/2019 05:57, Malcolm McLean wrote: > On Wednesday, 6 November 2019 10:35:27 UTC, David Brown wrote: >> On 06/11/2019 10:59, Malcolm McLean wrote: >>> On Tuesday, 5 November 2019 23:55:07 UTC, Ian Collins wrote: >>>> On 06/11/2019 12:43, Bart wrote: >>>>> On 05/11/2019 23:31, Ian Collins wrote: >>>>>> >>>>>> 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. >>>> >>>> If a warning is truly irrelevant, disable it. Otherwise fix it. >>>> >>> During development, code is often in an intermediate stage. It's known >>> to be incomplete, or buggy, but we still want to compile and maybe >>> run it. So there might be things like unreachable code, or statements >>> with no effect, that the compiler warns about. That's one reason why >>> warnings are warnings rather than errors. However we often still want >>> the warning, we want to know where the code is being worked on and >>> contains temporary statements. >>> >> >> It is also a reason why developers should use good tools, and know how >> to use them. This all smacks of "a bad workman blames his tools". If >> you don't know how to avoid or deal with the issues you have invented >> here, then you should be asking for help, not making excuses. (If you >> want to ask here, I will happily give you suggestions.) >> > You avoid the issue by not using "treat warning as errors" for debug > builds, only for release candidate builds, after warnings have been > removed. In fact you don't even need the flag then, because you can > see that the build is clean and there are no warnings. > > Very simple process. As long as you admit that a compiler which distinguishes > between non-fatal "warnings" and fatal "errors" is a better tool than > a compiler that doesn't make such a distinction. We (as in my $day job team) always compile with warns as errors. If you don't introduce them, you don't have to go back and fix them "later". -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-06 22:59 +0100 |
| Message-ID | <qpvfov$i9t$1@dont-email.me> |
| In reply to | #147671 |
On 06/11/2019 17:57, Malcolm McLean wrote: > On Wednesday, 6 November 2019 10:35:27 UTC, David Brown wrote: >> On 06/11/2019 10:59, Malcolm McLean wrote: >>> On Tuesday, 5 November 2019 23:55:07 UTC, Ian Collins wrote: >>>> On 06/11/2019 12:43, Bart wrote: >>>>> On 05/11/2019 23:31, Ian Collins wrote: >>>>>> >>>>>> 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. >>>> >>>> If a warning is truly irrelevant, disable it. Otherwise fix it. >>>> >>> During development, code is often in an intermediate stage. It's known >>> to be incomplete, or buggy, but we still want to compile and maybe >>> run it. So there might be things like unreachable code, or statements >>> with no effect, that the compiler warns about. That's one reason why >>> warnings are warnings rather than errors. However we often still want >>> the warning, we want to know where the code is being worked on and >>> contains temporary statements. >>> >> >> It is also a reason why developers should use good tools, and know how >> to use them. This all smacks of "a bad workman blames his tools". If >> you don't know how to avoid or deal with the issues you have invented >> here, then you should be asking for help, not making excuses. (If you >> want to ask here, I will happily give you suggestions.) >> > You avoid the issue by not using "treat warning as errors" for debug > builds, only for release candidate builds, after warnings have been > removed. In fact you don't even need the flag then, because you can > see that the build is clean and there are no warnings. No. There are two ways to handle this. One is to build up code in workable testable steps - then you have "treat warnings as errors" on all the time. The other is to have "treat warnings as errors" off while you are doing major work at the start, and once you have a base established, you turn it on. "Debug" builds don't come into it. In fact, if you start having different options sets for "debug" and "release" builds, you are likely to risk failing to properly test your main builds. Sometimes it can be useful to temporarily add debug flags (such as sanitizers) while tracking down particular problems, or to limit optimisation in a part of the code so you can single-step in a debugger, but for the most part I dislike having this kind of debug/release distinction at all. Your builds, except possibly for very early stages of development, will be clean - or they won't build, because warnings are treated as errors. And you keep "treat warnings as errors" on so that you will not release known bad code when you later make a change to the program. > > Very simple process. As long as you admit that a compiler which distinguishes > between non-fatal "warnings" and fatal "errors" is a better tool than > a compiler that doesn't make such a distinction. > I often disagree with what is considered an error and what is considered a warning by compilers. I don't consider a program ready until it is of the quality I want - it is not ready for release if it has warnings, so they might as well be fatal errors. (The opposite is true also - if there is something the compiler can warn about but I don't think it is important enough to stop the build, I disable the warning.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-11-06 14:37 -0800 |
| Message-ID | <94ddb27b-a7a0-4819-a286-2ef90c2db656@googlegroups.com> |
| In reply to | #147681 |
On Wednesday, 6 November 2019 22:00:07 UTC, David Brown wrote: > > "Debug" builds don't come into it. In fact, if you start having > different options sets for "debug" and "release" builds, you are likely > to risk failing to properly test your main builds. Sometimes it can be > useful to temporarily add debug flags (such as sanitizers) while > tracking down particular problems, or to limit optimisation in a part of > the code so you can single-step in a debugger, but for the most part I > dislike having this kind of debug/release distinction at all. > On platforms such as the Mac and Windows, the compiler provides a "debug" and "release" configuration. You can toggle the two, it's a prominent feature of the IDE, not some obscure option hidden away somewhere. Now it is of course open to you to argue that this is a bad idea, and that you should always develop in "release" mode, except maybe for the initial code construction. But you're working in a different way that almost everyone else works, and not in the way recommended by Apple and Microsoft.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-07 00:58 +0100 |
| Message-ID | <qpvmnv$or2$1@dont-email.me> |
| In reply to | #147685 |
On 06/11/2019 23:37, Malcolm McLean wrote: > On Wednesday, 6 November 2019 22:00:07 UTC, David Brown wrote: >> >> "Debug" builds don't come into it. In fact, if you start having >> different options sets for "debug" and "release" builds, you are likely >> to risk failing to properly test your main builds. Sometimes it can be >> useful to temporarily add debug flags (such as sanitizers) while >> tracking down particular problems, or to limit optimisation in a part of >> the code so you can single-step in a debugger, but for the most part I >> dislike having this kind of debug/release distinction at all. >> > On platforms such as the Mac and Windows, the compiler provides a > "debug" and "release" configuration. You can toggle the two, it's a > prominent feature of the IDE, not some obscure option hidden away > somewhere. Really? "The compiler" ? Perhaps what you are trying to say is that the IDE's (/not/ compilers) MSVS on Windows and XCode on Mac make two configurations by default when you create a new project. Would that be more accurate? If you know what you are doing, you can remove the unwanted configuration, make new ones to suit your needs, change the details of the configurations, etc. You are not stuck with "release = optimise and no debug symbols", "debug = debug symbols and no optimise" default. > > Now it is of course open to you to argue that this is a bad idea, > and that you should always develop in "release" mode, except maybe > for the initial code construction. But you're working in a different > way that almost everyone else works, and not in the way recommended > by Apple and Microsoft. > What makes you think they recommend it? It's just a commonly used default that people are familiar with as a starting point, not something that is necessarily recommended. And I work in a different way from Apple and Microsoft. Amongst other things, I don't consider my users to be beta testers and bug-hunters.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-11-07 02:08 -0800 |
| Message-ID | <a93388f9-4463-4460-84f1-8974872a988a@googlegroups.com> |
| In reply to | #147689 |
On Wednesday, 6 November 2019 23:59:05 UTC, David Brown wrote: > On 06/11/2019 23:37, Malcolm McLean wrote: > > > On platforms such as the Mac and Windows, the compiler provides a > > "debug" and "release" configuration. You can toggle the two, it's a > > prominent feature of the IDE, not some obscure option hidden away > > somewhere. > > Really? "The compiler" ? > > Perhaps what you are trying to say is that the IDE's (/not/ compilers) > MSVS on Windows and XCode on Mac make two configurations by default when > you create a new project. Would that be more accurate? > That would be more accurate, yes. The compiler doesn't actually take a single flag to debug / release. > > If you know what you are doing, you can remove the unwanted > configuration, make new ones to suit your needs, change the details of > the configurations, etc. You are not stuck with "release = optimise and > no debug symbols", "debug = debug symbols and no optimise" default. > You might be able to add and remove configurations, but I've never tried to do it. You can set options for each configuration, and it may be possible to set the "debug" configuration so it is effectively "release" and vice versa. However you also have two sets of libraries to link against, debug and release. > > > > Now it is of course open to you to argue that this is a bad idea, > > and that you should always develop in "release" mode, except maybe > > for the initial code construction. But you're working in a different > > way that almost everyone else works, and not in the way recommended > > by Apple and Microsoft. > > > > What makes you think they recommend it? It's just a commonly used > default that people are familiar with as a starting point, not something > that is necessarily recommended. > You don't go to all the trouble of creating debug libraries, and then not recommend that people use them. > > And I work in a different way from Apple and Microsoft. Amongst other > things, I don't consider my users to be beta testers and bug-hunters. > Comments like that just indicate your lack of seriousness.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-07 15:43 +0100 |
| Message-ID | <qq1ajb$rg6$1@dont-email.me> |
| In reply to | #147703 |
On 07/11/2019 11:08, Malcolm McLean wrote: > On Wednesday, 6 November 2019 23:59:05 UTC, David Brown wrote: >> On 06/11/2019 23:37, Malcolm McLean wrote: >> >>> On platforms such as the Mac and Windows, the compiler provides a >>> "debug" and "release" configuration. You can toggle the two, it's a >>> prominent feature of the IDE, not some obscure option hidden away >>> somewhere. >> >> Really? "The compiler" ? >> >> Perhaps what you are trying to say is that the IDE's (/not/ compilers) >> MSVS on Windows and XCode on Mac make two configurations by default when >> you create a new project. Would that be more accurate? >> > That would be more accurate, yes. The compiler doesn't actually take a > single flag to debug / release. Good - then we are on the same page. >> >> If you know what you are doing, you can remove the unwanted >> configuration, make new ones to suit your needs, change the details of >> the configurations, etc. You are not stuck with "release = optimise and >> no debug symbols", "debug = debug symbols and no optimise" default. >> > You might be able to add and remove configurations, but I've never tried to > do it. You can set options for each configuration, and it may be possible > to set the "debug" configuration so it is effectively "release" and > vice versa. However you also have two sets of libraries to link against, > debug and release. I haven't used MSVS much, but I am confident that you can configure and change all this. The IDE would be useless without such possibilities. >>> >>> Now it is of course open to you to argue that this is a bad idea, >>> and that you should always develop in "release" mode, except maybe >>> for the initial code construction. But you're working in a different >>> way that almost everyone else works, and not in the way recommended >>> by Apple and Microsoft. >>> >> >> What makes you think they recommend it? It's just a commonly used >> default that people are familiar with as a starting point, not something >> that is necessarily recommended. >> > You don't go to all the trouble of creating debug libraries, and then > not recommend that people use them. You make them available for the few occasions when they are useful - which is not many (unless it is likely that there are bugs in the libraries). Car manufacturers provide airbags - but they don't recommend you use them. They prefer people to drive in such a way that they never need to use the airbag. >> >> And I work in a different way from Apple and Microsoft. Amongst other >> things, I don't consider my users to be beta testers and bug-hunters. >> > Comments like that just indicate your lack of seriousness. > In any software development, you have a balance between features, time to market, and development costs. In my line of work, we have a very different balance of priorities than typical desktop software. If I make software that is supposed to be buried in concrete at the bottom of the sea and work for 10 to 20 years (and I have), it takes a different development attitude than writing software that is to be released for the Christmas market, ready or not, with bugs to be fixed by updates and hotfixes. (This is not actually a condemnation of the way the Apples and Microsofts of the world work - if desktop developers held themselves to the standards that serious embedded developers do, we'd probably still be using DOS.)
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2019-11-07 16:15 -0600 |
| Message-ID | <pp59se5fv0s0lmehdss1ld0d0una7tf4h5@4ax.com> |
| In reply to | #147712 |
On Thu, 7 Nov 2019 15:43:55 +0100, David Brown <david.brown@hesbynett.no> wrote: >On 07/11/2019 11:08, Malcolm McLean wrote: >> On Wednesday, 6 November 2019 23:59:05 UTC, David Brown wrote: >>> On 06/11/2019 23:37, Malcolm McLean wrote: >>> >>>> On platforms such as the Mac and Windows, the compiler provides a >>>> "debug" and "release" configuration. You can toggle the two, it's a >>>> prominent feature of the IDE, not some obscure option hidden away >>>> somewhere. >>> >>> Really? "The compiler" ? >>> >>> Perhaps what you are trying to say is that the IDE's (/not/ compilers) >>> MSVS on Windows and XCode on Mac make two configurations by default when >>> you create a new project. Would that be more accurate? >>> >> That would be more accurate, yes. The compiler doesn't actually take a >> single flag to debug / release. > >Good - then we are on the same page. > >>> >>> If you know what you are doing, you can remove the unwanted >>> configuration, make new ones to suit your needs, change the details of >>> the configurations, etc. You are not stuck with "release = optimise and >>> no debug symbols", "debug = debug symbols and no optimise" default. >>> >> You might be able to add and remove configurations, but I've never tried to >> do it. You can set options for each configuration, and it may be possible >> to set the "debug" configuration so it is effectively "release" and >> vice versa. However you also have two sets of libraries to link against, >> debug and release. > >I haven't used MSVS much, but I am confident that you can configure and >change all this. The IDE would be useless without such possibilities. It's pretty trivial: under Build / Configuration Manager, pick "new".
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-11-10 20:01 +0000 |
| Message-ID | <slrnqsgr4m.cdo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #147685 |
On Wed, 2019-11-06, Malcolm McLean wrote: > On Wednesday, 6 November 2019 22:00:07 UTC, David Brown wrote: >> >> "Debug" builds don't come into it. In fact, if you start having >> different options sets for "debug" and "release" builds, you are likely >> to risk failing to properly test your main builds. Sometimes it can be >> useful to temporarily add debug flags (such as sanitizers) while >> tracking down particular problems, or to limit optimisation in a part of >> the code so you can single-step in a debugger, but for the most part I >> dislike having this kind of debug/release distinction at all. >> > On platforms such as the Mac and Windows, the compiler provides a > "debug" and "release" configuration. You can toggle the two, it's a > prominent feature of the IDE, not some obscure option hidden away > somewhere. > > Now it is of course open to you to argue that this is a bad idea, > and that you should always develop in "release" mode, except maybe > for the initial code construction. But you're working in a different > way that almost everyone else works, and not in the way recommended > by Apple and Microsoft. It's a common way of working in the Unix and embedded world -- It's not just David Brown. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-11-11 15:26 +1300 |
| Message-ID | <h2rv6rF4cl5U9@mid.individual.net> |
| In reply to | #147924 |
On 11/11/2019 09:01, Jorgen Grahn wrote: > On Wed, 2019-11-06, Malcolm McLean wrote: >> On Wednesday, 6 November 2019 22:00:07 UTC, David Brown wrote: >>> >>> "Debug" builds don't come into it. In fact, if you start having >>> different options sets for "debug" and "release" builds, you are likely >>> to risk failing to properly test your main builds. Sometimes it can be >>> useful to temporarily add debug flags (such as sanitizers) while >>> tracking down particular problems, or to limit optimisation in a part of >>> the code so you can single-step in a debugger, but for the most part I >>> dislike having this kind of debug/release distinction at all. >>> >> On platforms such as the Mac and Windows, the compiler provides a >> "debug" and "release" configuration. You can toggle the two, it's a >> prominent feature of the IDE, not some obscure option hidden away >> somewhere. >> >> Now it is of course open to you to argue that this is a bad idea, >> and that you should always develop in "release" mode, except maybe >> for the initial code construction. But you're working in a different >> way that almost everyone else works, and not in the way recommended >> by Apple and Microsoft. > > It's a common way of working in the Unix and embedded world -- > It's not just David Brown. It is that. In addition, there's nothing to stop you using the same compiler options, excluding optimisation settings, in both debug and release configurations. All things considered, you probably should to avoid surprises when swapping between one and the other. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-11 12:37 +0100 |
| Message-ID | <qqbh55$n9m$1@dont-email.me> |
| In reply to | #147933 |
On 11/11/2019 03:26, Ian Collins wrote: > On 11/11/2019 09:01, Jorgen Grahn wrote: >> On Wed, 2019-11-06, Malcolm McLean wrote: >>> On Wednesday, 6 November 2019 22:00:07 UTC, David Brown wrote: >>>> >>>> "Debug" builds don't come into it. In fact, if you start having >>>> different options sets for "debug" and "release" builds, you are likely >>>> to risk failing to properly test your main builds. Sometimes it can be >>>> useful to temporarily add debug flags (such as sanitizers) while >>>> tracking down particular problems, or to limit optimisation in a >>>> part of >>>> the code so you can single-step in a debugger, but for the most part I >>>> dislike having this kind of debug/release distinction at all. >>>> >>> On platforms such as the Mac and Windows, the compiler provides a >>> "debug" and "release" configuration. You can toggle the two, it's a >>> prominent feature of the IDE, not some obscure option hidden away >>> somewhere. >>> >>> Now it is of course open to you to argue that this is a bad idea, >>> and that you should always develop in "release" mode, except maybe >>> for the initial code construction. But you're working in a different >>> way that almost everyone else works, and not in the way recommended >>> by Apple and Microsoft. >> >> It's a common way of working in the Unix and embedded world -- >> It's not just David Brown. > > It is that. In addition, there's nothing to stop you using the same > compiler options, excluding optimisation settings, in both debug and > release configurations. All things considered, you probably should to > avoid surprises when swapping between one and the other. > I see two main points here. One is that debugging is typically /easier/ with some optimisation, but not too much. Compilers do more analysis with optimisations enabled, and thus give better warnings to catch problems earlier. And if you are doing low-level debugging (breakpoints, single-stepping, analysis of assembly code, etc.) then it is much simpler with a bit of optimisation as you avoid massive amounts of stack operations for local variables. But you want to avoid the optimisations that re-arrange code too much, as that makes it harder to follow. For gcc, I use -O1 as the lowest optimisation level, though most of the time -O2 code is okay for debugging. Secondly, there is the principle "test what you will ship, ship what you have tested". Debugging is not testing, but it is part of the same process - and as Ian says, you avoid surprises by not changing flags (or not changing them much). But there is no "right" answer - I can only say what works for me, and the kind of code I write, and the kind of debugging I do. And this will also vary at different stages during the development of a project. But I /can/ say that a "debug configuration with debugging symbols and no optimisation" and a "release configuration with full optimisation and no debugging symbols" is always the wrong answer for me.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-11-07 07:21 +1300 |
| Message-ID | <h2gh9hFq967U7@mid.individual.net> |
| In reply to | #147658 |
On 06/11/2019 22:59, Malcolm McLean wrote: > On Tuesday, 5 November 2019 23:55:07 UTC, Ian Collins wrote: >> On 06/11/2019 12:43, Bart wrote: >>> On 05/11/2019 23:31, Ian Collins wrote: >>>> >>>> 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. >> >> If a warning is truly irrelevant, disable it. Otherwise fix it. >> > During development, code is often in an intermediate stage. It's known > to be incomplete, or buggy, but we still want to compile and maybe > run it. So there might be things like unreachable code, or statements > with no effect, that the compiler warns about. That's one reason why > warnings are warnings rather than errors. However we often still want > the warning, we want to know where the code is being worked on and > contains temporary statements. That depends how you develop your code. If you are using test driven development, code is only written to pass tests so there won't be things like unreachable code, or statements with no effect. As I said, very compile is a "make test". -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-11-06 10:39 -0800 |
| Message-ID | <ce5a93ef-6290-4cbb-8903-84e8d32fb8c3@googlegroups.com> |
| In reply to | #147674 |
On Wednesday, 6 November 2019 18:21:49 UTC, Ian Collins wrote: > On 06/11/2019 22:59, Malcolm McLean wrote: > > On Tuesday, 5 November 2019 23:55:07 UTC, Ian Collins wrote: > >> On 06/11/2019 12:43, Bart wrote: > >>> On 05/11/2019 23:31, Ian Collins wrote: > >>>> > >>>> 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. > >> > >> If a warning is truly irrelevant, disable it. Otherwise fix it. > >> > > During development, code is often in an intermediate stage. It's known > > to be incomplete, or buggy, but we still want to compile and maybe > > run it. So there might be things like unreachable code, or statements > > with no effect, that the compiler warns about. That's one reason why > > warnings are warnings rather than errors. However we often still want > > the warning, we want to know where the code is being worked on and > > contains temporary statements. > > That depends how you develop your code. If you are using test driven > development, code is only written to pass tests so there won't be things > like unreachable code, or statements with no effect. As I said, very > compile is a "make test". > Test-driven development isn't feasible for us.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-11-07 07:47 +1300 |
| Message-ID | <h2gipoFq967U9@mid.individual.net> |
| In reply to | #147676 |
On 07/11/2019 07:39, Malcolm McLean wrote: > On Wednesday, 6 November 2019 18:21:49 UTC, Ian Collins wrote: >> On 06/11/2019 22:59, Malcolm McLean wrote: >>> On Tuesday, 5 November 2019 23:55:07 UTC, Ian Collins wrote: >>>> On 06/11/2019 12:43, Bart wrote: >>>>> On 05/11/2019 23:31, Ian Collins wrote: >>>>>> >>>>>> 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. >>>> >>>> If a warning is truly irrelevant, disable it. Otherwise fix it. >>>> >>> During development, code is often in an intermediate stage. It's known >>> to be incomplete, or buggy, but we still want to compile and maybe >>> run it. So there might be things like unreachable code, or statements >>> with no effect, that the compiler warns about. That's one reason why >>> warnings are warnings rather than errors. However we often still want >>> the warning, we want to know where the code is being worked on and >>> contains temporary statements. >> >> That depends how you develop your code. If you are using test driven >> development, code is only written to pass tests so there won't be things >> like unreachable code, or statements with no effect. As I said, very >> compile is a "make test". >> > Test-driven development isn't feasible for us. It's feasible for anyone! -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-11-07 08:14 +1300 |
| Message-ID | <h2gkdiFq967U10@mid.individual.net> |
| In reply to | #147676 |
On 07/11/2019 07:39, Malcolm McLean wrote: > Test-driven development isn't feasible for us. > What makes it unfeasible for you? -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-11-06 12:30 -0800 |
| Message-ID | <b76dec61-9f95-4ced-85f5-fcd8525e636a@googlegroups.com> |
| In reply to | #147678 |
On Wednesday, 6 November 2019 19:15:09 UTC, Ian Collins wrote: > On 07/11/2019 07:39, Malcolm McLean wrote: > > > Test-driven development isn't feasible for us. > > > > What makes it unfeasible for you? > > -- > Ian. Firstly we have a plugin architecture. So the programs can't run without the main application. Secondly the routines are geometrical in nature. Often the specification is "visually acceptable results". Also, whilst low level routines often have relatively simple test cases, and could be developed under a test-driven development regime if we chose to do so, those aren't the routines which limit development. The more complex routines are liable to fail on complex geometry, with degeneracies in it, often subtle ones which the programmer overlooks during initial development, and that's difficult to enter into test code. Then to calculate the expected result is often only feasible by re-coding the routine under test and putting that # into the test routine. Which isn't a sensible way of proceeding. However results are usually easy to check visually. So what we do is write interactive test tools, then try to break the routines, initially in informal test by the programmer, later in more formal tests by testers.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-11-08 21:04 -0800 |
| Message-ID | <867e49ej2w.fsf@linuxsc.com> |
| In reply to | #147678 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-09 01:37 -0800 |
| Message-ID | <qq61df$1to3$1@gioia.aioe.org> |
| In reply to | #147812 |
On 11/8/2019 9:04 PM, 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 have seen people eat raw kool-aid powder mixed with extra sugar! Wow. I can almost hear the enamel being destroyed wrt the critic acid...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-09 01:38 -0800 |
| Message-ID | <qq61f2$1to3$2@gioia.aioe.org> |
| In reply to | #147820 |
On 11/9/2019 1:37 AM, Chris M. Thomasson wrote: > On 11/8/2019 9:04 PM, 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 have seen people eat raw kool-aid powder mixed with extra sugar! Wow. > I can almost hear the enamel being destroyed wrt the critic acid... citric acid... ;^)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-11-10 08:32 +1300 |
| Message-ID | <h2oiifF4cl5U1@mid.individual.net> |
| In reply to | #147812 |
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. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-11-28 16:09 -0800 |
| Message-ID | <86mucf8rvs.fsf@linuxsc.com> |
| In reply to | #147843 |
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.
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web