counting number of lines in my output file

hey guys,

im trying to use malloc and realloc in my programme, as the sizes of my arrays change with some parameters in my program.But to use them i need to calculate the number of lines that I will have in my output file in the end, so that i can allocate the right amount of memory.But how could i go about writing the code for calculating the number of lines.

in my output file, the first line lists some constants..so thats line number 1..then underneath i have two colums of time against x(t) which are both arrays..

Merry Christmass!!
xx

Open file for sequential reading (see fopen for more information) and read line-by-line and count until you reach the end.

If your lines are all exactly the same length, you can get the file size, then divide by the line length, but most files use variable length lines, so you'll probably have to do what Elysia suggested.

heyy, thanx for the replies but i wanted to write it into my program a short piece of code that would calculate the number of lines in my output file, which varies all the time, say 'n' to then allocate the right amount of memory using malloc

for e.g

x = (float*)malloc(n*sizeof(float)) where x is my pointer to the array

opening the file and reading the number of lines myself would not be of any use,as i need to know it beforehand to allocate the required memory. I read somewhere something like

while(fprintf(output, "%f", &x) ==1) n++;

but dont really understand that properly.

Quote:

---

Originally Posted by zesty

opening the file and reading the number of lines myself would not be of any use,as i need to know it beforehand to allocate the required memory. I read somewhere something like

---

No, you don't. Just use a sizeable array of say 10k or so and read line-by-line to find out how many lines there are.
If you just need to find the size, you can just open it, seek to the end (fseek) and retrieve the file pointer position (ftell).
There's nothing preventing you from reading the file and deciding how much memory to allocate before reading it into memory at a later time.

Alternatively, you can use a dynamic array - extend your array size as it needs to grow (realloc).

Why not malloc() a reasonable size to start, then realloc() if you need to make it bigger...?

Code:

---

int c, lines = 0;
FILE *f;

...

/* Assume f points to a valid FILE opened for reading... */

while((c = fgetc(f)) != EOF)
{
    if(c == '\n')
    {
        lines++;
    }
}

---

Easier than you may think.

But also more inefficient than reading line-by-line with fgets.

Code:

---

int lines = 0;
char buffer[10000];
FILE *f;

...

/* Assume f points to a valid FILE opened for reading... */

while( fgets(buffer, sizeof(Buffer), f) )
{
        lines++;
}

---

But more accurate then using fgets without checking for '\n' in the returned string.
No matter how big you make the buffer, there might be a line that is longer then that.
Kurt

I'd say that's coming close to abusing the size of variables on the stack :) -- also I'm pretty sure fgets() would do something similar to MacGyver's code ;)

It also means if a line is larger than 10,000 bytes you'll get incorrect results, perhaps the fastest way is (by far not the most efficient):

Code:

---

* seek the end of the file
* find out how many bytes you are from the start (ie how big the file is)
* allocate a buffer big enough to hold the file
* read in the file into the buffer
* loop through the buffer char-by-char looking for new lines (while keeping a running total)
* free the buffer

---

Well, if you're concerned about stack space, you can always allocate on the heap.
fgets is also supposed to return a char*, but msdn docs never say what it returns if there's not an error. I'm thinking you can find out whether fgets was able to read an entire line or not.

You said so yourself that you don't like supporting IE because it's not standards compliant. Hence don't use the MSDN docs for standard C -- they seem to 'miss-label' things (ie POSIX compliant functions), or totally forget to mention things.

Quote:

---

Originally Posted by man fgets (3)

Upon successful completion, fgets() and gets() return a pointer to the
string.

---

In other words, NULL on failure else the string.

Quote:

---

Originally Posted by man fgets (3)

