This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/13134] [3.4 regression] Visibility attribute is ignored


------- Additional Comments From carlo at alinoe dot com  2003-12-01 20:37 -------
Subject: Re:  [3.4 regression] Visibility attribute is ignored

On Mon, Dec 01, 2003 at 08:16:04PM -0000, austern at apple dot com wrote:
> 
> ------- Additional Comments From austern at apple dot com  2003-12-01 20:15 -------
> Subject: Re:  [3.4 regression] Visibility attribute is ignored
> 
> I would prefer to avoid distinguishing between "B has no visibility 
> attribute specified" and "B has default visibility specified".  Any 
> solution that requires distinguishing between those two 
> almost-identical things means that a declaration's visibility can have 
> five possible states, not four, i.e. that it requires three bits to 
> describe.

I was merely thinking about the parallel with 'inline' and how I treat
that when I proposed that.  There I do not put 'inline' at a declaration
because you can't see whether or not it should be inlined:

int foo(int x);
int bar(int y);

but I add it later, at the definition of the function:

inline int
foo(x)
{
  return x + 1;
}

int bar(int y)
{
  // Huge body of 400 lines.
}

The parallel that I saw what that it is to be prefered to have
the specification only in one place, but - in the case of visibility
it would be other way around (specified in the header, and not at
the definition).  So, if you want you can argue that at the moment
you write the definition you already know the visibility (as it
follows the declaration) and might as well be forced to be specified,
just like in the case of constness of class member functions.

In other words, I see no objections to do it your prefered way.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13134


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]