Pelles C versus Code::Blocks

[CommonTater]

Ralf, ah loves ya man... but I'm seriously starting to think you're stuck in some kind of time warp...

Why, because I just don't follow all the new "shiny, shiny" and rather stick to stuff that's tested and proven? 
Has served me very well for the last 36 years and I am sure it will serve me well for many years to come... 

See, now that I can agree with... I'm no victim of fads either and I certainly don't run out to get the very latest of anything.  That said... there is reasonable precaution and there's something approaching either "too lazy to upgrade" or "too paranoid to change" that we must guard against. 

Like you I stick to pretty basic code I'm not deliberately trying to do anything "the C-11 way" but at the same time if there is a function or procedure available that does what I need then, well shucks, I'm gonna use it!  Moreover; I'm not going to care if it's 30 minutes or 30 years old.  (Hint: Once it's compiled and working... it's all just machine code, anyway.)

Getting back to the specific thing about loading files in Hydronium's thread... That whole business about reading files line by line or character by character is an artifiact of 64k RAM systems that has somehow gotten carried forward through computer class after computer class.  Many files in modern use are to be used as a single entitity... images being an excellent example but there are tons of others.  These files *have* to be in one piece in memory or you're not going to use them.... what's the advantage of loading them character by character vs one ReadFile() call?  There isn't any... The only reason to read a 5mb BMP file character by character is that "I've always done it this way" and that's a plain terrible reason, my friend, ... especially when there's a single function that can copy the file at full disk speed. 
 
I absolutely agree with playing it safe... but in my experience there's no correlation between "old" and "safe" in fact one can make the argument that older functions --particularly those relying upon guestimated buffer sizes-- are far less safe than many of the newer ones.
 
Finally; I see no reason to be all bent out of shape over "muti-platform" or "multi-compiler" compatibility.  To the best of my knowledge, none of the code I've written has ever been compiled on anything but Pelles C... and I'm betting that is the case with the vast majority of programmers' code... They sweat and struggle with broadest common denominator concerns, costing themselves weeks in development... then in the long run they are the only person ever to compile the code. I couldn't care less about all this "needs to run on freeBSD" crap... those guys weren't my customers and the odds of my professional source code being ported anywhere are exactly 0 since it never leaves my posession.
 
Anyway, Ralf, I mean no offense whatsoever and, for sure, we've had this discussion in various forms before... My friend, we're going to agree about precaution... but not to the level you take it.
 

[CommonTater]

That's perfectly fine by me, but not everyone is happy to be forced to write legacy C code even 12 years after C99 debut.

Hi Mig... The reason I suggested starting with C in Console mode was not so much because C++ is a simple step... it isn't.  It's more for the purpose of starting off with simple methodology and helping someone get their head around some of the more fundimental programming tasks before throwing them in with the sharks .

(Good to see you back posting!)

[migf1]

Ralf, ah loves ya man... but I'm seriously starting to think you're stuck in some kind of time warp...

Why, because I just don't follow all the new "shiny, shiny" and rather stick to stuff that's tested and proven? 

Has served me very well for the last 36 years and I am sure it will serve me well for many years to come... 

Ralf

No argument there, you know better than anyone what serves you best. But I don't agree on generalizing based on one man's needs

For example, before version 2010, the Visual Studio was not supporting <stdint.h>/<inttypes.h>. Thus if you needed your code to use guaranteed fixed size types, no matter the platform you compile your code on, you had to go through a hell lot of a tedious coding, trying to do it with strict C89/90 (mostly defining your own types, based on CHAR_BITS in <limits.h>, with or without using the TYPE_MAX/TYPE_MIN constants).

You could always copy <stdint.h> and/or <inttypes.h> from a C99 compliant compiler, and start using it directly, but in that case it would be like using C99 in the first place (saving you all the C89/90 hassle).

C99 is not an experimental standard. It is mature, well established, well tested and well supported for a long time, by most (if not all) major C compilers.

I would fully agree if we were talking about C11, which is indeed way too early to accept it as a mature/reliable standard. It is not, it is not even supported by most compilers yet (it took years for C99 to be established, so I assume the same will happen with C11).

@Tater:

Hello buddy, glad to be back

I think we both suggested the same thing, that the console is an excellent way for any beginner to start learning the language and its mechanics.

[andre104]

Hi walep,

Both Pelles C and Code::Blocks are, IMO, excellent tools in their own rights.
If your plan is to use only C in Windows, then use Pelles C.
But if you are looking for cross-platform, configurable IDE, then go for Code::Blocks.

I don't see a reason to use one and discard the other.