freepooma-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Freepooma-devel] [RFC] Change domain object default constructor behavio


From: Richard Guenther
Subject: [Freepooma-devel] [RFC] Change domain object default constructor behavior
Date: Wed, 6 Apr 2005 18:05:32 +0200 (CEST)

Hi!

To address possible correctness issues wrt using UninitializedVector
utility class as storage for all our domain types and to address
limitations of compilers alias analysis confused by the casts
introduced by this class, I propose to remove use of this helper
and not ly to the compiler about the element type of f.i. Loc<3>.

To still get non-initialization behavior that was possible due to
using UninitializedVector with a POD element type (int), we need to
either ensure that types like Loc<1> are POD (impossible, I think),
or change the default constructor of our domain objects to _not_
initialize the domain, as opposed to the NoInit variants now.

This _will_ break certain uses of domains in current codes, but
possibly allow much better optimization of Loc<> indices.  This will
also match the behavior of the Tiny classes, which do _not_ initialize
in their default constructors.

Do any of you have ideas on how to avoid this kind of breakage
while retaining the structural improvements?  The problem is that
C++ does not allow array member initializers that affect the whole
array. So, the following does not work:

struct NoInit {};

template <class Bar, int Dim>
struct Foo
{
        Foo() : x(Bar(NoInit())) {}

        Bar x[Dim];
};

struct Bar
{
        Bar(const NoInit&) {}
        Bar() { x = 1; }
        int x;
};

int foo(void)
{
        Foo<Bar, 3> f;
        return f.x[0].x;
}


Thanks for any hints,

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]