Russian Qt Forum

Здравствуйте :) Ломаю голову над проблемой уже шестой час, но никак не могу понять, почему не работает. Помогите пожалуйста...

Я хочу сделать QList< USBID* > и искать их по indexOf(). Как было написано в документации на QList, я реализовал в USBID оператор сравнения, получилось так:

C++ (Qt)
bool USBID::operator ==(USBID &cmpId) const

В ходе отладки выяснилось, что до выполнения моего operator == дело не доходит.

эта функция сравнения подойдет для QList<USBID>, а для QList<USBID *> нужно реализовать функцию bool USBID::operator ==(USBID *cmpId) const

Всё равно не работает :'( А я правильно думаю?

C++ (Qt)
USBID meow(vID);
int foundIndex = m_ids->indexOf(&meow); // QList< USBID* > *m_ids;

Вам был бы нужен был бы оператор
bool operator == ( const MyString * cmpId, const MyString * cmpId2 );
Но оператор с 2 ссылками перегрузить вам не удастся.

если meow - это какая-то локальная переменная, то она получит новый адрес, которого точно нету в m_ids (а если вдруг такой адрес там и найдется, то он все равно будет указывать на другой объект)

kambala, я думаю он хотел перегрузить оператор ==, что бы сравнивались не указатели, а то, на что они указывают.

Впринципе вместо указателя можно использовать класс (самописный или существующий).

Нечто вроде:

C++ (Qt)
bool operator ==( const QPointer< USBID > &cmpId, const QPointer< USBID > &cmpId2 )
{
    return *cmpId == *cmpId2;
}
 
USBID meow(vID);
int foundIndex = m_ids->indexOf(&meow); // QList< QPointer< USBID > > *m_ids;

Примечание 1: QPointer требует чтобы USBID наследовалось от QObject.
Примечание 2: Я бы на вашем месте отказался от QList::indexOf.

да, точно :)

тогда если объекты типа USBID и так где-то хранятся, почему бы не хранить их прямо в QList<USBID>?

И правда, классы изначально кривые, отсюда и сложности.
Спасибо вам за советы, утром буду пробовать ^_^

indexOf - всего лишь линейный перебор, да и нет смысла его переопределять - напр он может потребоваться для нахождения указателя. Иногда продуктивен подход типа "да чихал я на Ваши функторы!", напр

C++ (Qt)
template <class T1, class T2>
int IndexOfValue( const T1 & src, const T2 & match )
{
 for (int i = 0; i < src.size(); ++i)
  if (*src[i] == match)
   return i;
 return -1;
}
 

Я отказался от затеи с QList :D получилось так:

C++ (Qt)
class USBIDs
{
// ...
public:
  bool findDevice(const QString &vID, const QString &pID);
  QString vendorName() const
  QString productName() const;
 
private:
  QHash< QString, USBInfo > *m_ids;
  QString m_selectedKey;
};

C++ (Qt)
bool USBIDs::findDevice(const QString &vID, const QString &pID)
{
  m_selectedKey = vID + pID;
  return m_ids->contains(m_selectedKey);
}
 
QString USBIDs::vendorName() const  { return m_ids->value(m_selectedKey).vendorName; }
QString USBIDs::productName() const { return m_ids->value(m_selectedKey).productName; }

m_selectedKey. xорошего впечатления не производит :)  Потом если Вам понадобится выводить поля USBInfo в определенном порядке, то нужен будет еще контейнер. А вот завернуть все поиски в USBIDs - идейка неплохая, может действовать примерно так

C++ (Qt)
struct USBIDs : public QList <USBInfo> {
 typedef QList <const USBInfo *> TUSBListPtr;
 TUSBListPtr Lookup( const QString * vendorName, const QString * productName, int options ) const;
 
 TUSBListPtr LookupByVendor( const QString & vendorName, int options = look_FullMatch  ) const;
 {
  return Lookup(&vendorName, 0, options);
 }
 
 TUSBListPtr LookupByProduct( const QString & productName, int options = look_FullMatch  ) const;
 {
  return Lookup(0, &productName, options);
 }
 
 enum {
  look_FullMatch = 0,
  look_StartsWith = 1,
  look_EndsWith = 2,
 };
};
 

