[omniORB-dev] Implementation Repository

[Duncan Grisby]

On Wednesday 26 February, Thomas Lockhart wrote:

> 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 intend to keep the core parts of omniORB -- i.e. the ORB libraries,
the IDL compiler, omniNames -- free of STL. There are plenty of users
for whom STL is not an option, either because it's not available at
all, or because it conflicts with aspects of their application code.
STL also has a bad impact on code size, and there are few (practical)
guarantees about things like thread safety or efficiency.

Non-core parts, like an added ImR, are a different matter. If the
authors of those parts want to make a different trade-off, and use
STL, that's fine by me. Just be prepared for the portability
issues... :-)

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --