При реализации operator [] как включить проверку границ?

Question

Прежде всего, я прошу прощения за долгое приведение к такому упрощенному вопросу.

Я реализую класс, который служит очень длинным одномерным индексом на кривой заполнения пространства, или n-кортеж, представляющий декартову координату, которой соответствует индекс.

class curvePoint
{
public:
    friend class curveCalculate;

    //Construction and Destruction
    curvePoint(): point(NULL), dimensions(0) {}
    virtual ~curvePoint(){if(point!=NULL) delete[] point;}

    //Mutators
    void convertToIndex(){ if(isTuple()) calc(this); }
    void convertToTuple(){ if(isIndex()) calc(this); }
    void setTuple(quint16 *tuple, int size);
    void setIndex(quint16 *index, int size);
    void setAlgorithm(curveType alg){algorithm = alg;}

    //Inspectors
    bool isIndex(){return current==Index;}
    bool isTuple(){return current==Tuple;}
    size_t size(){return dimensions;}
    quint16 operator[](size_t index);

    enum curveType{HilbertCurve, ZCurve, GrayCodeCurve};
    enum status{Index, Tuple};

private:
    curveCalculate calc;
    curveType algorithm;
    quint16 *point;
    size_t dimensions;
    status current;
};

(длина массива, на который указывает точка , равна измерения )

В любом случае при реализации оператора [] мне было интересно, каков наилучший способ проверки границ. Я хочу избегать выдачи исключений, если это вообще возможно, и полный диапазон значений можно использовать для каждого числа в массиве, поэтому специальное значение, возвращаемое в случае ошибки вне границ, также невозможно;

Я думал о чем-то вроде этого, хотя и реализовано в определении класса:

quint16 curvePoint::operator[](size_t index)
{
    return point[ index % dimensions ];
}

Это делает так, что мы никогда не покидаем границ массива, и если я хорошо документирую, я думаю, что это будет хорошо; тем не менее, я настороженно отношусь к этой конкретной реализации.

Это выглядит приемлемым для других? Есть ли другой способ проверки границ, в то же время удовлетворяя моим ограничениям?

Edit: Расчет таких вещей, как кривые Гильберта и т. Д., Очень запутанный, достаточно запутанный, поэтому я не хочу, чтобы добавлялся дополнительный интерфейс для библиотек stl.

Кроме того, поскольку мне придется преобразовывать многие тысячи из них каждый раз, когда запрашивается многомерная база данных, я не хочу дополнительных затрат на вызовы функций stl в миксе, если это вообще возможно.

Мне скорее нравится идея утверждения; но, если я правильно помню, что перерывы в сборках релизов не так ли?

Полагаю, я могу использовать исключения, это то, за что все рутируют, но я использую библиотеки Qt, и они избегают исключений как по производительности, так и по переносимости, и я надеялся сделать то же самое.

Answer 1

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

Answer 2

Если я что-то не так понимаю,

return point[ index % dimensions ];

не является проверкой границ вообще. Он возвращает реальное значение из совершенно другой части строки, что усложнит обнаружение ошибок.

Я бы либо:

1. Брось исключение или утверждение (хотя ты сказал, что не хочешь этого делать)
2. Просто разыменуйте точку за массивом "естественным" способом (т.е. просто пропустите любую внутреннюю проверку). Преимущество перед% состоит в том, что они с большей вероятностью (хотя undefined и undefined) получают «странные» значения и / или нарушение доступа

В конце концов, вызывающий абонент нарушает ваши предварительные условия, и вы можете делать все, что пожелаете. Но я думаю, что это самые разумные варианты.

Также рассмотрите, что сказал Кэтэлин о включении встроенных коллекций STL, если это разумно.

Answer 3

Возможно, вы могли бы добавить исключение «вне границ» для оператора [] (или хотя бы assert).

Это должно выявить любые проблемы, особенно при отладке.