RE: [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:address@hidden]
Sent: Wednesday, November 26, 2003 11:42 AM
To: Richard Guenther
Cc: Hendrik Belitz; address@hidden
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
address@hidden