#c #c 11 #allocator
#c #c 11 #распределитель
Вопрос:
Я использую g и определил пользовательский распределитель, где size_type равен byte. Я использую его с basic_string для создания пользовательских строк.
Код «basic_string.tcc» ведет себя ошибочно, потому что в коде
_S_create(size_type __capacity, size_type __old_capacity, const _Allocamp; __alloc)
код проверяет наличие
const size_type __extra = __pagesize - __adj_size % __pagesize;
Но вся арифметика является байтовой арифметикой, и поэтому __pagesize то, что должно иметь значение 4096, становится 0 (потому что 4096 кратно 256), и у нас есть исключение «деление на 0» (код зависает).
Вопрос не в том, что мне делать, а в том, как я мог бы попросить исправить приведенный выше код? от кого? (Я могу реализовать эти исправления).
Комментарии:
1. Пример кода не обновляется
__pagesize, поэтому ваше утверждение «__pagesize … становится «зависающим в воздухе, неподдерживаемым». Почему бы не опубликовать соответствующий код.2. @Cheersandhth. -Если в коде libray указано
const size_type __pagesize.3. Почему size_type определяется как char?
4. Учитывая, что libstdc
basic_stringв любом случае не соответствует стандарту, это может быть напрасной тратой усилий. Вы пробовали то же самое с__versa_string?5. @Zacrath стандартная библиотека позволяет определяемым пользователем распределителям ограничивать размер всех связанных объектов и определять их собственный size_type, по-видимому, потому, что в этом есть законная необходимость, а не просто из любви к чрезмерной конфигурируемости.
Ответ №1:
Прежде чем вы сможете запросить или предложить изменение чего-либо подобного, вы должны привести веские доводы в пользу того, что проблема действительно существует и ее необходимо устранить. На мой взгляд, вероятно, это не так.
Вопрос в том, при каких обстоятельствах было бы законно (или полезно) определять size_type как символ без знака? Я не знаю ничего в стандарте, что конкретно запрещает этот выбор. Это определяется как
целочисленный тип без знака — тип, который может представлять размер самого большого объекта в модели распределения.
И unsigned char это определенно unsigned integer type согласно s3.9.1. Интересно.
Так полезно ли это? Очевидно, вы, кажется, так думаете, но я не уверен, что ваш случай четко изложен. Вы могли бы поработать над предоставлением доказательств того, что эту проблему стоит решить.
Итак, мне кажется, что процесс:
- Установите, предназначено ли
unsigned charдля включения в качестве допустимого выбора в стандарт, или же оно должно быть исключено, или было просто упущено из виду. - Поднимите проблему «несоответствия стандартам» с командой для каждого компилятора, у которого возникла проблема, предоставив веские аргументы и пример воспроизведения.
- Рассмотрите возможность отправки исправления, если это в ваших силах исправить.
Или вы могли бы просто использовать short unsigned int вместо этого. Я бы.
Комментарии:
1. В соответствии с моими потребностями, я уже закомментировал код с помощью простого {if(std::numeric_limits<size_type>::max()>=__pagesize_def){ const size_type __extra = __pagesize — __adj_size % __pagesize; __capacity = __extra / sizeof(_CharT); } Поэтому я спрашиваю где я должен запросить этот патч. Что касается факта соответствия стандарту и т.д., то ясно и незамедлительно, что это всего лишь простая ошибка, независимо от какого-либо стандарта или других соображений, ее просто нужно исправить и перейти к более интересной работе и аргументам. Более того, ошибка вернется снова в shorts, если page_size>65536.
2.Попробуйте gnu.org/software/gcc/bugs или gcc.gnu.org/onlinedocs/libstdc /manual/….