The fgets() function reads at most one less than the number of characters
specified by n from the given stream and stores them in the string s.
Reading stops when a newline character is found, at end-of-file or error.
The newline, if any, is retained. If any characters are read and there
is no error, a `\0' character is appended to end the string.

---

They suffice well enough. Despite severals flaws, they do describe the functions.
I wouldn't recommend it 100% to newbies, but it will suffice since it's the only doc I have offline.
But in case it returns a pointer to the string, then all you have to do is:

Code:

---

int lines = 0;
char buffer[10000];
FILE *f;

/* Assume f points to a valid FILE opened for reading... */

while( fgets(buffer, sizeof(Buffer), f) )
{
        /* Only increment lines if fgets read an entire line, otherwise continue reading the line */
        if ( Buffer[ strlen(Buffer) ] == '\n' )
                lines++;
}

---

Or...

Code:

---

if(strchr(ret, '\n') != NULL)
    lines++;

---

Don't forget, fgets() stops at a newline, so there's never going to be a newline in the string other than at the end :)

Indeed, so if there isn't a newline, the entire line was not read.

But consider the following:

Code:

---

line1\n
line2\n
line3

---

You'd now report there was 2 lines, incorrect -- there's 3.

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++;

---

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.

Quote:

---

Originally Posted by ZuK

Wrong. You'd report 1 line for an empty file.
Kurt

---

Hmmm. Additional logic is required.

Quote:

---

Originally Posted by zacs7

Not to mention you're using sick twisted Microsoft renamed functions.

fopen_s, ewwwww.

---

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.

Quote:

---

Originally Posted by Elysia

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?

Quote:

---

Originally Posted by MacGyver

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;
}

---

Quote:

---

Originally Posted by Elysia

Besides, fopen is deprecated (in Visual Studio 2005/2008!). That's reason enough to avoid it.

---

:rolleyes:

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.

Quote:

---

Originally Posted by Elysia

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.

---

Wrong again. ;)

http://msdn2.microsoft.com/en-us/lib...kh(VS.80).aspx

Quote:

---

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.

---

Quote:

---

Originally Posted by Elysia

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.

---

Portability?

Besides, how hard is it to check errno?

Quote:

---

Originally Posted by MacGyver

Wrong again. ;)

http://msdn2.microsoft.com/en-us/lib...kh(VS.80).aspx

---

OK, so that goes to show that Microsoft is good at confusing people. I agree.

Quote:

---

Portability?

Besides, how hard is it to check errno?

---

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.
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.

Quote:

---

Originally Posted by Elysia

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.

---

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.

Quote:

---

Originally Posted by Elysia

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.

---

If they were standard functions, I might use them. But for most of those "secure" functions, I can't see why they would be more secure than the standard C functions, assuming you're not a sloppy programmer.

Irregardless if it's a Microsoft prank or whatever - they're safer than normal CRT functions and they're easy to do away with if you need portability.

Quote:

---

Originally Posted by cpjust

If they were standard functions, I might use them. But for most of those "secure" functions, I can't see why they would be more secure than the standard C functions, assuming you're not a sloppy programmer.

---

Plus, they can help you find bugs, especially when you write complicated code and pass a destination buffer not large enough to hold the data.
Portability isn't an issue if you understand what you're doing. Usong Windows APIs and such is non-portable since they must be completely re-written, but "secure" functions only needs a wrapper or a define to wrap them to standard functions, so there's no issue here.

If it's Microsoft only, then they have done us a great service in at least trying to provide a better runtime library without breaking too much code. I don't blame them and I certainly don't mind using them.

They're dumb...

Quote:

---

Originally Posted by msnd pointlessness

For example, the strcpy function has no way of telling if the string that it is copying is too big for its destination buffer. However, its secure counterpart, strcpy_s, takes the size of the buffer as a parameter, so it can determine if a buffer overrun will occur.

---

Er... use strncpy()...

They don't seem to be more 'secure', in fact they're merely n00b-friendly CRT functions. They even 'fix' gets() so you can use it 'safely'. Pfft, it's been established for a long time that they're unsafe and use the other CRT functions which already solve the problem (eg, gets() -> fgets(), strcpy() -> strncpy(), etc). M$ has done nothing but launched an attempt to break portability a bit more.

And as I said before, strcpy() is safe if you're not careless. ;)

malloc() the buffer for what you need and guarentee the size will match. Otherwise, use static buffers, but make sure your static buffer being copied into is large enough to handle the entire buffer coming in. Bingo. Your buffer is large enough.

Even the MS 'secure' functions can be insecure if you don't know how to use them properly. Just pass in the wrong size for a buffer size and boom!
I avoid C like the plague, so I usually don't need to use those functions, but when I do use them, I read the docs thoroughly. The reason why they can be insecure is because people don't pay enough attention to the docs.