good easy to use Free C compiler!!

[Beej Jorgensen]

I mean the ability to continue the exection at any line in the
current function. Apparently you have never used that feature of
gdb. No wonder you do not miss it in ddd.

Or perhaps he doesn't miss it in DDD because he can right-click on a
source line then select "Set Execution Position".

DDD might not be the best debugging front-end, but at least give it a
fair shake.

-Beej

 

[jacob navia]

Beej Jorgensen a écrit :

Or perhaps he doesn't miss it in DDD because he can right-click on a
source line then select "Set Execution Position".

DDD might not be the best debugging front-end, but at least give it a
fair shake.

-Beej

WOW!!

THANKS!

I am using ddd precisely in the Macintosh (OS X) to debug a huge
C++ program and I didn't know the right click trick...

I retire this point against ddd of course. It does it in a very good
way. Besides executing the jump in gdb, I had to set a breakpoint
at that line so that I could go step by step later. ddd does it for me now
and allows to avoid all the manual stuff.

Thanks again. (And thanks to the "ddd" developers)

 

[blmblm]

On Jan 20, 1:01 pm, jacob navia <[email protected]> wrote:

[ snip ]

Granted I don't use vim either [I use gedit mostly since I like using
my mouse for more than picking which window to work in],

Just for the record, with apologies for the off-topicness ....:

The versions of vim I've used in recent years do have some support
for mouse use, to select text and paste anyway, in the environments
I think most people are using in 2010. You do have to explicitly
enable it set mouse=a). :help mouse-using for more information.

Not trying to talk you into switching editors, just sayin'.

[ snip ]

 

[Simon Connah]

why not?

Shocking standards support. Microsoft have openly announced that they
have no intention to support C99. That makes it a pretty poor C
compiler if you ask me.

You'd be better off with Clang (and LLVM).

 

[Seebs]

make is hideously non-portable. Or least if the original author was
some sort of make guru.

