opencog-dev team mailing list archive

[Gustavo Machado Campagnani Gama <gama@xxxxxxxxxxxxx>]

Hi all,

while fixing the build on Fedora 9, I huge number of warnings were
issued because we use a few SGI STL extensions (namely, ext/hash_map and
ext/hash_set).

The deprecation warnings suggested to migrate to the TR1 replacements
"unordered_map" and "unordered_set". As it turned out, the conversion
was not as straightforward as I originally thought and ended up spending
a good part of the past week working on this. The result of this
conversion is available for review at lp:~gama/opencog/tr1.

Now, the reason I'm sending this e-mail is because migrating the code to
use the TR1 extensions has one big drawback: we loose compatibility with
older compilers. From what I could google, at least GCC 3.X and MSVC <
2005 would not be supported -- though I haven't been able to confirm
this.

We are faced thus with the following dilemma: should we target "the
future" and assume that every developer will have a relatively modern
system/environment, or should we target "maximum backwards
compatibility" and just add "-Wno-deprecated" to our default compiler
flags?

There's a third option which is to hack on "platform.h" and create
custom typedefs so that we'd use the tr1 containers only when the
compilers support them. But I'm afraid that this would be a lot harder
to implement and might not work perfectly as there are some differences
between the APIs of the hash_* and unordered_* containers.

Personally, I'd say we should go with the TR1 conversion because 1) we
will eventually have to do it (the deprecated implementation will be
removed) and, 2) we already have a few relatively modern dependencies in
our stack so most users will have to use a modern system/distro anyway.

--
Gustavo

ps: a branch that builds with gcc 4.3 but doesn't have the tr1
conversion is available at lp:~gama/opencog/gcc43 if anyone wants to
have a look; I'll merge this branch to 'main' if we choose to go with
'backwards compatibility'