sscanf - how Im suppose to use it for that?

Started by
26 comments, last by MaulingMonkey 14 years ago
Im trying to do this: File_p.getline( Line, 1000 ); sscanf( Line, "%d %c %d %c %d %d %c %d %c %d %d %c %d %c %d", tmpF[0], eatslash, tmpF[1], eatslash, tmpF[2], tmpF[3], eatslash, tmpF[4], eatslash, tmpF[5], tmpF[6], eatslash, tmpF[7], eatslash, tmpF[8] ); Witch is equivalent of this( At least is what I understood about this func): //File_p>>tmpF[0]>>eatslash>>tmpF[1]>>eatslash>>tmpF[2]>>tmpF[3]>>eatslash>>tmpF[4]>>eatslash>>tmpF[5]>>tmpF[6]>>eatslash>>tmpF[7]>>eatslash>>tmpF[8];//get 9 indices But sscanf are puting werid values on my array, is the first time I use it and cant figure out whats going on. Thats what a line gets: 1/1/1 2/2/2 3/3/3 3/3/3 2/2/2 4/4/4 It is not getting neither the first value correctly.
Advertisement
Nevermind, I just forgot to put '&' on the variables..

BTW I think is good to point that sscanf is a million times faster than '>>' as I guessed:

ms sscanf(release, x64):
56.254868
52.737598
54.236492
53.433758
53.610428

ms ifstream >>(release, x64)
95.837546
94.708611
93.654243
92.235176
93.818764



If you are using "eatslash" just to ignore it (as it seems) sscanf has an interesting feature to parse something but just ignore it.

Check out the "%*" syntax, I use often for strings "%*s" and it should make parsing faster too. Let us know timings :)
Two bits of advice:
1) Avoid std::istream::getline in favour of std::getline since the later function works with an std::string (avoiding raw char arrays with all the problems that produces).
2) Use std::istringstream rather than sscanf.
Since you're using C++, you shouldn't be using sscanf, as others have said.

Personally, I'd rather someone repeatedly jumped on my balls than made me use sscanf.
ms sscanf with %*c(release, x64)
54.890099
54.492992
54.398979
52.433685
52.738811

Thats what I changed, much cleaner! but didnt change much the performance
sscanf( Line, " %d %*c %d %*c %d %d %*c %d %*c %d %d %*c %d %*c %d", &tmpF[0], &tmpF[1], &tmpF[2], &tmpF[3], &tmpF[4], &tmpF[5], &tmpF[6], &tmpF[7], &tmpF[8] );
Im about to kill myself trying to figure out the best way to work with files, any advice you can give me will be so much appreciated that I will mary you..

The first thing I figured out is that Im better using windows api to open and read the file( since( as pointed on windows internals book) c++ routines at some point call those(createfile, read/writefile))

What I was thinkig was loading the entire file to an array( since is what readfile does) and work just on the array..in my mind I think this is problay the fastest(just a guess)...I didnt follow my own guess because I suck, I dont know any array/string manipulation funcs to give me the freedom I want to do stuff...so I went back to the fstream stuff witch I never really liked(witch I also dont know a damn, but at least am more used to...)

Im considering a few things now, using c++ string stuff, using c to manipulate array, or use my damn arms and create my own funcs to traversee the array and doing the stuff I will need( like finding new lines and stuff )

You can think anything, but damn, maya load these files on ridiculous blink of eyes, my code get on a situation that looks is stucked on a infinite loop, but actually is just still working, how they do that?? Lack of knowledge is killing me..

Whats the problem on using sscanf if its faster btw?



Actually Im not understanding a crazy situation(at debuging looks fine, everything works as suppose), my app start consumes all my ram(4GB)! also the mouse get slow, and I need to ctrl+alt+del to close it..and that happens loading a file of 229KB! Any idea why this happens? Is this because std::vectors are actually terrible and Im better making the damn wheel that everyone loves to flame...
-___- yes, Im desperate(and my english sucks)
string-to-int and int-to-string benchmarks.

To make it is hell. To fail is divine.

You can do like that too:

sscanf(line, "%d/%d/%d %d/%d/%d %d/%d/%d", &tmp[0], &tmp[1], &tmp[2], &tmp[3], &tmp[4], &tmp[5], &tmp[6], &tmp[7], &tmp[8]);
"string-to-int and int-to-string benchmarks."

Reinventors of the wheel FTW

This topic is closed to new replies.

Advertisement