gcc 4.3.1 has some new warnings.
1. strange forward declarations...
e.g.
"class foo::bar;"
fix is
namespace foo
{
class bar;
}
2. suspicious ";" placement in for/while loops
e.g.
for (i = 0; i < 10; ++i);
{
//do something
}
fix is either...
for (i = 0; i < 10; ++i)
{
//do something
}
or, if it is intentional, introduce some white-space to silence gcc,
e.g. from
for (int nCount = 0; nCount++ != nIndex; ++nCount, ++p);
to
for (int nCount = 0; nCount++ != nIndex; ++nCount, ++p) ;
FWIW, I've filed individual bugs for all the loops that are probably
wrong.
3. const placement checking.
some const examples.
class foo
{
public:
static void foo(); //3.1
const void foo(); //3.2
int foo() { return 10; } const //3.3
int foo() const { return 10; } //3.4
int foo() const; //3.5
const int foo(); //3.6
const int foo() const; //3.7
};
So, while static at the start of a declaration like 3.1 makes the
function static, a const at the start of a declaration instead qualifies
the type following it, so 3.2 says we're returning a "const void",
whatever such a thing might be.
So 3.2 is meaningless, it should be void foo(); or the intention might
have been to declare that the method was const, in which case it would
be void foo() const;
3.3. is another pattern occasionally seen in OOo, i.e. the const has
been placed after {} of an inline. What happens here is that the const
is applied to the beginning of the next line. The intention is most
likely to have been 3.4.
3.6 const int foo(); here we are saying that we have a non-const method
that returns a "const int". Its *likely* that the intent was that we are
a const method that returns an int. i.e. int foo() const. If the intent
was to return a "const int", see 3.7
3.7. returning a "const int". Specifying a constness on a fundamental
type returned from a method doesn't really mean anything.
i.e.
const int foo();
int apple = foo(); //ok
is perfectly fine, you can't control the callers receiving variables
constness with it, i.e. you're not enforcing
const int apple = foo();
Contrast against if the method was
const int* foo();
then what is pointed to is const, but not the pointer itself i.e.
const int *baz = foo();
baz = somethingelse(); //ok, I can change the pointer.
*baz = 0; //not ok, can't change the contents
int *bar = foo(); //not ok, constness violation
moving on from there, take
int* const foo();
what is returned is a pointer whose contents *can* be changed, and some
meaningless extra constness on the pointer itself is specified.
i.e. we can still do
int *baz = foo(); //ok
i.e.
int * const baz = foo();
is not enforced by such a signature, and
const int * const foo();
only adds extra constness for what is pointed to, so
const int *baz = foo(); //ok
and
const int * const baz = foo();
is not enforced by this.
So, I've a workspace open where I've fixed all of these warnings in the
modules set as warnings_are_errors.
Where the const has no effect I've made the initial assumption that the
intention may have been to make the method const, and if the method is
already const, or is a function rather than a method, or has some other
reason why the method cannot be const, then I've simply dropped the
extra const.
Anyone unhappy with the above described set of changes I intend to
submit under issue 92941 ?
C.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
