Michael Stefaniuc wrote:
Jacek,
I'm not sure about this patch. gcc 3.1.1 produced a warning about a double const. The rules of what is const depending on where in the declaration it is placed are mind bongling (especially at 1am) and I don't know what the intention was here so please review.
-static const REFIID tid_ids[] = { +static REFIID tid_ids[] = { &IID_IHTMLWindow2 };
It would be easier if one were obliged to always put const (and volatile) qualifiers to the right of what they qualify, then the whole declaration would read from right to left. Thus, here,
char const * const *p;
p is a pointer to a constant pointer to a constant char. The almost-universally adopted convention of putting the left-most qualifer on the left of the type it qualifies, as in
const char *ch;
rather than the equivalent
char const *ch;
rather spoils this flow.
Here,
static const REFIID tid_ids[];
could be rewritten
static REFIID const tid_ids[];
And REFIID in a C setting is defined as:
const GUID * __MIDL_CONST (where __MIDL_CONST is "const", if rpcproxy.h has not been included).
So, in case anyone is still awake and interested:
static const REFIID tid_ids[];
is equivalent to
static const GUID *const const tid_ids[]; (Note the erroneous double const.)
or static GUID const *const const tid_ids[];
as I would prefer to put it. So, to conclude, you don't want the extra const, and it may not have been the const you thought it was, either. :)