Re: Converting CString to Integer
From: Doug Harrison [MVP] (dsh_at_mvps.org)
Date: 10/18/04
- Next message: Doug Harrison [MVP]: "Re: Is there any benchmark about CString(MS) vs string(std)?"
- Previous message: Doug Harrison [MVP]: "Re: Difference between passing as pointer?"
- In reply to: Sergey Kochkarev: "Re: Converting CString to Integer"
- Next in thread: Sergey Kochkarev: "Re: Converting CString to Integer"
- Reply: Sergey Kochkarev: "Re: Converting CString to Integer"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 18 Oct 2004 14:13:09 -0500
Sergey Kochkarev wrote:
>"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message news:<c1tvm0ptvmoa1egqi25k521b1sk6ephjev@4ax.com>...
>>
>> Did you measure it? And as mentioned in my last message, do you have an
>> application which calls it so frequently in such a short time that the
>> "improvement" actually matters?
>
>Well, nobody talks about efficiency.
Actually, the last sentence in my previous message was:
>>Seriously, while efficiency can't be ignored, it's ever more important to
>>have a sense of proportion.
>But getting something better for
>a lower price and with life time guarantee is better, don't you think
>so? Some people don't like japanese cars, some use them and are quit
>happy.
There's an old engineer adage that goes, "Fast, cheap, correct. Pick any
two." You said the code you posted was "much faster", yet you offer no
proof, neither absolute nor relative to some application. Was it "cheap"?
Well, you had to write it, and so you have to maintain it, and you wrote it
non-portably, so I'd say no. Was it "correct"? No, it contained a bad bug.
Now you're talking about "lower price" and "life time guarantees" and
"japanese cars", and I can no longer understand you.
>> Can you find the bug in your function? Hint: You might find it easier to
>> spot if you made it GetMyUnsignedChar and were to see if it can handle all
>> values of unsigned char.
>>
>
>Yes, I can. I test my code before releasing it, don't you?
I know that testing boundary conditions can be tricky, and so that's a good
place to take extra care when writing code and a logical place to look for
mistakes when examining code written by others.
>The code I posted is just an example, it took me 45 seconds to create it and I
>even did not compile it.
You posted some code as an example of why writing your own substitutes for
Standard Library code is "easy", "much faster", and "Error free". I did not
ask you for such an example, so I guess you were trying to "convince" me of
something, and so I'd think you'd take extra care to get it right. You don't
seem to get the irony in the code you posted having a bad bug, which proved
what I've been saying all along. So many people who are quick to write their
own versions of library code because "it isn't efficient" or "I can do it so
much better" end up getting it wrong. BTW, what was the bug?
>> And BTW, what's this magic number 0xFFFFFFFF?
>
>You don't know? It is a hexademical number. I can print it in integer
>and binary form for you - there is no magic. Hex numbers are part of
>C++ standard.
Maybe you're not familiar with common terms, so here you go:
http://jargon.watson-net.com/jargon.asp?w=magic+number
>> Do you know a portable way to get the number you need? How about a portable way to find the largest value of any unsigned type without #including a header file?
>
>Why? I'm not going to make something portable. Anyway, longhorn is
>going to be released in 5+ years, I have enough time.
Really? You're going to remember to check this in 5+ years? More often than
not, when people say "I'll fix it tomorrow" concerning things like this,
which do work for now, those tomorrows add up to weeks, months, and years,
until the issue is either forgotten or buried so deep in a to-do list that
it later surfaces as a bug. It takes an experienced programmer no longer to
use a portable constant than it takes you to write 0xFFFFFFFF, and the first
guy doesn't have to count F's to make sure he wrote the right constant.
>Ok, if you want
>it portable, make it unsigned(-1) and be happy.
Congrats, that's a correct answer. The other correct answers involve using
<limits.h> or <limits>.
>> To follow my hint
>> given earlier, you'll have to change this number.
>>
>
>No, I can't. I cannot delete the previous post, I'm not usegroup
>admin.
That's not what I had in mind, of course.
>A part of documentation:
>
>The return value is 0 (for atoi and _atoi64), 0L (for atol), or 0.0
>(for atof) if the input cannot be converted to a value of that type.
>The return value is undefined in case of overflow.
>
>See the contradiction? The first sentence grants the
>atol("9999999999999999999") to be zero, the second - to be undefined.
>What should I do? Whom should I believe? Only myself.
When you run into ambiguous documentation, a reasonable course is to consult
a higher authority. Elsewhere, you've tried quoting the C++ Standard, so I
know you're aware of standards. If you find the implementation of the
standard function doesn't conform to the standard, you can report it as a
bug, and once you know how it's defined in the standard, you can ask for the
documentation to be tightened up, and you can avoid using it non-portably.
The solution is not in general to throw your hands up, declare the function
unusable, and write your own.
>strtol requires four parameters which I have to prepare beforehand and
>not to make any errors with them. After the function is over, I have
>to check endptr, flags, etc., the whole amount of code is twice as big
>as it could be. And any line can contain errors, which are not easy to
>find because you cannot test all input values. That is the reason it
>is too hard to use strtol.
I showed how to use strtol correctly in an earlier message. If you think
what I posted is more complex than the buggy function you posted, or the
function you would end up with after fixing your bug, you have some strange
ideas about complexity. It's easy to wrap my very simple pseudocode into a
function that does whatever you want WRT error handling. In addition, you
can assume strtol works correctly; if you refuse to, I don't see how you can
use any library code at all, which puts you at the mercy of your own code,
which we've seen is not "Error free", irrespective of what you like to claim
for it. That's not intended to be a slight; it's a statement of fact that
applies to everybody.
>> >Want documentation? Here you are:
>> >GetMyUnsigned converts string into unsigned (32-bit) integer and
>> >returns false if the string does not contain unsigned (32-bit) only.
>>
>> Unfortunately, your function contains a bug and doesn't fulfill that
>> contract.
>
>My function does not contains bugs. Because I did not implement it. It
>is just an example - use it if you want, but don't blame me - we have
>no contract, don't we?
I didn't ask you to post any code. You did that yourself to bolster the
points you're trying to defend, concerning how "easy" and "Error free" it is
to write your own substitutes for library functions. Instead, you
illustrated the things I've been saying and disproved everything you're
trying to prove. And now, you're trying to get out of it by saying the buggy
function you posted and characterized as "much faster than C++ Runtimes. It
does not call other functions. It does what it should do and nothing else.
It does not have atol bug" doesn't contain bugs because it doesn't exist. I
don't know how to respond to that, other than simply to point it out.
>> >About STL. What implementation you mean?
>>
>> Where did I say anything about STL?
>
>You said Standard Library. Which is MSVCRT, isn't it?
STL means "Standard Template Library". Sometimes people use it synonymously
with "C++ Standard Library", but it's only a subset, namely the containers,
iterators, and algorithms part. MSVCRT is a DLL that contains a
multithreaded version of VC's C Standard Library implementation and a bunch
of other stuff. Most of the C++ Standard Library implementation resides
elsewhere.
>> That's a different issue altogether. The functions we're talking about in
>> this thread were standardized 15 years ago.
>
>May be.
Not "May be". "Were".
>My CRT source files are dated by 1998. I'm sure they are not
>standartized.
Then you should throw out everything that comes with your compiler,
including the compiler itself, I guess.
>Sorry, but my customers use XP. Because of MS marketing, not because
>of good sense. Or else who should by something from the one having no
>education and who even started his business from deceiving his first
>customer by selling of something he did not have.
If you want to talk about that, take it to your favorite advocacy group.
This is intended to be a technical forum, and to participate in technical
discussions, it helps to check irrelevant biases at the door.
-- Doug Harrison Microsoft MVP - Visual C++
- Next message: Doug Harrison [MVP]: "Re: Is there any benchmark about CString(MS) vs string(std)?"
- Previous message: Doug Harrison [MVP]: "Re: Difference between passing as pointer?"
- In reply to: Sergey Kochkarev: "Re: Converting CString to Integer"
- Next in thread: Sergey Kochkarev: "Re: Converting CString to Integer"
- Reply: Sergey Kochkarev: "Re: Converting CString to Integer"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
