good easy to use Free C compiler!!

[Interrupt]

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

 

[jacob navia]

Interrupt a écrit :

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

The lcc-win compiler should work.

I am the author of that. Download it and if you have a problem
write to
jacob at jacob dot remcomp dot fr

The download address is:

http://www.cs.virginia/edu/~lcc-win32

 

[Noob]

Can someone please point me in the direction of a good easy to use
free C compiler

http://en.wikipedia.org/wiki/GNU_Compiler_Collection
http://gcc.gnu.org/

 

[Nick Keighley]

The lcc-win compiler should work.

I am the author of that. Download it and if you have a problem
write to
jacob at jacob dot remcomp dot fr

The download address is:

http://www.cs.virginia/edu/~lcc-win32

note: this is free only for non-commercial use (which you may be fine
with)

You didn't say which platform you were on, I assume code blocks is
windows based since Jacob recommended lcc-win32. Other free windows
compilers are Microsoft Visual C++ Express (yeah, it really is a C
compiler), and mingw. mingw is an implemention of the widely used gcc
compiler.

 

[Andre Fernandes]

Unix - GCC is an easy choice.
Mac - Xcode (IDE) + GCC (compiler) (both free with the OS, so I'd consider
that free). Windows - Visual C++ Express

Yeah, I know, many will disagree, but that's free and easy for a beginner..

--

And visual C++ is a very good compiler (newer versions only, older
ones were disaster), I do use it for my windows applications.

 

[oksid]

See also http://www.cpax.org.uk/prg/portable/c/resources.php#FreeCompilers

The Pacific C link on your page is broken.
( http://www.hitech.com.au/products/pacific.html )

Hitech is now only selling Microchip compilers.

 

[jacob navia]

Tetsuya a écrit :

vim + gcc

That is a very bad choice.

What is missing is (among others)

(1) goto definition of a symbol
(2) usage of a symbol
(3) easy to use debugger
(4) automatic project management (makefile generation)

and many other things. Note that the original poster asked
for an "easy to use" system. vim is surely not an easy
to use system, unless you know it very well or you learn by
heart all those commands.

Please, we are in 2010, not 1975

jacob

 

[Tom St Denis]

That is a very bad choice.

What is missing is (among others)

(1) goto definition of a symbol
(2) usage of a symbol

Look up ctags.

(3) easy to use debugger

gdb [and/or DDD on top]

(4) automatic project management (makefile generation)

??? Writing makefiles is not usually that hard. Just add new .c files
to it as you write them.

and many other things. Note that the original poster asked
for an "easy to use" system. vim is surely not an easy
to use system, unless you know it very well or you learn by
heart all those commands.

Please, we are in  2010, not 1975

So the solution instead is to use a non-POSIX compliant OS and non-C99
compiler? uh, ok.

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], but a typical
UNIX environment [e.g. a proper shell, GNU make, gcc, etc] is way more
productive than anything you'd find in MSVC or lcc-win32 world. Also
they're free to acquire...

Tom

 

[jacob navia]

Tom St Denis a écrit :

Look up ctags.

Just for fun I did

ctags *.c

in the directory where I have the Container library code.

I obtained:

Duplicate entry in files dlist.c and bitstrings.c: Contains (Warning only)

Duplicate entry in file dlist.c, line 206: DestroyListElements
Second entry ignored


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

It doesn't understand #defines correctly either, and you can't tell it
what defines are active or not.

It doesn't understand the syntax of what is parsingat all. That is
why it can parse Fortran and C and Pascal...


This type of primitive "utility" is what people like you love.
ANYTHING if it is:

o text mode,
o Unix

and (of course) gnuish.

(3) easy to use debugger

gdb [and/or DDD on top]

Sure.

(1) No automatic display of variables getting used.
(2) ddd doesn't even support all gdb commands (set next line for instance)
(3) It has some funny features... for instance the continuous
stream of errors displayed in the console when it starts.

??? Writing makefiles is not usually that hard. Just add new .c files
to it as you write them.

Sure. Why do automatically something that can be done by hand?

So the solution instead is to use a non-POSIX compliant OS and non-C99
compiler? uh, ok.

Yeah dude, windows is a product of the evil empire.
And lcc-win since it runs under windows is also very
suspect.

what a mentality!

 

[Rob Kendrick]

Sure. Why do automatically something that can be done by hand?

