Возникли проблемы при использовании gperf: пустое ключевое слово не допускается

Question

command_options.gperf:

%{
#include "command_options.h"
typedef struct CommandOptionCode CommandOptionCode;
%}
struct CommandOption
  {
  const char *Option;
  int OptionCode;
  };
%%
+helpverbose, CommandOptionCode::HELPVERBOSE
+password, CommandOptionCode::PASSWORD
+nocopyright, CommandOptionCode::NOCOPYRIGHT
+nolog, CommandOptionCode::NOLOG
+_64bit, CommandOptionCode::_64BIT

command_options.h:

#ifndef __COMMANDOPTIONS_H
#define __COMMANDOPTIONS_H
struct CommandOptionCode 
  {
  enum 
    {
    HELPVERBOSE = 1,
    PASSWORD = 2,
    NOCOPYRIGHT = 3,
    NOLOG = 4,
    _64BIT = 5
    };
  };
#endif

Когда я бегу:

gperf  -L C++ -t --output-file=perfecthash.hpp command_options.gperf

Только чтобы получить:

Пустое ключевое слово ввода не допускается. Чтобы распознать пустое ключевое слово ввода, ваш код должен проверить len == 0 перед вызовом сгенерированной gperf поисковой функции.

Версия: GNU gperf 3.0.1 Почему?

Answer 1

Я обнаружил, что gperf 2.7 не заботит, есть ли разделитель "%%" между первым разделом и ключевыми словами. 3.0.1 строго соблюдает это. Итак, в моем случае я должен был изменить:

%{
#include <string.h>
%}

scan

быть

%{
#include <string.h>
%}
%%

scan

Я верю, что ваш случай отличается от того, что в руководстве говорится, что первое поле структуры должно называться name.

"This first field must be called `name', although it is possible to modify its name with the `-K' option (or, equivalently, the `%define slot-name' declaration) described below."

-Чарли

Answer 2

Я обнаружил, что gperf не любит пустые строки в разделе ключевых слов. Я думаю, он рассматривает пустую строку как пустую строку, поскольку это не комментарий, и жалуется на то, что она "пустая" и имеет len=0. Так как у меня есть привычка всегда заканчивать файл пустой строкой (есть некоторые ассемблеры и компиляторы, которые оплакивают отсутствие этого), это всегда было проблемой!

Answer 3

В дополнение к проблеме пустой строки, упомянутой Ричардом, gperf также не любит пробелы, предшествующие определенным токенам. (Я вырезал и вставил простой пример gperf, который искал "грубые" слова в пользовательском вводе. Имя образца было rude-1.gperf. В этом образце имелось отступ, который вызвал эту же ошибку.)