On Apr 2, 12:46 pm, "arnuld" <geek.arn...@gmail.comwrote:
On Apr 2, 12:43 pm, "Alf P. Steinbach" <a...@start.nowrote:
This looks good. I'd add an extra 'const', "const char* const arr[]",
but that's it.
const char* const arr[];
says:
"elements of the array can not be modified and array itself can not"
Not quite. The array contains pointers. The first const says
that what these pointers point to cannot be modified. (Sort of.
More exactly, it says that it cannot be modified through this
pointer without an explicit cast.) The second const says that
the pointer itself cannot be modified, to point to something
else.
Formally, an array is never const. But it's elements can be
const, which comes out to pretty much the same thing.
IIRC, you can not modify an array at all.
What makes you think that? You cannot modify the topology of
the array (dimensions, etc.), but you can certainly modify the
contents. Like Alf, I use both const in this sort of
expression, to ensure that nothing gets modified.
so i think we do not need the extra "const".
You never need it (except on reference arguments, if you want to
pass temporaries to them). On the other hand, it offers a fair
degree of protection, and very good documentation. I'd use it.
Some people may comment on the use of 'unsigned' for the
loop variable, because 'unsigned' can become problematic for a loop that
counts down; however, with e.g. std::vector there are good reasons to
use std::size_t for the loop variable, and that's an unsigned type too.
yes, otherwise, i get a warning saying something like: matching of an
unsigned type with a signed type.
Well, it's just a warning:-). But it is there for a reason.
Mixed signedness can sometimes have some very strange results.
As a general rule, of course, unless there is some reason for
doing otherwise (and interfacing with an externally imposed
interface which uses unsigned types is a good reason), stick
with int.
This also looks mainly good. Improvement: in order to get warnings
about some (real nasty) problems you need to add the "-O" (optimize)
option, or some other optimization.
this i what gcc says about "-0":
I think that Alf's point was that certain types of errors are
only detectable if the compiler does some flow analysis, and
that g++ (and most other compilers) only do flow analysis if
optimization is turned on.
It's an interesting point of view. Because optimizers are less
robust than normal code generators, I avoid optimization in
production code unless I need it. On the other hand, Alf is
right that there are a number of potential errors (e.g. using an
uninitialized variable) which a compiler can only find if it
does some optimization. So I guess the rule should be to use
optimization in debug builds, but to turn it off in production
builds.
[...]
my friends has VC++ which does not even recognise
"#include<iostream>". it always demands a ".h" in the end. don't know
which version he is using
It must be a very old one; I think <iostreamwas already
present in VC++ 5.0, and it was certainly present in 6.0 (which
is what, 10 years old now?).
Note that VC++ was one of the few compilers which handled the
transition gracefully, and offered two different
implementations. Maybe the reason your friends don't use
<iostreamis that some of there code counts on the behavior of
the classical iostream, and either doesn't compile or has the
wrong behavior if they include <iostream>.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
