[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Porting code to Linux, need guidance
From: |
Guy Harrison |
Subject: |
Re: Porting code to Linux, need guidance |
Date: |
Sun, 22 Aug 2004 12:59:59 GMT |
User-agent: |
KNode/0.7.7 |
Kenton Groombridge wrote:
> Hi,
>
> Hopefully this is the right group for this. I am working on getting
> Alien vs Predator completely ported to Linux. I am using the code that
> is available from icculus.org.
It may have been but we can't tell.
> I recently upgraded my gcc to 3.4.1 and now a portion of the code
> doesn't compile.
That may have been relevant. Trouble is, no-one's going to go grab all that
code. You'd have to have whittled it down to a compilable snippet.
> I think I figured it out, but want to be sure before I spend a bunch of
> time working around it only to find that I was wrong.
>
> My guess is the class ConstIterator makes class Iterator a friend, but
> class Iterator is a derived class of the bass class ConstIterator (hope
> I said that right). From what I understand and have researched is that
> in order for the class ConstIterator to use the class Iterator as a
> friend, then class Iterator has to be defined first, and for class
> Iterator to be derived from class ConstIterator, then the class
> ConstIterator has to be defined first. Essentially a catch 22.
This is more comp.lang.c++ where it would be on-topic to expand the topic.
You'd then come back here if it turns out the behaviour is peculiar to g++
(ie possible bug(*)). No reason to think that atm - methinks it's down to
increased conformance by 3.4.1 but as I'm no STL guru I'm in not certain
from your description.
(*)
An instantiation problem (standard doesn't go into details there).
> Am I on the right track? If so I would like to fix the code, but I
> would like to know how you would approach the fix for this.
In theory an iterator is loosely defined (if it behaves like a pointer it is
an iterator) so even though conventional (STL) iterators have
"attributes" (direction, tags and so forth), provided you can reduce the
pertinent errors to a snippet that's compilable by a standard compiler then
for sure comp.lang.c++.