Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Absolution

Quick string question

This topic is 6014 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

What is the best way to read individual characters from a file and append them to a null-terminated string (i.e. build up a string as you go). Or, what is the best way to read a 0 terminated string from a file? Abs

Share this post


Link to post
Share on other sites
Advertisement
You can also use fstream.getLine() function. It reads in a line and inserts into a char array, which you can then manipulate.

---
Make it work.
Make it fast.

"Commmmpuuuuterrrr.." --Scotty Star Trek IV:The Voyage Home

Share this post


Link to post
Share on other sites
All good suggestions. "Best" depends on what you are looking for. There is a time vs complexity tradeoff. fread is fastest, reading arbitrarily-sized blocks of data; fgets reads up to a newline (text files only); fscanf reads and parses data, and is the slowest. If speed is paramount, then use fread and interpret the data yourself. If speed is not an issue, fscanf requires the least amount of supporting code.

If absolute speed is very important, stay away from the C++ I/O classes. They are from 10%-60% slower than their C counterparts.

Share this post


Link to post
Share on other sites
quote:
Original post by OldGuy
If absolute speed is very important, stay away from the C++ I/O classes. They are from 10%-60% slower than their C counterparts.

Simply not true. The truth is that many well-established C programmers simply have not wrapped their heads around C++ I/O stream classes. In a functionality/efficiency tradeoff, the difference between Standard C I/O functions and C++ stream I/O is marginal at best - certainly not the 10 - 60% picture you paint.

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
The advantage of the C++ I/O routines is that they provide a higher level abstraction on top of the low level I/O routines. They are easier to use, handle more file/data types transparently, and better fit the OO model.

The advantage of the C I/O routines is that they are closer to the OS-specific layer. They do not have any object overhead, and are faster in almost every circumstance. Their downside is that they are harder to use.

If the I/O portion of your code is small, then I agree that the difference is neglibable. However, for programs that read and write a lot of data, I stand by my 10-60% difference.

Being religious about anything, even C++, can blind you to the realities of the everyday tradeoffs in programming.

Share this post


Link to post
Share on other sites
quote:
Original post by OldGuy
The advantage of the C I/O routines is that they are closer to the OS-specific layer. They do not have any object overhead, and are faster in almost every circumstance. Their downside is that they are harder to use.

The truth about the C++ I/O stream classes is that they also have low-level, unformatted functions (get, put, read, write) which essentially mirror the C fread, fwrite, fputs, fgets, fputc, fgetc functions. I conceded that the C functions are slightly more efficient, but I contine to contend the 10-60% assertion.

Being religious about anything, even C, can blind you to the realities of the everyday tradeoffs in programming.

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
So, we agree that using the right tool at the right time is best.

I was manager for a 300,000 line C++ project in the area of distributed databases. It used remote batches for data synchronization, and could involve many users and transactions. When we profiled the code, we found a large amount of time in the I/O routines. When we rewrote the key portion in ''C'' I/O routines, we improved throughput by between 40% and 60%, depending on data. MSVC++ 6.0.

When you program in the real world, you can''t afford to be too dogmatic.

Share this post


Link to post
Share on other sites
quote:
Original post by OldGuy
So, we agree that using the right tool at the right time is best.

Absolutely. I agreed with and confirmed your general assertion from the get-go; I just objected to the figures.

quote:
I was manager for a 300,000 line C++ project in the area of distributed databases. It used remote batches for data synchronization, and could involve many users and transactions. When we profiled the code, we found a large amount of time in the I/O routines. When we rewrote the key portion in ''C'' I/O routines, we improved throughput by between 40% and 60%, depending on data. MSVC++ 6.0.

Totally. C++ is still not optimum for truly low-level applications (eg system-level components); it''s one of the things that is being discussed for C++0x.

quote:
When you program in the real world, you can''t afford to be too dogmatic.

True dat!

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
I love it when a simple two sentence questions spawns a heated debate. I am writing a 3DS loader btw and it wasn''t too difficult to get one that works. Now I want one that works quickly. I am writing an RTS so the plan is to export my models in 3DS format and load them into a custom tool that sets up the correct ortho-projection, lighting, etc... and then renders them from all views and spits out a custom formatted bitmap (instead of going into PS and cutting/pasting/pixel level editing). Fun stuff! Now, if I can add a little keyframer to it I could automate the entire process.

Abs

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!