Source: odb-api
Version: 0.17.4-1
Severity: important
Tags: upstream
Justification: fails to build from source
Thanks for quickly taking care of #880680. Alas, builds of odb-api
for 32-bit architectures such as i386 are still failing:
/<<PKGBUILDDIR>>/eckit/src/eckit/container/DenseMap.h:144:11: error: 'const
V& eckit::DenseMap<K, V>::operator[](const size_t&) const [with K = unsigned
int; V = std::__cxx11::basic_string<char>; size_t = unsigned int]' cannot be
overloaded
const V& operator[] (const size_t& i ) const { ASSERT(i < values_.size());
return values_[ i ]; }
/<<PKGBUILDDIR>>/eckit/src/eckit/container/DenseMap.h:141:11: error: with
'const V& eckit::DenseMap<K, V>::operator[](const K&) const [with K = unsigned
int; V = std::__cxx11::basic_string<char>]'
const V& operator[] (const K& k ) const { return values_[ find(k)->idx() ];
}
/<<PKGBUILDDIR>>/eckit/src/eckit/container/DenseMap.h:145:5: error: 'V&
eckit::DenseMap<K, V>::operator[](const size_t&) [with K = unsigned int; V =
std::__cxx11::basic_string<char>; size_t = unsigned int]' cannot be overloaded
V& operator[] (const size_t& i ) { ASSERT(i < keys_.size()); return
values_[ i ]; }
/<<PKGBUILDDIR>>/eckit/src/eckit/container/DenseMap.h:142:5: error: with 'V&
eckit::DenseMap<K, V>::operator[](const K&) [with K = unsigned int; V =
std::__cxx11::basic_string<char>]'
V& operator[] (const K& k ) { return values_[ find(k)->idx() ]; }
The issue is that DenseMap<> generally has two pairs of [] operator
definitions: one that takes a key (the first type parameter) and works
like get(), and one that takes an index (always size_t) and works like
at(). This approach is confusing at best, and breaks altogether when
the key and index types are identical, as is the case when using a key
type of unsigned int in 32-bit builds.
I would suggest removing one of the [] pairs (probably the one that
takes size_t, since it's less idiomatic for maps) after flushing out
any usage that would otherwise mistakenly go to the other pair by
locally running experimental 64-bit builds in which the pair to be
removed is present but private.
Could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[email protected]
