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

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

Best C compiler

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

Contents

  Best C compiler "Usenet Advocate #1337" <test@dont-email.me> - 2020-03-03 22:38 -0500
    Re: Best C compiler Melzzzzz <Melzzzzz@zzzzz.com> - 2020-03-04 04:36 +0000
    Re: Best C compiler Autist <autist69@gmail.com> - 2020-03-04 07:16 +0100
      Re: Best C compiler "Usenet Advocate #1337" <test@dont-email.me> - 2020-03-04 18:48 -0500
        Re: Best C compiler Autist <autist69@gmail.com> - 2020-03-05 06:14 +0100
    Re: Best C compiler already5chosen@yahoo.com - 2020-03-04 01:05 -0800
    Re: Best C compiler Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-04 11:04 +0000
      Re: Best C compiler Real Troll <Real.Troll@Trolls.com> - 2020-03-04 07:25 -0400
        Re: Best C compiler Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-04 11:35 +0000
        Re: Best C compiler gazelle@shell.xmission.com (Kenny McCormack) - 2020-03-04 13:10 +0000
          Re: Best C compiler chad <cdalten@gmail.com> - 2020-03-04 06:12 -0800
        Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-04 10:00 -0800
          Re: Best C compiler Real Troll <real.troll@trolls.com> - 2020-03-04 22:59 -0400
      Re: Best C compiler gazelle@shell.xmission.com (Kenny McCormack) - 2020-03-04 13:07 +0000
    Re: Best C compiler fir <profesor.fir@gmail.com> - 2020-03-04 06:26 -0800
      Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-04 18:08 +0100
        Re: Best C compiler chad <cdalten@gmail.com> - 2020-03-04 09:26 -0800
          Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-04 18:31 +0100
            Re: Best C compiler scott@slp53.sl.home (Scott Lurndal) - 2020-03-04 22:31 +0000
              Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-05 06:44 +0100
                Re: Best C compiler Real Troll <real.troll@trolls.com> - 2020-03-05 03:20 -0400
                  Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-05 08:22 +0100
                Re: Best C compiler scott@slp53.sl.home (Scott Lurndal) - 2020-03-05 16:30 +0000
                  Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-05 17:40 +0100
                    Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-05 08:55 -0800
                      Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-05 18:47 +0100
                        Re: Best C compiler chad <cdalten@gmail.com> - 2020-03-05 10:06 -0800
                          Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-05 20:12 +0100
                            Re: Best C compiler chad <cdalten@gmail.com> - 2020-03-05 11:53 -0800
                        Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-06 01:56 -0800
                          Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-06 14:41 +0100
                            Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-06 05:48 -0800
                              Re: Best C compiler chad <cdalten@gmail.com> - 2020-03-06 06:23 -0800
                                Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-06 07:01 -0800
                                  Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-06 16:09 +0100
                                    Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-06 09:52 -0800
                                      Re: Best C compiler Guillaume <message@bottle.org> - 2020-03-06 19:11 +0100
                                        Re: Best C compiler Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-08 09:10 +0000
                                          Re: Best C compiler Guillaume <message@bottle.org> - 2020-03-08 16:08 +0100
                                            Re: Best C compiler Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-08 18:21 +0000
                                              Re: Best C compiler Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-03-08 14:57 -0400
                                                Re: Best C compiler Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-08 19:32 +0000
                                                  Re: Best C compiler Christopher Collins <ccollins476ad@gmail.com> - 2020-03-09 12:44 -0700
                                                    Re: Best C compiler Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-10 07:22 +0000
                                          Re: Best C compiler "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-03-08 14:34 -0700
                                            tsan (was Re: Best C compiler) Vir Campestris <vir.campestris@invalid.invalid> - 2020-03-11 21:55 +0000
                                              Re: tsan (was Re: Best C compiler) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-03-11 15:21 -0700
                              Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-06 15:27 +0100
                          Re: Best C compiler Richard Damon <Richard@Damon-Family.org> - 2020-03-07 12:15 -0500
                            Re: Best C compiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-07 17:50 +0000
                              Re: Best C compiler Richard Damon <Richard@Damon-Family.org> - 2020-03-07 13:00 -0500
                              Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-08 06:16 -0700
                                Re: Best C compiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-08 13:39 +0000
                                  Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-10 13:44 -0700
                                    Re: Best C compiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-11 03:34 +0000
                                      Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-11 03:27 -0700
                                        Re: Best C compiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-11 15:28 +0000
                                          Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-12 02:51 -0700
                                            Re: Best C compiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-12 11:58 +0000
                                              Re: Best C compiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-27 07:01 -0700
                                        Re: Best C compiler Bart <bc@freeuk.com> - 2020-03-11 16:08 +0000
                            Re: Best C compiler Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-08 09:17 +0000
                    Re: Best C compiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-05 23:32 +0000
                      Re: Best C compiler David Brown <david.brown@hesbynett.no> - 2020-03-06 12:37 +0100
        Re: Best C compiler fir <profesor.fir@gmail.com> - 2020-03-04 14:52 -0800
    Re: Best C compiler jacobnavia <jacob@jacob.remcomp.fr> - 2020-03-04 22:09 +0100
    Re: Best C compiler Philipp Klaus Krause <pkk@spth.de> - 2020-03-05 08:48 +0100
      Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-05 12:29 +0100
        Re: Best C compiler David Brown <david.brown@hesbynett.no> - 2020-03-05 12:41 +0100
    Re: Best C compiler "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-03-06 12:11 -0800

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