Чёрт, я ничего не понял :D Igors, можете в двух словах пояснить ваш пример? Пожалуйста ^^
Upd: кажется, чуть-чуть понял. А почему m_selectedKey было плохо?

Вообще-то наследоваться от контейнера часто нехорошо, но здесь, мне кажется, нормально.  Насчет m_selectedKey - ну а как Вы его будете пользовать?

C++ (Qt)
if (uids.findDevice(vendor, product)) {
 // а здесь что?
 return uids.vendorName();  // нет смысла, это тот самый vendor  
}
 

Напр потребуется подсчитать (или показать) все продукты такого-то vendora - и что, опять класс делать? Разумно выглядит зарядить все выборки в одном месте, пусть пока 1, по мере необходимости будете расширяться внутри класса

C++ (Qt)
 TUSBListPtr lst = uids.LookupByVendor(vendor);
 
// теперь по каждому USB этого vendora
 for (int  i = 0; i < lst.size(); ++i)
   // печатаем, выводим и.т.п.
}
 

Я подумал и остановился на ассоциативных массивах. Получилось плоско, но вроде бы попроще :)

C++ (Qt)
class USBID_Vendor
{
// ...
private:
  QString _name
  QHash< QString, QString > _products; // ID, Name
};

C++ (Qt)
class USBIDs
{
// ...
private:
  QHash< QString, USBID_Vendor > _ids
};

Это решает одну задачу (получить ID по имени). А если надо имя по ID? А если есть 2 или более ID с тем же именем или наоборот? Надо считать хотя бы на 1 ход вперед  :)

ID по имени? Мне наоборот нужно :) для очередного USB устройства я получаю VendorID и ProductID, для которых нужно получить соответственно, название производителя и устройства. ID производителей не повторяются, устройств, полагаю, тоже.

Нужно также полагать что

- 2 "просто одинаковых" устройств быть не может
- показать/напечатать все устройства такого-то вендора не требуется
- не требуется  даже печатать устройства в том порядке что они обнаружены

Иначе Ваша реализация не проходит (наверное требования слишком завышены  :))

Я правильно понимаю, что ваши дополнения - это ограничения на пользователя этой адской конструкции? Тогда "просто одинаковые" устройства фильтруются ещё до того как, в исходных данных повторяющихся пар вендор-продакт нету. Показывать-печатать устройства вендора тоже не надо - и вряд ли понадобится когда-либо. Порядок устройств определяется датой установки в систему, так что отпадает как и всё остальное.

Зачем всё это, если от реализации требуется всего лишь адекватно отвечать на чётко поставленный (один) вопрос?

Вернемся к вопросу-первоисточнику

Отсюда я делаю вывод что у Вас имеется набор (массив, контейнер) USBID имеющих vendorID. productID (ключ). Наверное у Вас есть набор устройств (откуда-то получен) и задача найти/проверить есть ли устройство с такими-то ID в Вашем списке. Если это не так - поясните, потому что не видно что еще здесь может иметь смысл.

Да, всё верно. Я получаю из реестра имена ключей, из них регулярным выражением добываю VID и PID. Есть файл USB.IDS (http://www.linux-usb.org/usb.ids). Задача сводится к тому, чтобы для очередного устройства с VID и PID получить название компании-производителя и название устройства.

Ага, а я-то думал у Вас расширяемый список устройств. Ну тогда не видно зачем городить какие-то свои классы если это решается на встроенных

C++ (Qt)
typedef int TID;
typedef QHash <TID, QString> TProductHash;
typedef QPair <QString, TProductHash> TVendor;
typedef QHash <TID, TVendor> TVendorHash;
 
TVendorHash vendorHash;
 
// заполняем vendorHash из текстовика
 
bool Lookup( TID vendorID, QString & vendorName, TID productID, QString & productName )
{
	TVendorHash::const_iterator itV = vendorHash.find(vendorID);
	if (itV == vendorHash.end()) return false;
	const TVendor & vendor = *itV;
	vendorName = vendor.first;
	TProductHash::const_iterator itP = vendor.second.find(productID);
	if (itP == vendor.second.end()) return false;
	productName = *itP;
	return true;
}
 

О, а я про QPair не знал :)
Спасибо вам за помощь :D