Depends on whether the original author was a make guru trying to accomplish
something insane without worries about portability (I've done that; I have
a hunk of makefile which is functionally equivalent to xargs with macro
expansions, but I assure you it's GNU make only) or trying to do something
simple, clear, and extremely portable (I've done that too).

-s

 

[Seebs]

The problem with"grep" is that it doesn't understand what it is parsing,
and if you are looking for the definition of a often used symbol, you
will have to waste a lot of time looking at all occurrences of the
symbol until you find the definition.

I usually don't.

If I want to find the definition of struct foo, 'grep "struct foo {" ...'
does fine by me.

But grep is OK for people that use vim and printf debugging. Just go
ahead. Why do something automatically if you can do it by hand?

Heh.

Actually, there are things for which printf debugging is extremely useful.
For instance, let's say you have something which fails about one time
in a million. Which is faster:

1. Setting a breakpoint at the beginning of the operation, and stepping
through it each time to see how it failed.
2. Setting up logging and looking at the previous few log messages
before the failure.

But at each line, you have to type:

print"xxx" to figure out what is the value in variable "xxx".
And if you setup a watch you will have to unset it soon and set
another watch as variables getting used change.

I haven't had much trouble with that. For that matter, I don't usually
print a variable each line; I print it only when I think it's at risk of
changing.

I mean the ability to continue the exection at any line in the
current function. Apparently you have never used that feature of
gdb. No wonder you do not miss it in ddd.

I can't conceive of using that. If I'm not at the line, continuing there
wouldn't be relevant to what the program does outside the debugger anyway.

-s

 

[Herbert Rosenau]

Can someone please point me in the direction of a good easy to use
free C compiler, Im using Code Blocks now but it crashes all the time
and Im beginning to lose the plot with it, got enough problems trying
to learn C without having to fight the compiler to!!!

http://openwatcom.org/index.php/Main_Page

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

 

[Richard Bos]

Can someone please point me in the direction of a good easy to use
free C compiler, I=92m using Code Blocks now but it crashes all the time
and I=92m beginning to lose the plot with it, got enough problems trying
to learn C without having to fight the compiler to!!!

Dev-C++ (which, yes, also does C itself), from is simple and does the
job: <http://www.bloodshed.net/devcpp.html>.

Richard

 

[jacob navia]

Seebs a écrit :

I can't conceive of using that. If I'm not at the line, continuing there
wouldn't be relevant to what the program does outside the debugger anyway.

You have JUST stepped over the problem. Now instead of
starting ALL the program again to arrive at the point of the error,
you go back two lines and REDO the lines that lead to the error
again.

Of course this supposes that those lines are restartable, but in most
cases they are.

 

[Nick]

I haven't had much trouble with that. For that matter, I don't usually
print a variable each line; I print it only when I think it's at risk of
changing.


I can't conceive of using that. If I'm not at the line, continuing there
wouldn't be relevant to what the program does outside the debugger anyway.

Although I use a debugger to grovel through core dumps I've very rarely
indeed had a need to do the "stop, examine, step" type of debugging.

Usually a few judicious printfs will show which value is getting wrong
where very quickly.

When I used assembler it was a very different matter.

I'm not rubbishing it, and clearly different people work different ways,
but just the level of abstraction from assembler to C is enough for me
to not need that sort of thing very often.

 

[Nick Keighley]

Shocking standards support. Microsoft have openly announced that they
have no intention to support C99. That makes it a pretty poor C
compiler if you ask me.

there are plenty around then. I'm not particularly interested in C99
compliance.

 

[Nick Keighley]

Depends on whether the original author was a make guru trying to accomplish
something insane without worries about portability (I've done that; I have
a hunk of makefile which is functionally equivalent to xargs with macro
expansions, but I assure you it's GNU make only) or trying to do something
simple, clear, and extremely portable (I've done that too).

well I don't know what his goals were but he didn't achieve great
portability!

 

[Simon Connah]

there are plenty around then. I'm not particularly interested in C99
compliance.

Fair enough. I do find that somewhat odd though, given that one of the
most important metrics of a good compiler is standards compliance.
Afterall what use is a highly efficient optimising compiler if it does
not compile a large chunk of code that exists out there?

This is probably one of the few reasons I can use for the Intel C++
compiler. It has good C99 support and produces fast optimised code (at
least in comparison to GCC and the Microsoft compiler). I guess it just
depends on how much you are willing to pay for it.

 

[Richard Bos]

So the solution instead is to use a non-POSIX compliant OS

Tom, don't be such an utter weenie. There's nothing wrong with having a
non-POSIX-compliant OS if your aim wasn't to have a POSIX-compliant OS.

Richard

 

[Nobody]

Shocking standards support. Microsoft have openly announced that they
have no intention to support C99. That makes it a pretty poor C
compiler if you ask me.

Not supporting C89 either doesn't help.

 

[Ersek, Laszlo]

the Intel C++ compiler [...] produces fast optimised code

Agner`s CPU blog -- Will Intel be forced to remove the "cripple AMD"
function from their compiler?

http://www.agner.org/optimize/blog/read.php?i=49

http://www.reddit.com/r/programming/comments/al4xu/intels_cripple_amd_function/

Cheers,
lacos

 

[Antoninus Twink]

Right.

Wrong, Heathfield.

display xxx

 

[Antoninus Twink]

Both functions are declared static but "ctags" doesn't understand
"static" of course.

You are using a version of ctags from the stone age.

Try an exuberant ctags from the last decade or so.

(3) easy to use debugger

gdb [and/or DDD on top]

Sure.

Like any tool, it takes a while to get used to gdb, but it's *immensely*
powerful when you do (in my experience).

 

[Antoninus Twink]

The problem with"grep" is that it doesn't understand what it is parsing,
and if you are looking for the definition of a often used symbol, you
will have to waste a lot of time looking at all occurrences of the
symbol until you find the definition.

Which is why sane people would instead use ctags (set up so that it gets
rebuilt automatically with every make) and then CTRL+] in vim.

For variables defined in the same file, you don't even need to use ctags
- just gd (local variables) or gD (file-scope variables).

 

[Keith Thompson]

Not supporting C89 either doesn't help.

I thought they had pretty good support for C89.