> > I'm trying to build fam-oss 2.6.7 using Gentoo Linux i386 with
> > gcc3.1 and get the following output:
(Hey, I'm running Gentoo at home, but it only has gcc 2.95.3. That
built fam for kde with no problems.)
> At line 107 of Scheduler.h, struct IOTypeInfo has a member iotype that
> is given a "const" modifier. At line 123, two variables of type
> IOTypeInfo, "read" and "write" are declared.
...
> 1. Is the position of the const modifier correct? I'm accustomed to
> seeing it before the type. Is it possible to put the modifier
> elsewhere in C++?
Putting it before & after the type means two different things; it's the
same in C:
int a, b;
const int * c = &a; /* the value of c can change, but the value
*pointed to* by c is const. This is the
form you usually see, because usually, who
cares if c itself changes? */
int * const d = &a; /* the value of d cannot change (it's const),
but the value *pointed to* by d can change!
This is not what you usually want, which is
why you don't usually see it. */
So, two of the next four lines are allowed, and two are not. If you're
not sure which, your compiler will tell you the answer. :)
c = &b;
*c = 1;
d = &b;
*d = 1;
> 2. Is the IOTypeInfo constructor called when "read" and "write" are
> first declared at line 123?
No, the bit at the top of Scheduler.c++ is where they're defined, and
you can see what's passed to their constructors there. The declaration
in the header just means "somewhere in this program, there's a thing
called Scheduler::IOTypeInfo::iotype, which I will define later."
> If so, then this means they are
> actually instantiated, not declared, correct? If so, then
> presumably calling the constructor at lines 37 and 38 of
> Scheduler.c++ is trying to modify an already initialized const
> member. If so, how can this be overcome (other than removing the
> const modifier, which seems to be a bad idea)? If not, why
> would the error be occurring at all?
Scheduler.h line 107 makes use of C++'s little-known obfuscation operator,
which most books cover in the section on "pointers to members". Pointers
to members are not like the pointers which normal, healthy, well-adjusted
people (you know, like this list's subscribers) usually see. Consider the
declaration:
FDInfo::FDIOHandler FDInfo::*const iotype;
That freakishly weird syntax means that iotype is a const pointer to a
FDInfo::FDIOHandler member of the FDInfo class. It's like an offset
in the *class*; you don't get an FDInfo::FDIOHandler unless you apply
iotype to an FDInfo *object* using the .* or ->* operators. You can see
this where it's used in Scheduler.c++:
IOHandler old_handler = (fp->*(iotype->iotype)).handler;
fp is an FDInfo *, and iotype is an IOTypeInfo *, so iotype->iotype is
the offset of an FDInfo::FDIOHandler within the FDInfo class, and
fp->*(iotype->iotype) gives you an actual FDIOHandler in fp. (handler is
a member of FDIOHandler; its type is IOHandler.) The ->* operator isn't
one you see every day, and thank goodness for that!
Going back to the original problem... I don't see why gcc doesn't like
it. It looks to me like that code is properly initializing iotype; I was
thinking maybe the compiler is complaining that &FDInfo::read and
&FDInfo::write are not known at the point where they're passed into the
constructors & used to initialize iotype, but I don't think that can be
right, as it's already seen the struct FDInfo definition before that
point. There are three open bugs on gcc.gnu.org with "pointer to member",
but none of them look related to this.
--Rusty
--
Source code, list archive, and docs: http://oss.sgi.com/projects/fam/
To unsubscribe: echo unsubscribe fam | mail majordomo@xxxxxxxxxxx
|