Anonymous Namespaces

[Gabriel Dos Reis]

Chris Lattner <sabre@nondot.org> writes:

| On 1 Feb 2004, Gabriel Dos Reis wrote:
| 
| > Chris Lattner <sabre@nondot.org> writes:
| > | The "right" solution I mention above, would involve the C++ parser setting
| > | TREE_PUBLIC to false for entities in anonymous namespaces, and using some
| > | other (C++ specific) flag to control name lookup functions.  I am guessing
| > | that this is unlikely to fly though, because it would require changing
| > | more of the C++ front-end.  As such, I am specifically not suggesting
| > | this.
| >
| > Ahem.
| 
| What does 'ahem' mean?

I asked:

   So, exactly what are you suggesting with respect to the "unnamed
   namespace" as far as GCC is concerned?  

You went on a very loooong story, only to conclude that 

   As such, I am specifically not suggesting  this.

"Ahem" was an elliptic interjection for: Okaayyy, what do you suggest then?!?

| > | If this doesn't make sense, or if I made technical errors in my
| > | description, please let me know.  I think it should be clear that either
| > | implementation _cannot_ effect name lookup at all, because it does not
| > | change the value of any existing flag.
| >
| > If you assume that your "internal linkage" is not necessarily the same
| > as internal linkage in C++, then it makes sense.  If, however, as
| > you've claimed, you say they are the same, then it does not fly.  And
| > the why can be found if you unwind three or four messages up.
| 
| What are you talking about?  LLVM?  LLVM has no bearing on the description
| I just gave!

I'm talking about your use of "internal linkage".  

You seem to be focused on what you think people might say or think
about  LLVM doing, and yet you're saying that LLVM has nothing to do
with this discussion.  What if you take it granted that what LLVM does
is the last of my preoccupations as far as GCC is concerned?  I'm
interested in this discussion only because it is about what GCC might
do in order to generate better code; what LLVM does with the various
words it happens to redefine is of secondary interest to me as far as
those mystifications are not suggested to be brought into GCC.

[...]

| > | > So, the question is what are you transforming according to what
| > | > semantics and what are you demonstrating?
| > |
| > | The point is that what LLVM does is irrelevant to this discussion, as GCC
| > | is not LLVM.
| >
| > Oh, really, I would have sweared the contrary :-}
| 
| I'm not really sure what you're getting at here.  LLVM has, as one

Just pointing out some of your self-contradictory positions that make
it very hard to see where you're driving at -- no mentioning standard
phrase transmutation.  If what LLVM does has nothing to do with this
discussion, why did you bring it into the picture in the first place?

I'm pretty sure, it has something to do with the discussion, but I
suspect that some laws about flip-flop ought to be respected, which I
guess might explain why you flip-flop :-/

| component, a C/C++ front-end that is build using GCC.  It has many other
| components that are not, and LLVM itself is perfectly functional without
| any GCC code at all.  If you'd like, you can say that the LLVM project is
| a superset of the GCC project, but it does not "use" _all_ of the code or
| have _all_ of the features that GCC does, so I'm not sure this is
| appropriate either.  In any case LLVM != GCC.
| 
| >   > Yes. The second phase of two-phase name lookup ignores functions with
| >   > internal linkages.  Also, entities with internal linkage cannot be
| >   > used as template arguments.
| >
| >   With the LLVM G++ front-end, all entities declared in an anonymous
| >   namespace are emitted with internal linkage, including any related RTTI
| >   info, vtables, etc.
| 
| I don't understand what you're saying here.

The last tree lines are your words.  You were supposed to reply to the
nested quote -- which specifically was talking about interaction
between intenal linkage and name lookup.  You brought what "LLVM does"
in the discussion, in a context where you were using "internal
linkage" with a totally different meaning.  In other circumstances, I
owuld have characterized it as fraud.

-- Gaby