Thread: Moving a file pointer in a function

Since StrStr returns a pointer to the first character in the matched string, you do know exactly where to plop your \0 to terminate the string with only a very slight modification.

My mistake, I misunderstood how strstr was used, and I agree it would make much cleaner code, but I looked at an implementation of strstr and I think that although my solution is not beautiful by any measure it does have less overhead. This operation is - after all - preformed on every single character in the file.

Originally Posted by 127.0.0.1

My mistake, I misunderstood how strstr was used, and I agree it would make much cleaner code, but I looked at an implementation of strstr and I think that although my solution is not beautiful by any measure it does have less overhead. This operation is - after all - preformed on every single character in the file.

That may be true of some poorly implemented libraries. But the distribution libraries supplied with most better compilers are often highly optimized, often using inline Assembly to maximize their performance. So unless you're working with some really brain-dead library, it's very unlikely you will get better performance from self-made function replacements.

But, you should suit yourself... these are your mistakes to make, my friend.

Both implementations are basically O(mn) where m is the length of the data in the file, and n is the length of your comment string. And unless you're developing on an Apple using their standard C library, there's no guarantee that the strstr you're environment provides is the same as Apples. It may be a much more optimized version. In fact, many of the standard library functions are highly optimized for the specific platform they're meant to be used on.

Your attempt to justify this is touting preoptimization. You don't know whether the difference in speed is significant or negligible, or whether it causes some sort of bottle neck. The slowest part of your code is your reading from disk. Everything else is working at ludicrous speed compared to disk I/O. Besides, it's always preferable to use a well tested, existing, standard piece of library code than to invent the wheel. The only exception to that might be for purely academic purposes. In practical code this should be avoided at all costs.

...Besides, it's always preferable to use a well tested, existing, standard piece of library code than to invent the wheel.

..So unless you're working with some really brain-dead library, it's very unlikely you will get better performance from self-made function replacements.

Thanks for the perspective, I think I should study the standard library more so I do these kinds of things less.

Originally Posted by 127.0.0.1

Thanks for the perspective, I think I should study the standard library more so I do these kinds of things less.

May I ask which compiler you're using? (you may have mentioned it before, but I don't recall...)

May I ask which compiler you're using? (you may have mentioned it before, but I don't recall...)

I am using MinGW and Visual Studios

Originally Posted by 127.0.0.1

I am using MinGW and Visual Studios

They're OK compilers ... for a minute there I was afraid you were going to come up with Turbo C or DEVC++... Whew!

However; you should know that MSVS is not a standards based compiler... it's optimized by Microsoft for their own purposes.

Orrrrrr... you could use minGW in C-99 mode checking standards as you program...

I have since I started always used the C-99 switch.

using a non standards based compiler to check compatibility tends to *reduce* not improve portability of code

All of the code I produce is plain ANSI C-99, I only have these two fixes to make Visual Studios read the C-99 code.

Good stuff...

But ... you still gotta learn to think in smaller blobs...

Originally Posted by 127.0.0.1

EDIT: What in your opinion are better compilers? (also - although I use notepad++ with Mingw - I thought Dev C++ was an IDE on top of GCC. Am I wrong?)

Not wrong... However, DEVC++ was abandoned by it's author nearly a decade ago and still distributes with the old compiler. GCC has been through several revisions --and improvements-- since then. Same with Turbo C... it was the next best thing when Fred Flintstone was still wearing diapers and even with a couple of updates it's still a 16 bit DOS based dinosaur... it's output won't even run on 64 bit systems.

In my opinion, if you are doing C-99 standard programming your best bet is currently Pelles C. I say this for several reasons but mostly it's a very complete IDE with excellent documentation and a very tightly integrated compiler. Code::Blocks or Notepad++ and MinGW could give Pelles a run for the money if they had anything resembling Windows resource editors (Menus, Dialogs, String Tables, Message Tables, Accelerators, Manifests, etc) and full library documentation (press F1 on any keyword!).