strange realization of StrToD()
-
Once I have a long file with ascii text- long row of numbers. I used StrToD() to convert text to array of floating point numbers. I couldn't undrestand, why it works so slowly? Running it under debbugger, I realized what was the problem. This stupid function scanned the whole file, looking for null terminator! I think, there is no reason to scan long text string after set of chars, belonging to the first number has been obtained. Finally I had to write my own realisation of this function.
-
Once I have a long file with ascii text- long row of numbers. I used StrToD() to convert text to array of floating point numbers. I couldn't undrestand, why it works so slowly? Running it under debbugger, I realized what was the problem. This stupid function scanned the whole file, looking for null terminator! I think, there is no reason to scan long text string after set of chars, belonging to the first number has been obtained. Finally I had to write my own realisation of this function.
strtod(that is the 'standard'C++strtod, I never heard aboutStrToD) is not 'strange': it is a function satisfying its own requirements that are clearly explained, for instance here[^]. If it doesn't fit your needs, then, well, the right way is to write your own one (as you did).If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
strtod(that is the 'standard'C++strtod, I never heard aboutStrToD) is not 'strange': it is a function satisfying its own requirements that are clearly explained, for instance here[^]. If it doesn't fit your needs, then, well, the right way is to write your own one (as you did).If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]You are right about lowercase: strtod(const char *nptr, char **endptr) returns floating point value and a pointer to the first char, that stops scanning. It means, that if I have for example such string "12.3 0.07" and give pointer to this string to strtod for eating, it will return me 12.3 and pointer to the next char after '3'. Thats all right, no objections. But name me one reason to scan THE WHOLE string??? Why do not stop scanning after four first chars? It is my non-humble opinion: it typical left-hand approach.
-
You are right about lowercase: strtod(const char *nptr, char **endptr) returns floating point value and a pointer to the first char, that stops scanning. It means, that if I have for example such string "12.3 0.07" and give pointer to this string to strtod for eating, it will return me 12.3 and pointer to the next char after '3'. Thats all right, no objections. But name me one reason to scan THE WHOLE string??? Why do not stop scanning after four first chars? It is my non-humble opinion: it typical left-hand approach.
strtod uses strlen, internally - at least in VS2008. but VS2010 fixes this, reportedly.
-
strtod uses strlen, internally - at least in VS2008. but VS2010 fixes this, reportedly.
I use VS2005. I like it and this example of strange behavior is the only one what I actually met. No matter, build-in assembler lets me write compact and efficient procedures, when and if I have need in extra performance.
-
Once I have a long file with ascii text- long row of numbers. I used StrToD() to convert text to array of floating point numbers. I couldn't undrestand, why it works so slowly? Running it under debbugger, I realized what was the problem. This stupid function scanned the whole file, looking for null terminator! I think, there is no reason to scan long text string after set of chars, belonging to the first number has been obtained. Finally I had to write my own realisation of this function.
Looks like you found a bug.
-
Looks like you found a bug.
I wouldn't say so: procedure works correctly. It is only inefficient realization, no more. I met a real bug in VS 6.0, but now it is of no use to speak about such ancient soft. Sometimes VS2005 asks me for confirmation, when I try to close prog, currently running under debugger, but it happens probably due to old age of my particulat exemplar.
