[haiku-development] Re: GCC 2.95 and the STL
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 13 Mar 2010 21:21:38 +0100
On 2010-03-13 at 19:49:16 [+0100], Brecht Machiels <brecht@xxxxxxxxxxx> wrote:
> I'm getting stuck building assignfs with GCC 2.95. It builds fine with GCC
> 4.
>
> In file included from /Data/code/haiku/headers/cpp/list:34,
> from
> /Data/code/haiku/src/add-ons/kernel/file_systems/assignfs/A
> ssign.h:10,
> from
> /Data/code/haiku/src/add-ons/kernel/file_systems/assignfs/V
> olume.h:24,
> from
> /Data/code/haiku/src/add-ons/kernel/file_systems/assignfs/N
> ode.cpp:11:
> /Data/code/haiku/headers/cpp/stl_list.h:247: `list' is not a template type
> /Data/code/haiku/headers/cpp/stl_list.h:247: redefinition of `struct list'
> /Data/code/haiku/headers/private/kernel/util/list.h:37: previous definition
> here
>
> I seem to recall reading that namespaces GCC 2.95 can be problematic. Could
> that be related?
I believe there's a "using namespace std;" somewhere which causes this
problem. I don't think there's anything one can do besides avoiding to
include both headers in the same compilation unit.
> Or maybe the STL included with Haiku can use an upgrade?
Nope, it's a nightmare as it is, no need to add binary compatibility problems.
BTW, using the STL (beyond stuff that is fully defined in the headers) for an
FS in not such a good idea, anyway, since you won't be able to use it in the
kernel.
Moreover, std::list uses non-intrusive list-links which require memory
allocations. Since the STL container interfaces usually don't have another
way of reporting failed memory allocations than throwing std::bad_alloc,
using those classes in the kernel is a no-go.
CU, Ingo
Other related posts:
