Я расследую сбой в нашей программе. Я смотрю на QSort, написанный другим программистом. Я хотел бы обсудить, почему с ними это небезопасно, но они лучше понимают С ++, чем я, и хотели бы получить как можно больше информации. Я не могу вставить фактический код, но я сделаю все возможное, чтобы воссоздать основы.
Я могу придумать несколько причин, по которым это небезопасно, но хотел бы более конкретных тем для обсуждения.
QSort запускается на двух массивах с разными структурами. Первым элементом является другая структура с именем MyString. В противном случае другие элементы структуры отличаются. Например:
struct SItemA
{
MyString ItemId;
INT IntFoo;
}
struct SItemB
{
MyString ItemId;
FLOAT FloatFoo;
}
Это приложение, критичное к производительности, поэтому строки / массивы STL не используются. Я не знаю подробностей о том, как реализованы строки / массивы, но они надежны и хорошо протестированы большим сообществом и не являются предметом моего подозрения.
static int
IDCompare(
void const* inA,
void const* inB)
{
MyString const* a = (MyString const*)inA;
MyString const* b = (MyString const*)inB;
return MyStrCmp(**a, **b);
}
appQsort(aItems.GetData(), aItems.Num(), sizeof(SItemA), IDCompare);
appQsort(bItems.GetData(), bItems.Num(), sizeof(SItemB), IDCompare);
QSort наивно предполагает, что адрес структуры совпадает с адресом элемента MyString. Насколько я знаю, это правда (на данный момент), так как компиляторы C ++ гарантируют, что элементы структуры хранятся в порядке (при условии, что структура соответствует критериям для POD, что этот делает, насколько я могу судить).
Я думаю, что это было написано таким образом, чтобы избежать написания двух разных версий QSort с учетом каждой структуры.
Мое главное замечание заключается в том, что если реализация структуры изменяется (строка (пере) / перемещается), программа будет работать непредсказуемым образом и даже может привести к нарушению памяти.
Предполагая, что определение структуры не меняется. Есть ли другие проблемы с QSort как написано?
Задача ещё не решена.
Других решений пока нет …