Newest g++ gives a warning about use of deprecated feature

In file included from src/slha_io.cpp:27:
slhaea/slhaea.h:1528:36: warning: ‘template<class _Arg, class _Result> struct std::unary_function’ is deprecated [-Wdeprecated-declarations]
 1528 |   struct key_matches : public std::unary_function<value_type, bool>
      |                                    ^~~~~~~~~~~~~~
In file included from /usr/include/c++/12/string:48,
                 from src/slha_format.hpp:22,
                 from src/slha_io.hpp:22,
                 from src/slha_io.cpp:19:
/usr/include/c++/12/bits/stl_function.h:117:12: note: declared here
  117 |     struct unary_function
      |            ^~~~~~~~~~~~~~
slhaea/slhaea.h:2354:36: warning: ‘template<class _Arg, class _Result> struct std::unary_function’ is deprecated [-Wdeprecated-declarations]
 2354 |   struct key_matches : public std::unary_function<value_type, bool>
      |                                    ^~~~~~~~~~~~~~
/usr/include/c++/12/bits/stl_function.h:117:12: note: declared here
  117 |     struct unary_function
      |            ^~~~~~~~~~~~~~
slhaea/slhaea.h:2375:46: warning: ‘template<class _Arg, class _Result> struct std::unary_function’ is deprecated [-Wdeprecated-declarations]
 2375 |   struct key_matches_block_def : public std::unary_function<value_type, bool>
      |                                              ^~~~~~~~~~~~~~
/usr/include/c++/12/bits/stl_function.h:117:12: note: declared here
  117 |     struct unary_function
      |            ^~~~~~~~~~~~~~

This is by no mean critical but I thought you might want to know about that.

Dear Thomas,

for my personal use I implemented the following two push_front() functions with constant complexity:

  void
  push_front(const value_type& block)
  { impl_.push_front(block); }

  void
  push_front(const std::string& blockString)
  {
    value_type block;
    block.str(blockString);
    impl_.push_front(block);
  }

What do you think about adding these functions to your package? I find them quite useful, so maybe other users do so as well.

Best,
Alex

Dear Frank Thomas,

I'm planning to use your SLHAea package in my own spectrum generator because it looks very elegant and seems to be easy to use.

However, speed is a critical point for me, so I wonder how SLHAea performs compared to SLHALib (http://www.feynarts.de/slha/) or other hand-written SLHA libraries? My wish would be that reading and writing time together is much smaller than 0.1 ms. Have you done some speed comparisons with other libraries?

There is one problematic point which I have in mind: You are using std::string as map key in your examples:

  ifstream ifs("slha1.txt");
  Coll input(ifs);

  cout << "tan(beta) = "        << input["MINPAR"][3][1] << '\n';
  cout << "m_top(pole) line:\n" << input["SMINPUTS"][6]  << '\n';
  cout << "SMINPUTS block:\n"   << input["SMINPUTS"];

It could be that this is rather slow compared to an integer key (depending on the std::map implementation). So, using enums as an alternative would probably help here.

One possibility to achieve this would be to make the key type a template parameter which can be chosen by the user at compile time

  template <class key_type = std::string>
  class Coll { ... };

  namespace SLHAea {
     enum BlockNames : int { MINPAR, SMINPUTS, ... };
  }

  int main() {
    ifstream ifs("slha1.txt");
    Coll<SLHAea::BlockNames> input(ifs);

    cout << "tan(beta) = "        << input[SLHAea::MINPAR][3][1] << '\n';
    cout << "m_top(pole) line:\n" << input[SLHAea::SMINPUTS][6]  << '\n';
    cout << "SMINPUTS block:\n"   << input[SLHAea::SMINPUTS];
  }

What do you think about this option?

Best regards,
Alexander Voigt

MSVC gives a compiler warning for line 841 in slhaea.h, hinting to a possible bug.
The line for which the warning is given is in Block& read(std::istream& is):

is.seekg(-line_str.length()-1, std::ios_base::cur);

The warning from MSVC is:

warning C4146: unary minus operator applied to unsigned type, result still unsigned

If I understand correctly, the issue is the following: line_str.length() returns an unsigned value. Applying the unary minus operator to that value returns another unsigned value, which may be huge.

Example:

unsigned u = 1;
std::cout << -u; // prints 4294967295

I believe this is not the desired behavior.

A possible fix would be to perform a static_cast<std::ptrdiff_t>:

unsigned u = 1;
std::cout << -static_cast<std::ptrdiff_t>(u); // prints -1