Because some of us value being able to easily port and maintain our
Makefiles elsewhere. I've not found an automatic makefile generation
tool (including automake) that makes satisfactory ones.

Sure, your favourite IDE is just fine for this, just as long as you
don't care about building your product elsewhere.

B.

 

[jacob navia]

Rob Kendrick a écrit :

Because some of us value being able to easily port and maintain our
Makefiles elsewhere. I've not found an automatic makefile generation
tool (including automake) that makes satisfactory ones.

Sure, your favourite IDE is just fine for this, just as long as you
don't care about building your product elsewhere.

B.

And why lcc-win's makefiles wouldn't run anyhere?

The make utility of lcc-win is very primitive. The generated makefiles
use almost NOTHING from the features of a makefile utility. I have tried
them under linux and AIX, and they run unmodified (after you
erase the carriage return characters of windows.


Most makefiles written under Unix assume gmake, that has a lot of
features NOT found in other make utilities. lcc-win uses none of that.

You have never used lcc-win, and you just do not know what are you
talking about.

And, if you like writing makefiles, you can always write yours.
Lcc-win doesn't force you to generate a makefile.

 

[Richard Tobin]

Just for fun I did

ctags *.c

in the directory where I have the Container library code.

I obtained:

Duplicate entry in files dlist.c and bitstrings.c: Contains (Warning only)

Duplicate entry in file dlist.c, line 206: DestroyListElements
Second entry ignored

I use etags, which doesn't have that problem. But then I use emacs
rather than vi.

This type of primitive "utility" is what people like you love.
ANYTHING if it is:

o text mode,
o Unix

and (of course) gnuish.

Yes, there's some truth in that. Obviously I want it to run on unix,
because that's what I use. I've never found graphical interfaces
helpful for programming - quite the reverse. And certainly I favour
software that I and others can modify and redistribute.

-- Richard

 

[Rob Kendrick]

Rob Kendrick a écrit :

And why lcc-win's makefiles wouldn't run anyhere?

The make utility of lcc-win is very primitive. The generated makefiles
use almost NOTHING from the features of a makefile utility. I have
tried them under linux and AIX, and they run unmodified (after you
erase the carriage return characters of windows.

I'm talking in the general sense. And why would anybody want to use
lcc-win32 when Visual C++ Express is available?

Most makefiles written under Unix assume gmake, that has a lot of
features NOT found in other make utilities. lcc-win uses none of that.

Most, but not all. Just because people can use a feature doesn't mean
they do.

You have never used lcc-win, and you just do not know what are you
talking about.

You're talking out of your hat.

B.

 

[Tom St Denis]

Just for fun I did

ctags *.c

in the directory where I have the Container library code.

I obtained:

Duplicate entry in files dlist.c and bitstrings.c: Contains (Warning only)

Duplicate entry in file dlist.c, line 206: DestroyListElements
Second entry ignored

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

It doesn't understand #defines correctly either, and you can't tell it
what defines are active or not.

It doesn't understand the syntax of what is parsingat all. That is
why it can parse Fortran and C and Pascal...

This type of primitive "utility" is what people like you love.
ANYTHING if it is:

o text mode,
o Unix

and (of course) gnuish.

I don't use ctags myself, I have used it on other code bases but
mostly I just grep the damn ctags archive to find what I need.
Usually I just grep the source tree [or header files] for symbols I
need to find the origins of.

gdb [and/or DDD on top]

Sure.

(1) No automatic display of variables getting used.

You can watch variables, you just have to know what you're debugging.
You can step through code, one line at a time.

(2) ddd doesn't even support all gdb commands (set next line for instance)
(3) It has some funny features... for instance the continuous
    stream of errors displayed in the console when it starts.

Maybe your build is fudged? Mine will tell me about any threads or
whatever that are preloaded before execution but that's about it.
This is what I get on my ubuntu 9.04 laptop [in 32-bit mode]

---
tom@tom-laptop:~$ gcc -g3 test.c -o test
tom@tom-laptop:~$ gdb test
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/
gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb)
---

Where test.c is a simple hello-world app. Wow, lots of errors. I use
gdb all the time to debug things and it hasn't failed me yet.

Sure. Why do automatically something that can be done by hand?

Because I tend to write makefiles that have a lot of options and/or
smarts to them. I'm just saying that on a day-to-day basis adding new
files is not that hard [once you have the framework up]. It's not
something I need a tool [other than an editor] to help me with.

Yeah dude, windows is a product of the evil empire.
And lcc-win since it runs under windows is also very
suspect.

what a mentality!

No, but look who's talking about getting with the times. Even the
Apple crowd got on the POSIX bandwagon. Microsoft chugs along merrily
like nothing is happening. Meanwhile in a stock Microsoft OS you're
stuck with no shell, no userland tools, no development tools,
nothing. Even when you shell out the $600 [or whatever the heck it is
this week] for a licensed copy of VS C++ you still don't get any
command line tools [like bash/sed/grep/make/etc] that make development
easier [scripting is infinitely better than a menu or two], instead
you get a development studio that takes up 8GB of disk space and is
shit slow to load/work with. On my Ubuntu laptop a FULL install that
includes OS, office suite, multimedia suite, development tools, IM/www/
etc takes less than a couple GB of space. I get all my work done with
these tools too.

If you want to talk about getting this this era, I'd start looking at
Windows and what you DON'T get.

 

[Simon Connah]

Other free windows
compilers are Microsoft Visual C++ Express (yeah, it really is a C
compiler)

Good, C and Visual C++ and compilers are words which probably should
not be in the same sentence as each other.

Also there seems to be a worrying confusion between compilers and IDEs
in this thread. Code:Blocks is an IDE and not a compiler. The compiler
the OP is using is probably fine they just want a different way to use
it (be that text editor or full blown IDE).

 

[Nick Keighley]

Good, C and Visual C++ and compilers are words which probably should
not be in the same sentence as each other.

why not?

 

[Nick Keighley]

[vim/gcc] is a very bad choice.

What is missing is

(4) automatic project management (makefile generation)

??? Writing makefiles is not usually that hard.  Just add new .c files
to it as you write them.

add to what? Doesn't this rather assume you already have a make file?


is vim a vi derivative! Good grief. He'll be recomending teco next...

VI VI VI the editor of the beast.

Please, we are in  2010, not 1975

So the solution instead is to use a non-POSIX compliant OS and non-C99
compiler?  uh, ok.

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], but a typical
UNIX environment [e.g. a proper shell, GNU make, gcc, etc] is way more
productive than anything you'd find in MSVC or lcc-win32 world.  

