Memory Leak

I am using C, but the compiler should atleast give a warning when a possible memory leak could occur.

This is only offered as a feature of the debug CRT that you must enable. C/C++ does not hold the dev's hand during development nearly as much as managed languages do. The compiler will never warn you of a possible memory leak. The debug CRT will track allocations and de-allocations for you and with the correct configuration will link you to the lines of code that are the source of the leak.

Originally Posted by P4R4N01D

I am using C, but the compiler should atleast give a warning when a possible memory leak could occur.

As Bubba points out, it does not. It's your error if you do and the compiler isn't smart enough to hold your hand to ensure leaks do not occur.

The program is better now, it was due to parameters being passed to functions (GetUserNameA etc.) as the wrong type. The compiler gave these warnings and i fixed them up (eventually).

These are errors, not warnings. In C, the compiler may show them as warnings, but they are errors - your errors and if a leak occurs due to this, then the compiler isn't helping you understand there's a leak, but instead tell you that you made a programming error.

I see, I was only thinking of the compiler generating a warning/error when a variable that is alloced (malloc, or the like is not freed), but this is not a major problem and does not take long to fix. Due to this bing the first Win32 Gui aplication I created this was the only way I thought a memory leak could occur and trying to make a reason to why this would occur only made it worse. However, the compiler should check that the parameters bing passed to ach function are the same type. lcc-Win32 didn't generate any warnings or errors and dcidd to corrupt some strings so the square kept coming up under th user name column (this was probably having an effct on the memory. I decided to debug th application mainly to fix this bug, not the memory leak. It does get annoying with all the slightly different data types that are defind in windows.h and I have to keep going back to msdn to find what params must be passed to each function. Testing it now, the program does not undergo any rapid increase in memory usage. Interesting if lcc-Win32 had a debugger so I could see what was acctually happening and how it came up with strange characters in the string. Oh, well and thanks again, great help.

However, the compiler should check that the parameters bing passed to ach function are the same type. lcc-Win32 didn't generate any warnings or errors and dcidd to corrupt some strings so the square kept coming up under th user name column (this was probably having an effct on the memory. I decided to debug th application mainly to fix this bug, not the memory leak.

Your time would be better served becoming a better programmer than blaming your errors on someone or something else. Always assume it's your code rather than a fairly well established code base like a compiler. The compiler will warn you of many things and it does type checking on the parameters so I'm not sure what you are talking about. Blame your code not the compiler for failing to do everything for you.

It does get annoying with all the slightly different data types that are defind in windows.h and I have to keep going back to msdn to find what params must be passed to each function. Testing it now, the program does not undergo any rapid increase in memory usage.

This has nothing to do with C or with the compiler. The compiler doesn't care what data types Windows uses. Windows.h defines all the data types that Windows uses and while I agree it's a mess the real blame goes to Microsoft Windows Dev team rather than the compiler team.

Originally Posted by Bubba

Your time would be better served becoming a better programmer than blaming your errors on someone or something else. Always assume it's your code rather than a fairly well established code base like a compiler.

Yeah, I am not that experienced at C, and I will stop blaming the compiler. However, I still believe that Dev-C++ is better than lccWin32 (it has a debugger, more warnings, looks better etc.) and the include files should be the same. These things are standard, they come with the compiler. What is defined in say win.h from lccWin32 definitely should not be missing from Dev-C++. This only ends up with either going in and editing the .25million line file or the code being less readable.

Originally Posted by Bubba

This has nothing to do with C or with the compiler. The compiler doesn't care what data types Windows uses. Windows.h defines all the data types that Windows uses and while I agree it's a mess the real blame goes to Microsoft Windows Dev team rather than the compiler team.

I don't blame C, MS is the problem. I still think they've ruined C by creating C# so that is why I never intend to use it (but that is beside the point).

Originally Posted by P4R4N01D

I see, I was only thinking of the compiler generating a warning/error when a variable that is alloced (malloc, or the like is not freed), but this is not a major problem and does not take long to fix.

The compiler cannot possible know when you allocate something and free it. It doesn't include such an advanced flow analyzer to detect such errors. It's up to you to solve. This is also an unfortunate side effect of C--it does not offer any sort of automatic memory management.

Originally Posted by P4R4N01D

Yeah, I am not that experienced at C, and I will stop blaming the compiler. However, I still believe that Dev-C++ is better than lccWin32 (it has a debugger, more warnings, looks better etc.) and the include files should be the same. These things are standard, they come with the compiler. What is defined in say win.h from lccWin32 definitely should not be missing from Dev-C++. This only ends up with either going in and editing the .25million line file or the code being less readable.

Header files aren't standard. Using headers made for one compiler with another will only result in bad things™.

I don't blame C, MS is the problem. I still think they've ruined C by creating C# so that is why I never intend to use it (but that is beside the point).

Lol OK, now that's a funny comment.
Microsoft didn't invent C and the API was made long before C# was even thought of. No, C# didn't ruin C. Microsoft ruined the API at the first moment they made it. And IMHO, it ruined it also because they made it C (not C++).

Originally Posted by Elysia

Header files aren't standard. Using headers made for one compiler with another will only result in bad things™.

What, even windows.h? msdn does define all the constants, data types etc. so following on from their article there is not much more annoying than getting an error in that magic one line of code that will do exactly what you want (OK I haven't found this magic "one line" yet, but it was just an example).
Also It is worth noting that among other things I learnt C to get away from the .net framework (which C# has I believe). Anyway C# would be a better language than VB if it allows you to use the Win32 API directly (load your own dlls even, made with C).

Microsoft ruined the API at the first moment they made it.

In some respects (I asked my computing teacher about it and he said many functions had bad names, and above all advised against using it). It still needs to be there otherwise there would be no applications for windows (or they would be insanely hard to write), pretty boring an OS that does nothing.

Originally Posted by P4R4N01D

What, even windows.h? msdn does define all the constants, data types etc. so following on from their article there is not much more annoying than getting an error in that magic one line of code that will do exactly what you want (OK I haven't found this magic "one line" yet, but it was just an example).
Also It is worth noting that among other things I learnt C to get away from the .net framework (which C# has I believe). Anyway C# would be a better language than VB if it allows you to use the Win32 API directly (load your own dlls even, made with C).

No, it's not standard and it's in fact filled with Microsoft extensions.
Some compilers have even made their own Windows header files.
And if you want to get away from C#, then IMO, that would be C++. C really has no place in today's PC computer program (again, IMHO). C++ was designed to be today's C.

In some respects (I asked my computing teacher about it and he said many functions had bad names, and above all advised against using it). It still needs to be there otherwise there would be no applications for windows (or they would be insanely hard to write), pretty boring an OS that does nothing.

Indeed. Now you know why they haven't dropped backwards compatibility and all that.