good easy to use Free C compiler!!
Interrupt
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
> Can someone please point me in the direction of a good easy to use
> 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:
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
> > 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
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.
Richard Heathfield
> On 19 Jan, 15:46, jacob navia <ja...@nospam.org> wrote:
>
>>> 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
>
> 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.
Code::Blocks is a C++ IDE that supports Linux and Windows.
> 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.
See also http://www.cpax.org.uk/prg/portable/c/resources.php#FreeCompilers
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Lionel Pinkhard
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.
--
--------------------------------------------------------------
Professional mobile software development
BreezySoft Limited www.breezysoft.com
--------------------------------------------------------------
Andre Fernandes
And visual C++ is a very good compiler (newer versions only, older
ones were disaster), I do use it for my windows applications.
Richard Heathfield
<snip>
> And visual C++ is a very good compiler (newer versions only, older
> ones were disaster), I do use it for my windows applications.
Actually, the older versions of VC++ were just fine (for writing and
compiling C, at any rate).
Lionel Pinkhard
I use VS2005 for all my Windows work (though it's not free, it's pretty cheap
if you go for Standard), never let me down. Xcode for Mac and straight GCC
for the rest.
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
> Interrupt wrote:
>> Can someone please point me in the direction of a good easy to use
>> and I�m beginning to lose the plot with it, got enough problems trying
>> to learn C without having to fight the compiler to!!!
>
>
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
> On Jan 20, 1:01 pm, jacob navia <ja...@spamsink.net> wrote:
>> 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.
>
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.
>> (4) automatic project management (makefile generation)
>
> ??? 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?
>> 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.
>
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
jacob navia <ja...@spamsink.net> wrote:
> >> (4) automatic project management (makefile generation)
> >
> > ??? 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?
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
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
jacob navia <ja...@jspamsink.org> wrote:
>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
--
Please remember to mention me / in tapes you leave behind.
Richard Heathfield
> Tetsuya a �crit :
>> Interrupt wrote:
>>> 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!!!
>>
>> vim + gcc
>>
>
> That is a very bad choice.
Perhaps, but it works just fine for me.
<snip, as others have already discussed this bit>
> [...] 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.
vim is actually very easy to use. It's hard to /learn/, but ease of
learning and ease of use are not the same thing. Once you've climbed
vim's learning curve, it's extremely powerful.
> Please, we are in 2010, not 1975
I don't see any reason to stop using powerful tools just because the
date has changed slightly.
Richard Heathfield
> Richard Heathfield wrote:
>> 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 )
Thanks. I'll try to remember to fix that up (when I'm less tired).
Rob Kendrick
jacob navia <ja...@spamsink.net> wrote:
> Rob Kendrick a écrit :
> > On Wed, 20 Jan 2010 20:23:27 +0100
> > jacob navia <ja...@spamsink.net> wrote:
> >
> >>>> (4) automatic project management (makefile generation)
> >>> ??? 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?
> >
> > 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.
> >
>
> 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.
> >> (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.
> (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
> On 2010-01-19 15:50:50 +0000, Nick Keighley said:
>
> > 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.
why not?
Nick Keighley
> On Jan 20, 1:01 pm, jacob navia <ja...@spamsink.net> wrote:
> > [vim/gcc] is a very bad choice.
>
> > What is missing is
<snip>
> > (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?
> > 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.
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.
--
Campaign Against Unix Bigotry
(CAUB)
Nick Keighley
> Tom St Denis a écrit :
> > On Jan 20, 1:01 pm, jacob navia <ja...@spamsink.net> wrote:
> >> [vim/gcc] is a very bad choice [for an easy to use C compiler]
>
> >> What is missing is (among others)
<snip>
> >> (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.
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
> jacob navia <ja...@spamsink.net> wrote:
> > >> (4) automatic project management (makefile generation)
>
> > > ??? 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?
>
> 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
>
> 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.
Richard Heathfield
> 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?
It would be much easier to discuss such things with you if you were a
little more dispassionate about them.
Okay, so I use grep. I use vim. And yes, I even use printf. I also use
Visual C++'s very powerful (i.e. not-quite-as-powerful-as-vim) editor.
And its symbol search capabilities. And (on occasion) its debugger. And
gdb. And I use a keyboard, but I also have and occasionally use a mouse.
I use Linux - and Windows. On rare occasions, I will use awk, perl,
even dc, if the need arises. I am prepared, in fact, to use *any* tool
that will get the job done quickly and effectively. That's why I like
vim so much. Okay, so you don't like it? Fine, don't use it - I don't
have a problem with that. But just because you don't get on with it,
that doesn't mean that everyone else in the world will be like you. Nor
does it mean that people who are not like you are idiots.
> Avoid good IDEs and go through the grep output at each time you
> are looking for a variable definition.
That's sometimes a good idea. For example, it is sometimes possible for
grep to get the result you need rather more quickly than it takes for an
IDE to load. If all you need is the filename, grep makes more sense than
the IDE.
<snip>
[gdb]
> But at each line, you have to type:
>
> print"xxx" to figure out what is the value in variable "xxx".
Right. Which means it only takes up screen space when you need it to.
Sounds good to me.
> 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?
Sometimes a manual process /is/ quicker and more effective. Very often,
of course, it isn't. It depends.
<snip>
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
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)
blm...@myrealbox.com
[ 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 ]
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
Simon Connah
> On 21 Jan, 08:17, Simon Connah <simon.con...@googlemail.com> wrote:
>> On 2010-01-19 15:50:50 +0000, Nick Keighley said:
>>
>>> 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.
>
> 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
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
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.
Herbert Rosenau
wrote:
> 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!!!
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
> On 2010-01-21, jacob navia <ja...@spamsink.net> wrote:
>> 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.
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.
Richard Heathfield
wrote:
> oksid wrote:
>> Richard Heathfield wrote:
>>> 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 )
>
> Thanks. I'll try to remember to fix that up (when I'm less tired).
I have now replaced (or rather, truncated) the above link, losing the
pacific.html, which leaves a currently valid and relevant URL.
Nick
> On 2010-01-21, jacob navia <ja...@spamsink.net> wrote:
>> 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.
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.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
Nick Keighley
there are plenty around then. I'm not particularly interested in C99
compliance.
Nick Keighley
> On 2010-01-21, Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
>
> > 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).
well I don't know what his goals were but he didn't achieve great
portability!
Simon Connah
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
> On Jan 20, 1:01=A0pm, jacob navia <ja...@spamsink.net> wrote:
> > Please, we are in =A02010, not 1975
>
> 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
>>> Good, C and Visual C++ and compilers are words which probably should
>>> not be in the same sentence as each other.
>>
>> 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.
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
> jacob navia wrote:
>> But at each line, you have to type:
>> print"xxx" to figure out what is the value in variable "xxx".
>
> 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
I thought they had pretty good support for C89.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Albert
> Can someone please point me in the direction of a good easy to use
> and I�m beginning to lose the plot with it, got enough problems trying
> to learn C without having to fight the compiler to!!!
Install Cygwin with gcc, gdb and vim. Use printf statements to
*selectively* print out values of variables and gdb to debug seg
faults/get a stack trace.
According to Dave Taylor in Teach Yourself Unix in 24 Hours, First
Edition, "...you will need two hours to learn to use vi." I myself don't
know all the commands of vi let alone vim, but I'm already editing much
quicker than in Notepad, Code::Blocks, Dev-cpp, nano or Kate. That was
just going through usr_01 to usr03.txt in the vimtutor.
jaysome
Simon,
Using the "/Za" option with a Microsoft compiler should disable
language extensions and result in compliance with the ANSI C89
standard. Have you found otherwise? If so, please tell.
--
jay
Simon Connah
> On Fri, 22 Jan 2010 15:55:02 +0000, Nobody <nob...@nowhere.com> wrote:
>
>> On Thu, 21 Jan 2010 19:44:10 +0000, Simon Connah wrote:
>>
>>>>> Good, C and Visual C++ and compilers are words which probably should
>>>>> not be in the same sentence as each other.
>>>>
>>>> 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.
>>
>> Not supporting C89 either doesn't help.
>
> Simon,
I didn't post that.
Flash Gordon
> Nobody <nob...@nowhere.com> writes:
>> On Thu, 21 Jan 2010 19:44:10 +0000, Simon Connah wrote:
>>>>> Good, C and Visual C++ and compilers are words which probably should
>>>>> not be in the same sentence as each other.
>>>> 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.
>> Not supporting C89 either doesn't help.
>
> I thought they had pretty good support for C89.
You are right, it does, with the same caveats as all other compilers. To
get it to follow the standard you have to tell it to follow the standard
(as with all the other compilers), and there may be some bugs (as with
all the other compilers).
--
Flash Gordon
Interrupt
recommended, I’ve settled on Open Watcom which for me as a beginner is
the most intuitive! Also doesn’t crash constantly!
Thanks for the input!!!
Simon Connah
That is an IDE not a compiler. It uses the GCC compiler.
I'm not entirely sure why people find it so hard to distinguish between
an IDE and a compiler.
bartc
"Simon Connah" <simon....@googlemail.com> wrote in message
news:hjicgs$693$1...@speranza.aioe.org...
I don't think a compiler need be a standalone program, even if they are
frequently designed that way.
So if an IDE can compile programs (however it does so), then I guess it can
be considered a compiler, with some extra facilities.
--
Bartc
Conor
about the available free C compilers for C development under Windows.
Yes, it's a little Windows specific all of a sudden but at least it's
still C programming!
I do like the command line BTW. The last IDE I used was Turbo C 2.01,
but that 10 years of Unix for you. Type "make", go get coffee/sleep.
Computers are too fast now, can't sleep during compiles any more :-(
Ok, there's the free Borland 5.5 compiler, which is a little dated
perhaps, especially in regards to the Windows API. However, nothing
prevents me from writing my own header files, copying from the Win
SDK! It has the distinct advantage of being standalone, with no
install (just a 8MB zip file). Set your PATH and off you go. You do
end up doing a static link against Borland CRT.
Visual C++ 2005/2008 Express is free but you need to download the
Windows SDK to do anything useful like Win32 programming. Ruddy great
big install. Looks like you can dynamically link with a sole
dependency on msvcrt.dll, but you can't. There's MSVCR70.DLL,
MSVCR80.DLL and MSVCR90.DLL and they can sod off if they think I'm
distributing them. So static link again. Sigh.
{
Note Visual C++ 2008 creates an unnecessary dependency by calling
GetSystemWindowsDirectoryW. So compiled executables will not run on
Windows 98SE or ME. Now, I don't worry too much about 98SE given its
age but I'll be damned to hell if I'll let Microsoft dictate to me
what markets I may not access. It's one thing if I'm knowingly using
calls that 98SE didn't have but it's quite another to have MS
arbitrarily remove that market (however big it is). Rant over.
Sorry :-)
}
The earlier free Visual C++ compilers were non-optimising. Which I
thought was rather mean.
Erm. I'm not all that sure about Borland's CRT library and threading.
MS no longer has a single threaded CRT anymore, just libcmt.... I
worry about things like errno biting me in the ass some day. Someone
somewhere mentioned that everything is threaded on WinXP and the CRT
should be written to assume that (or maybe I'm losing it.)
I haven't used Watcom C or MinGW, but maybe those are better. I guess
I have a irrational liking for Borland given my love of Turbo C all
those years ago! I keep feeling it would be nice to dynamic link
against msvcrt.dll, given that it is always there, but perhaps I'm
being irrational and static linking is just fine. If Sysinternals can
produce single 100KB executables that do magic and don't need a
massive redistributable, then so can I. Maybe...
Cheers,
Conor.
Paul Richards
Have a look at Pelles C - fairly full implementation of C99 and a good,
lightweight IDE.
Conor
> lightweight IDE.
Ah yes, based on the LCC compiler. A friend picked bits out of it at
some point when he needed a resource editor. I think he still ended up
compiling with Borland 5.5 though. Hard to change habits!
At least there are choices out there which is a good thing.
jamm
VisualStudio/Express is a pretty nice tool though.
--
*From the 1966 TV series:*
Robin: You can't get away from Batman that easy!
Batman: Easily.
Robin: Easily.
Batman: Good grammar is essential, Robin.
Branimir Maksimovic
>
> Visual C++ 2005/2008 Express is free but you need to download the
> Windows SDK to do anything useful like Win32 programming. Ruddy great
> big install. Looks like you can dynamically link with a sole
> dependency on msvcrt.dll, but you can't. There's MSVCR70.DLL,
> MSVCR80.DLL and MSVCR90.DLL and they can sod off if they think I'm
> distributing them. So static link again. Sigh.
>
> {
> Note Visual C++ 2008 creates an unnecessary dependency by calling
> GetSystemWindowsDirectoryW. So compiled executables will not run on
> Windows 98SE or ME. Now, I don't worry too much about 98SE given its
> age but I'll be damned to hell if I'll let Microsoft dictate to me
> what markets I may not access. It's one thing if I'm knowingly using
> calls that 98SE didn't have but it's quite another to have MS
> arbitrarily remove that market (however big it is). Rant over.
> Sorry :-)
> }
Well, you can always write your own version of crt ;)
Or you don;t have to use crt at all ;)
I like express edition, it's really professional IDE.
No need for commercial editions at all.
VC++ can read typelibs like headers, which is good, too.
Win SDK you have to download if you want 64 bit compiler
and useful tools.
Greets
Conor
> Or you don;t have to use crt at all ;)
It has been done by developers, presumably those with a lot of time on
their hands! I won't be rushing to the top of that particular queue
though! You need to write startup code at the very minimum.
> VC++ can read typelibs like headers, which is good, too.
> Win SDK you have to download if you want 64 bit compiler
> and useful tools.
Yes, like MIDL and the typelib stuff if you want to do COM development
(IDispatch). Which I might at some point so I should go get the SDK
anyway I guess.
Conor.