fgets() vs std::getline() performance
in [C++]
|
From: Carlos Moreno on 16 Sep 2006 17:05 Jeff Koftinoff wrote: > In actual fact on most platforms, giving a 2 Gigabyte file (with no > '\n' in it) will cause the program to crash (with no exception thrown), > precisely because of this feature of dynamically resizing the string to > fit the input with no upper bounds. > > Depending where this code is used, it can be the basis of a security > hole - and in that sense fgets() could be a better solution! Nice!! Don't remember the last time I saw an irony that compares to this one!! In fact, it could first cause the entire machine to almost-irreversibly collapse, then crash the program (memory exhausted, intensive swap memory use, etc.) Carlos -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: crhras on 16 Sep 2006 17:04 > Wow ! I just used two different file IO methods and the performance > difference was huge. I should have mentioned that I'm using Borland Studio 2006 on Windows XP Pro. At this point, I think it might be caused by a flaw in the way getline( ) is implemented by Borland. I am going to post this question at borland.public.cppbuilder.language.cpp and if I discover anything there I'll post it here. Thanks again for everyone's responses. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 17 Sep 2006 06:55 Jeff Koftinoff wrote: > > These two snippets are not comparable: > > 1. std::getline() dynamically resizes the string to fit the input. > <snip> > This is an important feature... However it can be a big > problem that std::getline() function can not be told what > maximum length to allow. > In actual fact on most platforms, giving a 2 Gigabyte file > (with no '\n' in it) will cause the program to crash (with no > exception thrown), precisely because of this feature of > dynamically resizing the string to fit the input with no upper > bounds. If it causes a crash, that's an error in the implementation. Depending on context (and perhaps your interpretation of the standard), it should either cause badbit to be set (and stop inputting), or throw bad_alloc. Of course, if you've got a lot more virtual memory than real, and you haven't set ulimit to limit the size of the data segment, your machine could start thrashing and become effectively unusable long before either of these events occurred. > Depending where this code is used, it can be the basis of a > security hole - and in that sense fgets() could be a better > solution! I agree that a version of the function with a maximum length would be nice. Or simply specifying that extractors respect setw too---that would be useful for a lot of other things as well. But I don't see it really as a security hole, any more than the possibility of any user function to allocate more available memory than it should is. If untrusted users have access to your program, you'll have taken the necessary steps outside the program to prevent DOS due to thrashing. -- James Kanze (Gabi Software) email: kanze.james(a)neuf.fr Conseils en informatique orient?e objet/ Beratung in objektorientierter Datenverarbeitung 9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Maciej Sobczak on 18 Sep 2006 05:17 crhras wrote: > Wow ! I just used two different file IO methods and the performance > difference was huge. You might also want to check the following: http://www.msobczak.com/prog/fastreams/ -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: alex on 18 Sep 2006 05:18
crhras wrote: > Thanks for your response. > I tested your suggestion and it seemed to take about 25% less time. Based > on the results it seems to do the same as adding the line > std::ios::sync_with_stdio(false); which was a suggestion in another post. No. The difference is because std::getline uses std::string to store the data and std::basic_istream<...>::getline does not. Appending a char to the end of a std::string just seems to cost that more than putting the char into location in a plain buffer, since std::string checks it's internal buffer size. I assume that you use 512 for the length of a string not because it's a nice number :), but you have a guarantee that useful data for your porgram will not exceed 511 char's per input line. Alex [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |