Any input? It would be good to just get it done.

Ship It!

src/arch/power/types.hh (Diff revision 1)

Why do we need to add stuff to the std namespace?

Show all issues

1. Andreas Hansson Oct. 10, 2015, 2:35 p.m. (Oct. 10, 2015, 2:35 p.m.)

   We are using custom implementation of std::hash<X>::operator() for various reasons. The way to do so is to add the hash class to namespace std. Note that this has always been done this way. This patch does not change any behaviour.

2. Nilay Vaish Oct. 11, 2015, 10:42 a.m. (Oct. 11, 2015, 10:42 a.m.)

   I know you are not changing the behavior.  It just seems strange that
   
   libc writers would require their users to add things to std namespace.
   
   Now that I have seen the documentation, I don't think we are required
   
   to add anything to the namespace.  We provide the hash function at time
   
   of construction of the hash table object.  And I am not asking you to change
   
   anything with this patch.

src/mem/ruby/structures/CacheMemory.cc (Diff revision 1)

So what type would the compiler infer here?  Do you know when will

the compiler choose a const_iterator (underlying element cannot change)

and when will it choose a const iterator (iterator itself cannot change)?

Show all issues

1. Andreas Hansson Oct. 10, 2015, 2:35 p.m. (Oct. 10, 2015, 2:35 p.m.)

   Do we really care? If you worry I can change it back to an explicit type, but I must confess I really do not see the point in this instance.

2. Nilay Vaish Oct. 11, 2015, 10:42 a.m. (Oct. 11, 2015, 10:42 a.m.)

   Not with this code, but I am still curious to know if C++11 or 14 or whatever
   
   has a way for the programmer to express, while using auto, that the const_iterator
   
   version of find() should be used.  Again, I am not asking for changing the patch.

Ship It!