#150404

On 05/03/2020 05:44, Bonita Montero wrote:
>>> Of cours it's not an ide.
>>> But I'm asking which IDE he uses on top of mingw.
>
>> Why would you assume that any IDE is used?
>
> It's likely because developing without an IDE is a
> pain when you are not writing very small programs.
>

How do you know he is not writing a "very small program".  He asked for 
the "Best C compiler", so this should tell  to everybody that he is just 
starting and his first program is likely to be "Hell World!".  You can't 
say that this program is NOT "very small".

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

#150405

> How do you know he is not writing a "very small program".  He asked for
> the "Best C compiler", so this should tell  to everybody that he is just
> starting and his first program is likely to be "Hell World!".  You can't
> say that this program is NOT "very small".

We're talking about fir, not the OP.

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

#150411

Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Of cours it's not an ide.
>>> But I'm asking which IDE he uses on top of mingw.
>
>> Why would you assume that any IDE is used?
>
>It's likely because developing without an IDE is a
>pain when you are not writing very small programs.
>

While it may be painful for _you_, you don't speak
for anyone else.

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

#150412

>> It's likely because developing without an IDE is a
>> pain when you are not writing very small programs.

> While it may be painful for _you_, you don't speak
> for anyone else.

Debugging with a command-line debugger is painful if you already had
the comfort of a real debugger - for everyone ! And some programmers
use printf-debugging; that's even more horrible.

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

#150413

On Thursday, 5 March 2020 16:40:35 UTC, Bonita Montero  wrote:
> >> It's likely because developing without an IDE is a
> >> pain when you are not writing very small programs.
> 
> > While it may be painful for _you_, you don't speak
> > for anyone else.
> 
> Debugging with a command-line debugger is painful if you already had
> the comfort of a real debugger - for everyone ! And some programmers
> use printf-debugging; that's even more horrible.
>
Depends on the code. Debuggers are useful if the error occurs on the
first few iterations of the code. However if it takes many iterations
before the bug becomes evident, a printf trace of the program's state
can be more useful. You then scroll up it to detect the point at which
the values start to become unexpected.

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

#150414

> Depends on the code. Debuggers are useful if the error occurs on the
> first few iterations of the code.

Do you know conditional breakpoints ?

> However if it takes many iterations before the bug becomes evident,
> a printf trace of the program's state can be more useful.

Yeeees, a printf every iteration for a lot iterations.
Makes _perfectly_ sense to me.
printf()-debugging is a shit.

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

#150415

Some IDE don't make use of printf() in the debugger. Presumably because this call could block if the data is fully buffered.

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

#150416

> Some IDE don't make use of printf() in the debugger.

No one said this here. What we were talking about was using
printf() as a replacement for debug-views.

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

#150418

On Thursday, March 5, 2020 at 11:12:28 AM UTC-8, Bonita Montero wrote:
> > Some IDE don't make use of printf() in the debugger.
> 
> No one said this here. What we were talking about was using
> printf() as a replacement for debug-views.

Pull my finger.

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

#150420

