But consider the following:
You'd now report there was 2 lines, incorrect -- there's 3.Code:line1\n line2\n line3
But consider the following:
You'd now report there was 2 lines, incorrect -- there's 3.Code:line1\n line2\n line3
How about this then:
Code:FILE* f; int lines = 0; char Buffer[10000]; fopen_s(&f, "C:\\test.txt", "r"); while ( fgets(Buffer, sizeof(Buffer), f) ) { if (Buffer[strlen(Buffer) - 1] == '\n') lines++; } lines++;
Originally Posted by Adak
Wrong. You'd report 1 line for an empty file.
Kurt
Not to mention you're using sick twisted Microsoft renamed functions.
fopen_s, ewwwww.
Hmmm. Additional logic is required.
They're a safe version of the runtime library, which isn't Microsoft specific AFAIK.
Even if they were, I'd rather use safe functions than unsafe. They're easy to do away with with macros or wrappers anyway.
fopen() is unsafe how?
Well, I didn't say it's unsafe, but if there's a "safer" version available, I'll use it.
Besides, fopen is deprecated (in Visual Studio 2005/2008!). That's reason enough to avoid it.
This code should work better:
Code:bool ReadLine(FILE* f, char* pBuffer, size_t nSize); void Help() { FILE* f; int lines = 0; char Buffer[10000]; if (fopen_s(&f, "C:\\test.txt", "r") != 0) /* f = fopen("C:\\test.txt", "r"); if (f == NULL) */ { // ERROR: Failed to open file. printf("Failed to open file!"); return; } if ( ReadLine(f, Buffer, sizeof(Buffer)) ) { while ( ReadLine(f, Buffer, sizeof(Buffer)) ) lines++; lines += 2; } } int ReadLine(FILE* f, char* pBuffer, size_t nSize) { do { if (fgets(pBuffer, nSize, f) == NULL) return 0; } while (pBuffer[strlen(pBuffer) - 1] != '\n'); return 1; }
Oh, yes. If Microsoft says it, it must be true.
OK, so let me rephrase:
There's reason enough to avoid it in Visual Studio, since it will be removed in future versions of Visual Studio.
And I don't see what's wrong with using fopen_s instead of fopen if fopen_s is a newer function. Even if it isn't more secure, at least it returns the error instead of having you to check doserr or whatever they're called.
Wrong again.
http://msdn2.microsoft.com/en-us/lib...kh(VS.80).aspx
It should be noted that in this context, "deprecated" just means that a function's use is not recommended; it does not indicate that the function is scheduled to be removed from the CRT.Portability?
Besides, how hard is it to check errno?
OK, so that goes to show that Microsoft is good at confusing people. I agree.
As I told you, it's not difficult to do defines or wrappers to "emulate" the safe functions and wrap them to the plain, old functions.Portability?
Besides, how hard is it to check errno?
It's much harder to do it the other way around.
Where are you getting the list you need to load into memory? OR When are you adding to the list?
You could create a function that mallocs a new array of the first array's size +1, then copy the old array over right before freeing it.
You can get the size where size_of_array = (sizeof array)/(sizeof array[0]);
I have no idea how to write all the integers into the malloc'd space.
I almost always define _CRT_SECURE_NO_WARNINGS to get rid of those annoying deprecated warnings. For those functions that VC++ broke by renaming them (with a '_' at the front), I just use a #define to restore their proper names.
I prefer my programs to be compilable (or at least easy to port) on UNIX, even when I don't have any immediate plans to compile it on UNIX.
It's a shame not to use safe functions if they're available. Why not use them if you have them? They were designed for a reason - to avoid some very common mistakes.
Because they're not portable, it's Microsoft's ideology that they're the leaders of setting standards (in this case they're trying to peel back the current ones).
Microsoft 'secure' CRT functions, please don't make me laugh.
Last edited by zacs7; 12-25-2007 at 06:00 PM.