this is just an opinion.

Also they're free to acquire...

so are all the other free tools we mentioned.

 

[Nick Keighley]

Tom St Denis a écrit :

[vim/gcc] is a very bad choice [for an easy to use C compiler]
What is missing is (among others)

gdb [and/or DDD on top]

Sure.

(1) No automatic display of variables getting used.
(2) ddd doesn't even support all gdb commands (set next line for instance)
(3) It has some funny features... for instance the continuous
    stream of errors displayed in the console when it starts.

if by "it" you mean ddd, the stream of errors can be suppressed pretty
easily.

 

[Nick Keighley]

On Wed, 20 Jan 2010 20:23:27 +0100



Because some of us value being able to easily port and maintain our
Makefiles elsewhere.

??

try porting sun makefiles to linux...

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

 I've not found an automatic makefile generation
tool (including automake) that makes satisfactory ones.

Sure, your favourite IDE is just fine for this, just as long as you
don't care about building your product elsewhere.

my experience is much the same for make

 

[jacob navia]

Tom St Denis a écrit :

I don't use ctags myself, I have used it on other code bases but
mostly I just grep the damn ctags archive to find what I need.
Usually I just grep the source tree [or header files] for symbols I
need to find the origins of.

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.

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?

Avoid good IDEs and go through the grep output at each time you
are looking for a variable definition.

(3) easy to use debugger
gdb [and/or DDD on top]

Sure.

(1) No automatic display of variables getting used.

You can watch variables, you just have to know what you're debugging.
You can step through code, one line at a time.

"You can step through code one line at a time"

GREAT!!!

It would be difficult to have a debugger that doesn't do that of course.

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.

But why do automatically something that can be done by
hand?

(2) ddd doesn't even support all gdb commands (set next line for instance)
(3) It has some funny features... for instance the continuous
stream of errors displayed in the console when it starts.

Maybe your build is fudged? Mine will tell me about any threads or
whatever that are preloaded before execution but that's about it.
This is what I get on my ubuntu 9.04 laptop [in 32-bit mode]

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.