Undefined but declared hash<> template causing C++11 trouble
Hi Krzysz, The following lines in ui/tool/node.h are causing trouble with gcc 4.9 C++11:
#if HAVE_TR1_UNORDERED_SET namespace std { namespace tr1 { template <typename N> struct hash< Inkscape::UI::NodeIterator<N> >; } } #endif
Is it OK to remove those? If I comment them out, all seems to work fine. I cannot find the specialization definition anywhere, so seems only a fwd decl?
regards, Johan
On Thu, May 15, 2014, at 02:47 PM, Johan Engelen wrote:
Hi Krzysz, The following lines in ui/tool/node.h are causing trouble with gcc 4.9 C++11:
#if HAVE_TR1_UNORDERED_SET namespace std { namespace tr1 { template <typename N> struct hash< Inkscape::UI::NodeIterator<N> >; } } #endif
Is it OK to remove those? If I comment them out, all seems to work fine. I cannot find the specialization definition anywhere, so seems only a fwd decl?
Yes, that is a forward declaration. However the first thing to check is if your build is configured such that HAVE_TR1_UNORDERED_SET is actually defined (you might see in your config.h). One prime gotcha with #ifdef code is that unless you have the code being touched as live, it's easy to think something is safe to do when it will actually break things for other people.
That said, doing a forward declaration of a template provided in a library that we don't control is not a good practice, as you've now seen first-hand. Some judicious refactoring should be able to correct that without bringing in too much of a negative impact for others.
2014-05-15 23:47 GMT+02:00 Johan Engelen <jbc.engelen@...2592...>:
Hi Krzysz, The following lines in ui/tool/node.h are causing trouble with gcc 4.9 C++11:
#if HAVE_TR1_UNORDERED_SET namespace std { namespace tr1 { template <typename N> struct hash< Inkscape::UI::NodeIterator<N> >; } } #endif
Is it OK to remove those? If I comment them out, all seems to work fine. I cannot find the specialization definition anywhere, so seems only a fwd decl?
Looks like this is some kind of a leftover from something I didn't finish and then forgot about it. If there is no definition, it can be removed.
Regards, Krzysztof
There are some more of these in util/unordered-containers.h:
namespace std { template <> struct hashGlib::ustring : public std::unary_functionGlib::ustring, std::size_t { std::size_t operator()(Glib::ustring const &s) const { return hashstd::string()(s.raw()); } }; } // namespace std
And similar ones for boost and tr1 namespaces. These should also probably be removed.
On Fri, May 16, 2014 at 12:39 AM, Krzysztof Kosiński <tweenk.pl@...2179......> wrote:
2014-05-15 23:47 GMT+02:00 Johan Engelen <jbc.engelen@...2592...>:
Hi Krzysz, The following lines in ui/tool/node.h are causing trouble with gcc 4.9 C++11:
#if HAVE_TR1_UNORDERED_SET namespace std { namespace tr1 { template <typename N> struct hash< Inkscape::UI::NodeIterator<N> >; } } #endif
Is it OK to remove those? If I comment them out, all seems to work fine.
I
cannot find the specialization definition anywhere, so seems only a fwd decl?
Looks like this is some kind of a leftover from something I didn't finish and then forgot about it. If there is no definition, it can be removed.
Regards, Krzysztof
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 16-6-2014 17:23, Liam White wrote:
There are some more of these in util/unordered-containers.h:
namespace std { template <> struct hashGlib::ustring : public std::unary_function<Glib::ustring, std::size_t> { std::size_t operator()(Glib::ustring const &s) const { return hashstd::string()(s.raw()); } }; } // namespace std
And similar ones for boost and tr1 namespaces. These should also probably be removed.
This one is not a fwd declaration. It is defining the hash function for Glib::ustring to use the one for std::string for which the stdlib probably has an optimized version. The default hash function may be suboptimal for strings.
- Johan
On Fri, May 16, 2014 at 12:39 AM, Krzysztof Kosiński <tweenk.pl@...400... mailto:tweenk.pl@...400...> wrote:
2014-05-15 23:47 GMT+02:00 Johan Engelen <jbc.engelen@...2592... <mailto:jbc.engelen@...2592...>>: > Hi Krzysz, > The following lines in ui/tool/node.h are causing trouble with gcc 4.9 > C++11: > > #if HAVE_TR1_UNORDERED_SET > namespace std { > namespace tr1 { > template <typename N> struct hash< Inkscape::UI::NodeIterator<N> >; > } > } > #endif > > Is it OK to remove those? If I comment them out, all seems to work fine. I > cannot find the specialization definition anywhere, so seems only a fwd > decl? Looks like this is some kind of a leftover from something I didn't finish and then forgot about it. If there is no definition, it can be removed. Regards, Krzysztof ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net <mailto:Inkscape-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2014-06-16 17:23 GMT+02:00 Liam White <inkscapebrony@...400...>:
There are some more of these in util/unordered-containers.h:
namespace std { template <> struct hashGlib::ustring : public std::unary_functionGlib::ustring, std::size_t { std::size_t operator()(Glib::ustring const &s) const { return hashstd::string()(s.raw()); } }; } // namespace std
And similar ones for boost and tr1 namespaces. These should also probably be removed.
No, these are necessary, because Glib::ustring does not have a default hash function defined in the standard library. We have to provide it ourselves. This template simply says that the standard hash function for the std::string object contained within Glib::ustring should be used.
Regards, Krzysztof
participants (4)
-
Johan Engelen -
Jon A. Cruz -
Krzysztof Kosiński -
Liam White