On Thursday, 5 March 2020 17:48:08 UTC, Bonita Montero  wrote:
> > Depends on the code. Debuggers are useful if the error occurs on the
> > first few iterations of the code.
> 
> Do you know conditional breakpoints ?
> 
> > However if it takes many iterations before the bug becomes evident,
> > a printf trace of the program's state can be more useful.
> 
> Yeeees, a printf every iteration for a lot iterations.
> Makes _perfectly_ sense to me.
> printf()-debugging is a shit.
>
Say that we have the line
y = 1/x;

x goes to zero and it crashes. Now we could break on x == 0, but that won't tell us what happened to x before it went to zero. Or we could break on fabs(x) < epsilon, but what do we use for epsilon, how do we set up the condition in the debugger, and will it give us false positives?

if we put in the line
printf("x = %e\n", x);

then we get a list of all values of x before x goes to zero. There might be 
ten thousand of them. But likely things start to go wrong in the last hundred 
or so. We might see x gradually decrease in absolute value, wildly oscillate, or get into a pattern of alternating positive and negative values which steadily get lower. Or it might not be that all values until the last one look fine,
but we have a few isolated very low values further up in the trace.
The printf() method allows us to quickly monitor the state of the variable.

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

#150422

> x goes to zero and it crashes. Now we could break on x == 0, but that won't tell us what happened to x before it went to zero. Or we could break on fabs(x) < epsilon, but what do we use for epsilon, how do we set up the condition in the debugger, and will it give us false positives?

Then we restart the code and make a breakpoint where x is set.

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

#150423

On Friday, 6 March 2020 13:41:20 UTC, Bonita Montero  wrote:
> > x goes to zero and it crashes. Now we could break on x == 0, but that won't tell us what happened to x before it went to zero. Or we could break on fabs(x) < epsilon, but what do we use for epsilon, how do we set up the condition in the debugger, and will it give us false positives?
> 
> Then we restart the code and make a breakpoint where x is set.
> 
x is set ten thousand times before it goes to zero.

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

#150424

On Friday, March 6, 2020 at 5:48:57 AM UTC-8, Malcolm McLean wrote:
> On Friday, 6 March 2020 13:41:20 UTC, Bonita Montero  wrote:
> > > x goes to zero and it crashes. Now we could break on x == 0, but that won't tell us what happened to x before it went to zero. Or we could break on fabs(x) < epsilon, but what do we use for epsilon, how do we set up the condition in the debugger, and will it give us false positives?
> > 
> > Then we restart the code and make a breakpoint where x is set.
> > 
> x is set ten thousand times before it goes to zero.

If x is set ten thousand times before it goes to zero, then obviously you need to refactor your code.

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

#150426

On Friday, 6 March 2020 14:23:21 UTC, chad  wrote:
> On Friday, March 6, 2020 at 5:48:57 AM UTC-8, Malcolm McLean wrote:
> > On Friday, 6 March 2020 13:41:20 UTC, Bonita Montero  wrote:
> > > > x goes to zero and it crashes. Now we could break on x == 0, but that won't tell us what happened to x before it went to zero. Or we could break on fabs(x) < epsilon, but what do we use for epsilon, how do we set up the condition in the debugger, and will it give us false positives?
> > > 
> > > Then we restart the code and make a breakpoint where x is set.
> > > 
> > x is set ten thousand times before it goes to zero.
> 
> If x is set ten thousand times before it goes to zero, then obviously you 
> need to refactor your code.
>
No, of course not. It's unlikely that you need to refine x ten thousand
times. But you could easily set it ten thousand times before it goes wrong.
Each refinement might be for twenty or so iterations.

Now what you could do is try to identify the call on which it went wrong,
and repeat that in isolation. But that can be difficult to do. It's often
easier to simply repeat the entire run on which it went wrong, dump
a trace on each call, and ignore the early traces, except maybe for 
comparison purposes between good and bad calls.

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

#150427

> No, of course not. It's unlikely that you need to refine x ten thousand
> times. But you could easily set it ten thousand times before it goes wrong.

There might be ten thousand iterations before x goes to zero, but not
ten thousand places where it might go to zero. Usually there is only
one, sometimes a few places. So you set one or more conditional break-
points and avoid any logging mess. That's much more convenient.

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

#150428

