[omniORB-dev] Implementation Repository

[Thomas Lockhart]

> I have now got a usable version of the Implementation
> Repository I've been working on, and I'll be posting
> it in the next couple of days after I finish some
> preliminary documentation explaining how to use it.

Great!

> In the meantime, I just noticed Duncan saying on the
> list that using STL is a no-no. This Implementation
> Repository uses the STL a lot internally (primarily
> std::vector, std::string, std::map, std::bitset and
> iostreams). For it to be included in the omniORB
> package, would this need to be changed?

I'll make the suggestion that the code should be in omniORB in either 
case (with or without STL). Folks can then contribute to adapting it to 
be STL-free if that is a requirement for their platform, and autoconf 
can be used to enable/disable it on specific platforms in the meantime. 
STL *is* settling down a bit and perhaps it is less of an issue but we 
wouldn't know until it gets a bit of exposure in the omniORB package.

I recall mico having a "mini-STL" shipped with the package; perhaps that 
could be borrowed if it would help with the distro or with other 
internal algorithms in the omniORB code.

All imho of course :)

                    - Tom