Re: A few questions on C++
On Sep 19, 3:04 pm, Neelesh Bodas <neelesh.bo...@gmail.com> wrote:
On Sep 19, 5:46 pm, "D. Susman" <derya.sus...@gmail.com> wrote:
1) Should one prefer short / long to int in favour of better
compability? Does the sizeof(int) still vary dramatically between
platforms?
sizeof(int) is implementation-defined and hence no conclusions
can be drawn (rather, it is incorrect to draw any conclusions)
regarding whether it varies across platforms and/or
implementations.
It depends. Formally, the standard guarantees that an int has
at least 16 bits. In practice, it depends on the type of
platform you're targetting; for general purpose machines, you
can pretty much count on 32 bits today.
And of course, short and long have no more guarantees. From the
standard, a short is at least 16 bits, and a long 32; on general
purpose machines, however, only long really varies: 32 bits on
older systems, 64 on more recent ones (or when compiling in 32
bit mode).
There are, of course, exceptions. I expect that some embedded
processors still have 16 bit int's, and at least one mainframe
has 36 bit int's (and 1's complement).
2)Should one check a pointer for NULL before deleting it? 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?
According to the C++ standard, deleting a NULL pointer is
safe. So it is not mandatory to test the pointer for NULL
before deleting it.
And the C standard says that you can safely call free with a
null pointer as well. This may not have worked with some early,
pre-standard C compilers, but I can't imagine it being a problem
today. (I stopped testing for null some time around 1993 or
1994, and I've never encountered any problems.)
[...]
3) When is a struct favourable over a class?
If you have all public members and you want to avoid writing
"public" access specifier in the definition:
It's a question of coding guidelines, really. My rule is
generally to use struct if the class has data members, and all
of them are public, and to use class otherwise. Other people
have other rules, however, and they aren't necessarily wrong
either.
[...]
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 )
Preincrements are generally faster than postincrements since
postincrements need to make a copy before doing an increment. No such
copy-construction is necessary for pre-increment.
Have you actually measured the difference? I did, and found no
measurable difference. Obviously, you can design an iterator so
that there will be a difference, but such iterators will
probably cause performance problems elsewhere anyway---the STL
expects iterators to be cheap to copy.
About the most you can say is that it is almost certain that
pre-increment won't be slower than post-increment. So if all
other things are equal, why not use pre-increment. Except, of
course, that all other things rarely are equal---most of us have
to deal with existing code, and in such cases, it is decidedly
better to follow whatever conventions it uses, rather than to
worry about non-existant performance problems.
--
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