Re: A few questions on C++
On Sep 19, 3:10 pm, "Phlip" <phlip...@yahoo.com> wrote:
D. Susman wrote:
1) Should one prefer short / long to int in favour of better
compability? Does the sizeof(int) still vary dramatically between
platforms?
Use int, and (per a recent thread here) if you are not
portable, don't waste time pretending you are portable. If
your boss requests portability, actually run and test on
multiple platforms as you code.
More to the point, define portable. Formally, the C++ standard
requires an int to be at least 16 bits, no more. Practically,
if you're targeting general purpose computers, you can count on
32 bits; I think the risk of seeing less today is negligible,
except in embedded systems.
And don't program assuming a specific size. If you need a
specific size for some reason, use the C types defined in
<stdint.h> (which will be part of the next version of the C++
standard, and should be supported by most compilers today).
Your question contains the latent assumption that you can
never change your code once its 'int's are installed. If you
instead write lots of unit tests, they will check things like
the maximum values for your important numbers, and they will
help you change your variable types when the time comes.
I don't think it's that simple. You probably don't want to
change all of your int's; just those which are used for specific
values. Which means you have to identify what each int is used
for, to decide whether to change it or not.
Ideally, there would be a typedef for each different use of int,
and you'd only have to change the appropriate typedef.
Practically, I don't think I've ever seen that much rigor.
Your remaining int awareness invests in writing tests that
check your program's boundaries.
The first thing you have to do is determine the limits.
Typically, a user won't specify a specific limit; he'll just say
"as big as possible". If pushed, he'll come out with some large
round figure, like 1,000,000; that doesn't mean that he
wants you to reject input of 1,000,001, however. The usual
solution is to consider what you do with the input, determine
the actual limits, and verify those, rejecting input which you
cannot handle. Thus, for example, if you multiply some input by
2, you'll check that it is less than INT_MAX/2, and output an
error message if it isn't.
And you should also test this in your test suite: test the
maximum you can handle, to verify that you get correct results
with it, and test one more than the maximum, to verify that you
get the error message, and not wrong results. This is difficult
to do with black box testing, although some sort of binary
search could be used. (Test input larger than INT_MAX, to
ensure that it causes an error. Then test INT_MAX/2: it should
either return the correct results, or there should be an error
message. If it returns the correct results, try adding
INT_MAX/4; if it returns an error message, try subtracting
INT_MAX/4. At some point, you should end up at a place where
one value returns the correct results, and adding one to it
causes the error message. I don't know of any test framework
which has support for this sort of test, however.)
2)Should one check a pointer for NULL before deleting it?
No, you should use a smart pointer that wraps all such checks
up for you.
Why? What does a smart pointer buy you, if all it does is an
unnecessary test?
Don't forget, too, that most delete's are in fact "delete this".
And "this" cannot be a smart pointer.
Next, the line delete(int*)NULL is well-formed and
well-defined to do nothing.
Exactly. So there's no need in the test.
(And note you should use a C++ style cast, in the form
"elaborate_cast<int*>", instead of a simple (int*).)
Although deleting a NULL pointer is said to be safe in C++,
I see a lot of code doing the check before deletion. Is this
because they still preserve the C attitude?
It's because they don't fold duplication up into smart
pointers. _That_ is preserving the C attitude.
It's because they don't know the rules of the language. And it
has nothing to do with a C attitude, since the rules are exactly
the same for free(), in C.
3) When is a struct favourable over a class?
When you need a data bucket that is itself private to an outer class.
When you need a data bucket, period. I agree that it will
usually be private to an outer class, but there are exceptions.
There are also special cases: I'd guess that most of my POD
classes are used to allow static initialization (and thus avoid
order of initialization issues).
And of course, the choice of the keyword (struct or class) when
defining a class is purely a matter of convention. My own rule
is that I use struct if the class contains at least one data
member, and all data members are public. I've seen or heard of
at least two other conventions, however: struct is used if the
class contains *only* public data, and nothing else, and struct
is used if the class contains only public members, and nothing
else. (Note that this last rule results in a lot of "interface"
classes being defined with the keyword struct.)
As with most conventions, the important thing is to choose one,
and be consistent.
4) Should one favor '++iterator' over 'iterator++'? I did some
performance tests myself and did not see a big gap between their
execution times ( by using containers with size 10000000 which contain
objects )
Favor ++it for almost exactly that reason. Specifically, if it
is a raw pointer the pre- and post-increments will be nearly
the same speed. But if you upgrade it into a big object, the
it++ form will create a new object, copy it, and throw it
away. The compiler might not be able to optimize this away.
This from you? I thought you believed in testing:-). Have you
ever seen an actual case where the choice made a significant
difference in program runtime? ("Significant", here, means that
using one, the program did not meet its performance
requirements, and using the other, it did.) All of the tests
I've done indicate that it makes absolutely no difference, and
that the choice is purely arbitrary.
Just to shut people up, I'll use prefix on a green fields
project. But I won't bother to change if existing code uses
postfix.
Now use /el Goog/ and look up "premature optimization". When
you learn C++ you should start by learning clean code and good
design, and don't worry about performance until you find a
real need.
Exactly.
Note here that the original poster is doing exactly what he
should. He was probably told by someone that it made a
difference, but given the well established fact that programmers
are always wrong about what makes a difference, except when
they've actually measured, he tested the assumption. And found
it wrong. All I can say is that his experience corresponds to
mine. (What can make a difference, on the other hand, is saving
end() in a variable, rather than calling the function each time
in the loop. Apparently, even when inlined, compilers have
problems detecting that the function will return the same value
each time, so they reread it from memory, rather than using a
value cached in a register.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34