Hi there,
sorry for the delay in getting back to you.
This is really odd, I had a problem compiling this with gcc-3.1 and I know at
least one other Gentoo user had the same issues. However, after having
rebuilt my system a number of times it now compiles just fine.
There are still a few known problems with gcc-3.1 on a Gentoo system and I'm
guessing that one of them (broken sandbox) may have been the cause.
Anyway, everything seems fine.
Thanks again for looking into it and I'm very sorry to have bothered you
unnecessarily. My only defence is that this was done so early in the process
that some of the problems that are now known weren't known back then...
Kind regards,
/Lars
On Thu, 30 May 2002 00:57, Rusty Ballinger wrote:
> > > 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
|