This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR C++/9021 and 11005
- From: Danny Smith <danny_r_smith_2001 at yahoo dot co dot nz>
- To: Jason Merrill <jason at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 11 Dec 2003 21:59:29 +1100 (EST)
- Subject: Re: [PATCH] Fix PR C++/9021 and 11005
--- Jason Merrill <jason@redhat.com> wrote: > Hmm, I'm not sure this is right,
either. Do we really want to allow people
> to keep adding attributes to a class?
>
> I think it probably makes sense to use your patch, but make it conditional
> on whether or not the class is complete; if it is, then specifying
> additional attributes is an error.
>
> Thoughts?
>
Maybe. This rule:
"If !COMPLETE_TYPE_P, merge attributes, else ignore the
new attributes"
works with the usages of dllimport that I am familiar with, but doesn't
appear to be needed for dllimport anyway (see third case below).
The most common usage in the dll[im/ex]port context is this:
// Case 1:
// Class definition with DLLIMPORT attribute, followed by a redeclaration
// (or declaration as friend) without the attribute.
struct __attribute__((dllimport)) Foo1
{
int foo1fun(void) const;
};
struct Bar1
{
int useFoo1 (const Foo1& _x);
};
struct Foo1; // Redeclaration: Old attributes should be retained,
// and not overwritten with NULL_TREE
int Bar1::useFoo1 (const Foo1& _x)
{
return _x.foo1fun();
}
void test1()
{
Bar1 aBar1;
Foo1 aFoo1;
aBar1.useFoo1 (aFoo1);
}
// Case 2:
// This usage is also accepted by native compiler and is useful for
// keeping all the 'target' attributes in a single place.
// Forward declaration with DLLIMPORT attribute
// followed by definition without DLLIMPORT attribute.
// FooBar-dll.h
// All the dll attribute stuff is put here
struct __attribute__((__dllimport__)) Foo2;
struct __attribute__((__dllimport__)) Faz2;
struct __attribute__((__dllimport__)) Foz2;
// FooBar.C
#ifdef _DLLAPI
#include "FooBar-dll.h"
#endif
struct Foo2;
struct Bar2
{
int useFoo2 (const Foo2&);
};
struct Foo2 // This gets attribute from the forward declaration
{
int foo2fun(void) const;
};
int Bar2::useFoo2(const Foo2& _x)
{
return _x.foo2fun();
}
void test2()
{
Bar2 aBar2;
Foo2 aFoo2;
aBar2.useFoo2 (aFoo2);
}
// Case 3:
// Finally, this is the case where we try to add an attribute
// to a complete type.
// Definition without attribute, followed by a redeclaration
// with attribute.
struct Foo3
{
int foo3fun(void) const;
};
struct __attribute__((dllimport)) Foo3; // Ignore attribute?
struct Bar3
{
int useFoo3 (const Foo3& _x);
};
int Bar3::useFoo3 (const Foo3& _x)
{
return _x.foo3fun();
}
void test3()
{
Bar3 aBar3;
Foo3 aFoo3;
aBar3.useFoo3 (aFoo3);
}
Even without a check for COMPLETE_TYPE_P before merging attributes,
foo3fun doesn't get marked as dllimport.
Danny
> Jason
>
http://personals.yahoo.com.au - Yahoo! Personals
New people, new possibilities. FREE for a limited time.