On Friday, 6 March 2020 15:09:18 UTC, Bonita Montero  wrote:
> > No, of course not. It's unlikely that you need to refine x ten thousand
> > times. But you could easily set it ten thousand times before it goes wrong.
> 
> There might be ten thousand iterations before x goes to zero, but not
> ten thousand places where it might go to zero. Usually there is only
> one, sometimes a few places. So you set one or more conditional break-
> points and avoid any logging mess. That's much more convenient.
>
You can break when x goes to zero, but you then lose the information about 
the previous values. Which is often important. 

I've give you a real example. I had a test for a Bezier curve forming a
cusp which returned a false positive. Mathematically it is cusp when
a value based on the curve parameters goes to zero. I was returning
a cusp when the absolute value went below an epsilon. Simply by 
inserting a printf statement and running it on some geometry, I was 
able to check the values, and virtually all of them were tiny, but
above the epsilon. The bad one was below the epsilon.

You could of course break in a debugger, check,and restart. But it's
much easier to simply scan a list of values for various curves.

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

#150429

Le 06/03/2020 à 18:52, Malcolm McLean a écrit :
> You can break when x goes to zero, but you then lose the information about
> the previous values. Which is often important.
> (...)

Logging and otherwise instrumenting code are invaluable tools and 
debuggers are no replacement for that in many cases in which not just a 
specific condition, but the whole succession of events leading to it is 
important to understand what happens. Which is usually completely 
unpractical to do with debuggers alone.

Ironically, some people that get paid by the hour may actually not mind 
frantically hitting "next" while watching a few variables for hundreds 
of iterations. I guess some could even find that relaxing. Mwahaha. The 
same goes with code reuse, that some developers seem not to care about 
and will prefer rewriting everything from scratch at every opportunity. 
Those will change their habits if they ever become self-employed. ;)

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

#150436

On Fri, 2020-03-06, Guillaume wrote:
> Le 06/03/2020 à 18:52, Malcolm McLean a écrit :
>> You can break when x goes to zero, but you then lose the information about
>> the previous values. Which is often important.
>> (...)
>
> Logging and otherwise instrumenting code are invaluable tools and 
> debuggers are no replacement for that in many cases in which not just a 
> specific condition, but the whole succession of events leading to it is 
> important to understand what happens. Which is usually completely 
> unpractical to do with debuggers alone.

Even though I don't do stepwise debugging a lot myself, one feature
worth mentioning is stopping and then going backwards through the
states.  That can help you find the earlier point where things started
going wrong.

There's support for this in gdb nowadays.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#150440

Le 08/03/2020 à 10:10, Jorgen Grahn a écrit :
> Even though I don't do stepwise debugging a lot myself, one feature
> worth mentioning is stopping and then going backwards through the
> states.  That can help you find the earlier point where things started
> going wrong.
> 
> There's support for this in gdb nowadays.

That's interesting. I don't do stepwise debugging a lot either, but when 
I do, I occasionally use gdb - and I didn't know it supported this. I'll 
certainly have a look (although again it wouldn't beat a complete log - 
much easier to read and handle than having to step 'backwards', 
especially if you need to have a view over a relatively long sequence of 
events - but this functionality can still be handy to have.)

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

#150441

On Sun, 2020-03-08, Guillaume wrote:
> Le 08/03/2020 à 10:10, Jorgen Grahn a écrit :
>> Even though I don't do stepwise debugging a lot myself, one feature
>> worth mentioning is stopping and then going backwards through the
>> states.  That can help you find the earlier point where things started
>> going wrong.
>> 
>> There's support for this in gdb nowadays.
>
> That's interesting. I don't do stepwise debugging a lot either, but when 
> I do, I occasionally use gdb - and I didn't know it supported this.

https://www.gnu.org/software/gdb/news/reversible.html

There may be other choices too.  I remember being shown a separate
tool for Linux for this, but I cannot remember its name (it was
something brief and generic like 're').

> I'll 
> certainly have a look (although again it wouldn't beat a complete log - 
> much easier to read and handle than having to step 'backwards', 
> especially if you need to have a view over a relatively long sequence of 
> events - but this functionality can still be handy to have.)

That's what I have against stepwise debugging, too: I get lost in the
tree of choices.  Quite different from using the debugger to look at a
single state, e.g. in a core dump or at a breakpoint.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

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

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

csiph-web