Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

getline() works for (single) character delimited reads and lets you use a std::string. The latter is reason enough to use it: it means you don't have to worry about manual dynamic memory allocation and have zero risk of overflows.

In any case, the C++ equivalent to fgets is sgetn on the underlying streambuf or filebuf - http://en.cppreference.com/w/cpp/io/basic_streambuf/sgetn . I'd use this before I used fgets, if for no other reason than I then don't have to remember to call fclose()

The fact that you haven't used one of the most trivial functions in the standard library because of a slight performance penalty 15 years ago is worrying.



What are you worried about? An order of magnitude is not a slight performance penalty. The C++ standard library is vast and we've had c++98, c++03 and c++11 in the 15 or so years. There's few enough parts of it that you'll revisit regularly. You can't go around expecting people to be experts in the minutiae of all of it.


If both the C++ and the Perl code had the same performance I'd stick with the Perl version.


Slight? It would turn a 10-min run into over 2 hours.


Well its not wise to guess about why you experienced this problem. A proper investigation would require a testcase that recaptures it.

My hunch would be that you was discarding the std::string between lines (thereby not reusing the buffer and causing additional memory allocation for each line)... but I'm not sure even that would cause a 12 fold slowdown.


Nope. I doubt I did that, but even if I did, it couldn't explain the slowdown. Sometimes I needed to hold the netlist in memory (as a graph), and thus allocated space for every line anyways. (Actually, up to five times for each line: data structure, device name, source name, drain name, gate name.) Unless I ran out of memory, this never caused a significant slowdown.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: