[pooma-dev] POOMA Namespace Pollution

[James Crotinger]

Hi All,

I thought that the various global (non-Pooma::) functions all had Pooma::
objects as arguments, which should usually be enough to avoid collisions
with other people's stuff. What are the problem functions? 

I added namespace support to PETE a long time ago, but I believe it is an
option on the generator program that is used to generate the operator files.
Does CodeSourcery maintain the separate PETE repository? I don't think this
stuff was ever part of the Pooma distribution - we just generated the
operator includes and checked those in. At any rate, we didn't put the Pooma
operators in a namespace because, at the time, some of our compilers
(probably most, in fact) didn't do Koenig lookup correctly. 

Happy Thanksgiving!

	Jim


-----Original Message-----
From: Jeffrey D. Oldham [mailto:oldham at codesourcery.com] 
Sent: Wednesday, November 26, 2003 11:42 AM
To: Richard Guenther
Cc: Hendrik Belitz; pooma-dev at pooma.codesourcery.com
Subject: Re: [pooma-dev] POOMA Namespace Pollution

Richard Guenther wrote:
> On Wed, 26 Nov 2003, Hendrik Belitz wrote:
> 
>>Am Mittwoch, 26. November 2003 15:07 schrieben Sie:
>>
>>>You can also mark the colliding names inside the sources with namespace
>>>Pooma. But I really suspect internal Pooma is not namespace clean.
>>
>>It doesn't seem to be. Putting the POOMA headers into a namespace won't
solve
>>the problem (this seem to lead to a double inclusion of some STL headers,
>>resulting in a pretty large bunch of errors). Not putting POOMA into an
>>namespace shows that most of the internal POOMA structures are not in the
>>POOMA namespace at all (Resulting in namespace pollution).
> 
> 
> Yes, in fact, all over the POOMA source there are commented out namespace
> Pooma guards, so I think there were compiler problems some time ago. I
> already put some global functions back into Pooma namespace locally, so
> maybe there needs to be a point in the future we re-enable all the Pooma
> namespace.
> 
> Maybe Jeffrey has some suggestions on this, as it breaks backward
> compatibility.

This might be a good time to add namespace support for POOMA.  I know of 
two issues:

1) Backwards compatibility: We might be able to maintain backwards 
compatibility by supporting optional namespaces where the default option 
is no namespaces.  I attach a file with a possible approach.

2) Adding namespaces to PETE, the loop fusion mechanism, may be non-trivial.

-- 
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20031127/71484caf/attachment.html>