[haiku-development] Re: Lock/Thread private includes problem
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 07 May 2012 22:58:59 +0200
Julian Harnath wrote:
> Ingo Weinhold <ingo_weinhold@xxxxxx> schrieb:
> > <thread.h> includes <thread_types.h> which in turn includes <lock.h>
> > (since locking primitives are used in the thread related structures).
> So by including <thread.h> (or just <thread_types.h>) you get an include
> cycle.
>
> I noticed the cycle but hoped there would be some way out... and there
> is still one thing that confuses me. It is of no pratical use, more a
> technical detail: if I add #include <thread.h> at the *end* of lock.h,
> it still produces lots of errors. Why does that happen? Including it at
> the end is of course not useful, but when doing that, a later-included
> thread_types.h should be able to see everything from lock.h, right?
> Anyone have an idea?
Since more than two headers are involved you can still get the same effects.
E.g. let the current include chain be a -> b -> c. If you change c to include a
at its end, for a source file including b the preprocessor will read b -> c ->
a -> b. Since b is guarded, this will result in preprocessed output a'c'b',
which will fail to compile due to a' referring to definitions/declarations of
b'.
> The function I need in lock.h is thread_get_current_thread() which is a
> macro that points to various arch-dependent inline functions, so pretty
> much the worst-case here ;-) ... forward-declarations don't help and
> pulling the inline functions into separate header-files for every arch
> is a little more change than I want to do.
It probably isn't necessary. I don't think the architecture specific thread
headers include anthing that would be part of the cycle, so I wouldn't split
them unnecessarily. Also, it might not be necessary to split both <lock.h> and
<thread.h>. I would only split them on an as-needed basis.
> So either I revert some of
> my changes and go without using that function, or I add another new
> function somewhere (maybe in a new file) that simply wraps around
> thread_get_current_thread().
Please don't. Adding a work-around for such an issue is not a good solution.
CU, Ingo
Other related posts:
