Здравствуйте, B0FEE664, Вы писали:

BFE>Для беззанаковых целых в С++ переполнения не бывает (в отличии от знаковых).
BFE>Если же говорить об ошибках допускаемых на крайних значениях, то их одинаково легко допустить для любого типа.

Я не знаю, как тебе объяснить. Вот смотри, надо тебе, например, на какое-то смещение в массиве назад отсутпить и потом ещё позицию поделить на что-то. В случае int ты всегда получишь адекватный индекс, а вот в случае uint -- вовсе и не всегда...

BFE>А если нужно писать одинаковый код для разных платформ? Я скорее предпочту выбрать соответствие диапазонов, чем разрядность.

Ну и зря. Надо разядность выбирать ПО ЗАДАЧЕ, а не по платформе...
А то у тебя на одной платформе будут глюки из-за нехватки разрядности, а на другой нет...

BFE>Может, да. А может и хватить.
Если это ветор байт и в пкмяти нет вообще больше ничего, то шансы есть...
Много уже программ написал с такой структурой данных?

BFE>это беззнаковое-то число?
Не, знаковое почитать и проверить на вменяемость диапазона...

BFE>Да, но ещё и потому, что "старый" код часто завязан на эту размерность.
Да не надо больше просто!
Когда с 16 бит переходили, было надо, вот и переходили на более длинный int. А сейчас не надо.
НА 32-й платформе int64 доступен же. Просто в большинстве мест НЕ НУЖЕН...

Я ещё раз намекаю, что разрядность определяется ЗАДАЧЕЙ, а не платформой...

BFE>И тут начинаются пляски с define'ами для подбора правильного int под размер данной платформы.

У тебя просто какие-то проблемы с разрядностью целых.
Смотри, если ты о 16-разрядных платформах, то, во-первых законодательство РФ запрещает это обсуждать в открытых источниках, а, во-вторых, кроссплатформенность там не нужна, и не возможна, к тому же. Так как нужн другие данные и алгоритмы.
А если мы от 32/64 говорим, то нужно целых три целых, ну, на крайняк 4

1) 32-битное знаковое
2) 64-битное знаковое
3) целое, в которое можно затолкать указатель (но это уже почти никогда не нужно)
3а) знаковое целое в которое можно класть индекс массива в памяти (но это уже совсем никогда не нужно)

Собственно всё...

Здравствуйте, jyuyjiyuijyu, Вы писали:

J>Здравствуйте, night beast, Вы писали:

J>

J>p = strstr(text, 'magic pattern') 

J>if (p != text)

J>if (p[-1] == '#')
J>else


J>p = strstr(text, 'magic pattern') 

J>if (p - text >= 3)


J>if (p[-1] == '#' && p[-2] == '@' && p[-3] == '%')
J>else
J>

Помоему без подобного онанизма можно обойтись просто написав

p = strstr(text, '#magic pattern')
...

p = strstr(text, '%@#magic pattern')
...

Здравствуйте, johny5, Вы писали:

J>Помоему без подобного онанизма можно обойтись просто написав
J>

J>p = strstr(text, '#magic pattern')
J>...

J>p = strstr(text, '%@#magic pattern')
J>...

J>

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

Здравствуйте, Erop, Вы писали:

BFE>>А если нужно писать одинаковый код для разных платформ? Я скорее предпочту выбрать соответствие диапазонов, чем разрядность.
E>Ну и зря. Надо разядность выбирать ПО ЗАДАЧЕ, а не по платформе...
Это не всегда возможно. Например, я долгое время писал библиотеки (ActiveX контролы) на продажу. Их иногда использовали в таких загадочных и нетривиальных условиях, что я просто "диву давался".

E>А то у тебя на одной платформе будут глюки из-за нехватки разрядности, а на другой нет...
Обычно, всё же ресурсы кончаются раньше, чем разрядность. Но не всегда.

BFE>>Может, да. А может и хватить.
E>Если это ветор байт и в пкмяти нет вообще больше ничего, то шансы есть...
E>Много уже программ написал с такой структурой данных?
Конкретно std::array — нет. А вот самодельный массив построенный на Bi-дереве с использованием всего диапазона unsigned int приходилось использовать.

E>Я ещё раз намекаю, что разрядность определяется ЗАДАЧЕЙ, а не платформой...
При написании библиотек задача как таковая неизвестна.
BFE>>И тут начинаются пляски с define'ами для подбора правильного int под размер данной платформы.
E>У тебя просто какие-то проблемы с разрядностью целых.
E>Смотри, если ты о 16-разрядных платформах, то, во-первых законодательство РФ запрещает это обсуждать в открытых источниках, а, во-вторых, кроссплатформенность там не нужна, и не возможна, к тому же.
Да. Про это лучше забыть как про страшный сон.

E>Так как нужн другие данные и алгоритмы.
E>А если мы от 32/64 говорим, то нужно целых три целых, ну, на крайняк 4
E>1) 32-битное знаковое
E>2) 64-битное знаковое
E>3) целое, в которое можно затолкать указатель (но это уже почти никогда не нужно)
E>3а) знаковое целое в которое можно класть индекс массива в памяти (но это уже совсем никогда не нужно)
E>Собственно всё...

Собственно из за того, что 3a) сделан беззнаковым для стандартных контейнеров весь спор.

Здравствуйте, B0FEE664, Вы писали:

E>>Ну и зря. Надо разядность выбирать ПО ЗАДАЧЕ, а не по платформе...
BFE>Это не всегда возможно. Например, я долгое время писал библиотеки (ActiveX контролы) на продажу. Их иногда использовали в таких загадочных и нетривиальных условиях, что я просто "диву давался".

И что, ты хочешь сказать, что тот битик когда-то оказался важным?
Брал бы в сомнительных местах int64 и не парился бы...

BFE>Обычно, всё же ресурсы кончаются раньше, чем разрядность. Но не всегда.
Ну, если разрядность выбрана правильно, то всегда. И "запасной" битик сверху просто не нужен.

BFE>Конкретно std::array — нет. А вот самодельный массив построенный на Bi-дереве с использованием всего диапазона unsigned int приходилось использовать.

А зачем там был unsigned int, а не int64?
BFE>При написании библиотек задача как таковая неизвестна.
Это не правда. У тебя не было ТЗ разве?

E>>А если мы от 32/64 говорим, то нужно целых три целых, ну, на крайняк 4
E>>1) 32-битное знаковое
E>>2) 64-битное знаковое
E>>3) целое, в которое можно затолкать указатель (но это уже почти никогда не нужно)
E>>3а) знаковое целое в которое можно класть индекс массива в памяти (но это уже совсем никогда не нужно)
E>>Собственно всё...

BFE>Собственно из за того, что 3a) сделан беззнаковым для стандартных контейнеров весь спор.

Типа из-за варнингов проблема что ли?
Ну-ну, воюйте с варнингами...

просто другой нужды в беззнаковости индекса, кроме как предупреждения -- нет...

Здравствуйте, Erop, Вы писали:

E>>>Ну и зря. Надо разядность выбирать ПО ЗАДАЧЕ, а не по платформе...
BFE>>Это не всегда возможно. Например, я долгое время писал библиотеки (ActiveX контролы) на продажу. Их иногда использовали в таких загадочных и нетривиальных условиях, что я просто "диву давался".

E>И что, ты хочешь сказать, что тот битик когда-то оказался важным?
да.
E>Брал бы в сомнительных местах int64 и не парился бы...
Хорошо бы ещё знать, какие из мест следует считать сомнительными...

BFE>>Конкретно std::array — нет. А вот самодельный массив построенный на Bi-дереве с использованием всего диапазона unsigned int приходилось использовать.
E>А зачем там был unsigned int, а не int64?
для скорости и экономии места. Да и внешний интерфейс был ограничен unsigned int.

BFE>>При написании библиотек задача как таковая неизвестна.
E>Это не правда. У тебя не было ТЗ разве?
Было (давно это было), типа такого: надо написать то-то и то-то. Напиши спецификацию и имплементируй её. А на основе спецификации мы тут наймём технического редактора, он help для пользователей напишет. Вот такое ТЗ от американского босса, которого я никогда в живую не видел и с которым никогда не встречался, хотя работал на него много лет.

Здравствуйте, B0FEE664, Вы писали:

E>>Брал бы в сомнительных местах int64 и не парился бы...
BFE>Хорошо бы ещё знать, какие из мест следует считать сомнительными...
Ну назови, для примера пять мест, где выбор неочевиден...

И интересно посмотреть на место с битиком, тоже.

E>>А зачем там был unsigned int, а не int64?
BFE>для скорости и экономии места. Да и внешний интерфейс был ограничен unsigned int.

Зачем?

BFE> Было (давно это было), типа такого: надо написать то-то и то-то. Напиши спецификацию и имплементируй её. А на основе спецификации мы тут наймём технического редактора, он help для пользователей напишет. Вот такое ТЗ от американского босса, которого я никогда в живую не видел и с которым никогда не встречался, хотя работал на него много лет.

Прекрасное ТЗ. Знаковость индекса можно выбирать любую...

Здравствуйте, Аноним, Вы писали:
А>Приветствую.
А>- Меня вот всегда удивляло, почему в качестве счетчика цикла, который будет использоваться в качестве индексации масива / контейнера, зачастую используется знаковая целочисленная переменная?
потому что int это красиво. unsigned int это как int* (и сноска внизу — * — как int не работает)

А>- Кстати, как часто, когда вы имеете дело с контейнерами, вы используете итераторы? Оператор индексации / метод at настолько же часто?
когда они есть, тогда и используются.

А>- Допустим, нам надо выделить два одинаковых по размеру куска памяти одного и того же типа.
А>Использовали бы стандартный вариант
А>

А>int *a = new int [n * 2];
А>int *b = a + n;
А>

А>вот такой?
во втором варианте образуется зависимость одного от другого. зачем нужна эта зависимость?

Здравствуйте, B0FEE664, Вы писали:

BFE>Собственно из за того, что 3a) сделан беззнаковым для стандартных контейнеров весь спор.
Даже там оно так непослеовательно сделано... Когда индексируешь вектор, то беззнаковое, а когда итератор произвольного доступа, то вроде бы знаковое...

Или ты и difference_type за беззнаковое держишь?

В любом случае, нужда, которую решили цовлетворить в std, когда выбирали беззнаковый индекс массива, не особо-то нужная...
Вообще весь std::vector плохо спроектирован очень много лет назад. Чего на него ориентироваться?

Здравствуйте, Erop, Вы писали:

E>>>Брал бы в сомнительных местах int64 и не парился бы...
BFE>>Хорошо бы ещё знать, какие из мест следует считать сомнительными...
E>Ну назови, для примера пять мест, где выбор неочевиден...

Вот так вот 5 сразу я не приведу.
Вот из текущей работы. Ширина картинки (изображения) — это unsigned или signed int?

E>>>А зачем там был unsigned int, а не int64?
BFE>>для скорости и экономии места. Да и внешний интерфейс был ограничен unsigned int.
E>Зачем?
А что, надо было int64 выдавать выдавать наружу?

BFE>> Было (давно это было), типа такого: надо написать то-то и то-то. Напиши спецификацию и имплементируй её. А на основе спецификации мы тут наймём технического редактора, он help для пользователей напишет. Вот такое ТЗ от американского босса, которого я никогда в живую не видел и с которым никогда не встречался, хотя работал на него много лет.
E>Прекрасное ТЗ. Знаковость индекса можно выбирать любую...
E>(И интересно посмотреть на место с битиком, тоже.)

И был выбран unsigned int. Просто из соображений — не ограничивать интерфейс. И это спасло от переделки интерфейса, когда появились пользователи захотевшие отображать данные из базы, где индексы оказались (вдруг) unsigned int.

Здравствуйте, Erop, Вы писали:

BFE>>Собственно из за того, что 3a) сделан беззнаковым для стандартных контейнеров весь спор.
E>Даже там оно так непослеовательно сделано... Когда индексируешь вектор, то беззнаковое, а когда итератор произвольного доступа, то вроде бы знаковое...
E>Или ты и difference_type за беззнаковое держишь?
Я крайне редко использую разницу между указателями. И обычно я знаю какой из итераторов больше.

E>В любом случае, нужда, которую решили цовлетворить в std, когда выбирали беззнаковый индекс массива, не особо-то нужная...
E>Вообще весь std::vector плохо спроектирован очень много лет назад. Чего на него ориентироваться?
Потому, что это стандарт :

Здравствуйте, B0FEE664, Вы писали:

BFE>Вот из текущей работы. Ширина картинки (изображения) — это unsigned или signed int?

что такое "картинка"? И в чём ширина? В пикселах?
Если в пикседлах, то это вообще больгше на short похоже. Так что int32 должно хватать, по идее...

BFE>И был выбран unsigned int. Просто из соображений — не ограничивать интерфейс. И это спасло от переделки интерфейса, когда появились пользователи захотевшие отображать данные из базы, где индексы оказались (вдруг) unsigned int.

А что делали пользователи, у которых индексы вдруг int оказались?

Здравствуйте, Erop, Вы писали:

BFE>>Вот из текущей работы. Ширина картинки (изображения) — это unsigned или signed int?
E>что такое "картинка"?
Ну, кадр из фильма, например. Но не обязательно. Может быть фото.

E>И в чём ширина? В пикселах?
Да.

E>Если в пикседлах, то это вообще больгше на short похоже. Так что int32 должно хватать, по идее...
Вот и мне придумать гипотетическую ситуацию, когда картинка больше 400 000 000 пикселей в ширину не удалось, а в библиотеке, что мы используем ширина объявлена как uint32_t, при этом размер под буффер изображения — uint64_t. И встаёт закономерный вопрос, то ли это авторы библиотеки не подумали, то ли я не понимаю всех возможных трансформаций над изображением, которые эта библиотека может сделать... В целом эта библиотека служит для склеивания изображений с нескольких камер, но результат-то всё равно на чём-то надо смотреть... и обычного int должно хватить. Но ведь размер картинки не может быть отрицательным. Зачем тогда int32 ?
Вот примерно так же я рассуждал, когда делал выбор для своей библиотеки:
BFE>>И был выбран unsigned int. Просто из соображений — не ограничивать интерфейс. И это спасло от переделки интерфейса, когда появились пользователи захотевшие отображать данные из базы, где индексы оказались (вдруг) unsigned int.
E>А что делали пользователи, у которых индексы вдруг int оказались?
Не знаю. Не жаловались

А вообще-то, индекс и размер чего-либо — это два разных типа (количество и указатель), и то, что при реализации используются встроенные типы — в корне не верно. Видимо правильный (общий) подход такой: надо завести три типа индекс (он же итератор), размер (он же количество) и смещение (он же difference_type). Определить операции преобразование одного в другой. И если так сделать, то... обретёшь проблемы взаимопонимания с коллегами.

Здравствуйте, B0FEE664, Вы писали:

BFE>Вот и мне придумать гипотетическую ситуацию, когда картинка больше 400 000 000 пикселей в ширину не удалось, а в библиотеке, что мы используем ширина объявлена как uint32_t, при этом размер под буффер изображения — uint64_t. И встаёт закономерный вопрос, то ли это авторы библиотеки не подумали, то ли я не понимаю всех возможных трансформаций над изображением, которые эта библиотека может сделать...

Скорее всего они это сделали "просто так".
Мао того, я не удивлюсь, что на картинках с шириной больше 0х80000000 они лажают

BFE>В целом эта библиотека служит для склеивания изображений с нескольких камер, но результат-то всё равно на чём-то надо смотреть... и обычного int должно хватить. Но ведь размер картинки не может быть отрицательным. Зачем тогда int32 ?
Чтобы можно было написать

assert( width > 0 );

E>>А что делали пользователи, у которых индексы вдруг int оказались?
BFE>Не знаю. Не жаловались

А может и те не жаловались бы?

BFE>А вообще-то, индекс и размер чего-либо — это два разных типа (количество и указатель), и то, что при реализации используются встроенные типы — в корне не верно. Видимо правильный (общий) подход такой: надо завести три типа индекс (он же итератор), размер (он же количество) и смещение (он же difference_type). Определить операции преобразование одного в другой. И если так сделать, то... обретёшь проблемы взаимопонимания с коллегами.

Гланое, что совершенно не понятно в чём цель всех этих строгостей.
На поверку это всё числа. Зачем усложнять дальше?

Здравствуйте, B0FEE664, Вы писали:

E>>Даже там оно так непоследовательно сделано... Когда индексируешь вектор, то беззнаковое, а когда итератор произвольного доступа, то вроде бы знаковое...
E>>Или ты и difference_type за беззнаковое держишь?
BFE>Я крайне редко использую разницу между указателями. И обычно я знаю какой из итераторов больше.

При чём тут ты и STL? Я про то, что в

std:vector<char> arr(mySize);
char& r1 = arr[myPos]; // (1)
char& r2 = arr.begin()[myPos]; // (2)

(1) и (2) не эквивлентны, если для mtPos важна знаковость...
Так что реальных гарантий, в математическом смысле, STL-код всё рвно не даёт. Там, конечно, везде нарисованы unsigned, но если ты начнёшь этот "запасной" битик реально юзать, то имеешь большие шансы таки нарваться...

BFE>Потому, что это стандарт :
И что с того? Это же стандарт наа библиотеку, а не на образ мысли?

Здравствуйте, Erop, Вы писали:

E>У тебя просто какие-то проблемы с разрядностью целых.
E>Смотри, если ты о 16-разрядных платформах, то, во-первых законодательство РФ запрещает это обсуждать в открытых источниках,

Настоящий джентльмен всегда сможет высказаться о 16-разрядных платформах, не прибегая к терминологии, не разрешённой в открытых источниках.

E> а, во-вторых, кроссплатформенность там не нужна, и не возможна, к тому же. Так как нужн другие данные и алгоритмы.

Простите, этого не понял. Вот у меня программа на Си, написанная для установки с 80186 в "сердце" управления. Какой святой дух запретит мне переносить её, например, на Cortex?

Или Вы имели в виду что-то уж совсем специфическое?

E>А если мы от 32/64 говорим, то нужно целых три целых, ну, на крайняк 4

E>1) 32-битное знаковое
E>2) 64-битное знаковое
E>3) целое, в которое можно затолкать указатель (но это уже почти никогда не нужно)
E>3а) знаковое целое в которое можно класть индекс массива в памяти (но это уже совсем никогда не нужно)

Что-то не понял последнего — почему оно вдруг стало не нужно.

Здравствуйте, zaufi, Вы писали:

Z>что касается применения unsigned счетчиков в циклах, кроме "эстетических" соображений есть еще и вполне практический:
Z>http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html
Z>в данном руководстве утверждается, и есть мнение что не безосновательно , что применение unsigned типов идет только на пользу!
Z>в частности читать нужно со страницы 144 (абсолютный номер в этой PDF, а не по index'у): 3.4.2.2 Optimizing for Macro-fusion. и втыкать в частности пример на странице 146...

Во-первых, у этого правила "M impact, ML generality", то есть оно для достаточно специфического случая, а во-вторых — развёртка цикла даёт значительно больший результат по-любому, чем один сэкономленный такт на границе цикла. По-моему, оно не стоит того, чтобы за ним так гоняться и терять возможные другие положительные черты.

Здравствуйте, B0FEE664, Вы писали:

BFE>>> Было (давно это было), типа такого: надо написать то-то и то-то. Напиши спецификацию и имплементируй её. А на основе спецификации мы тут наймём технического редактора, он help для пользователей напишет. Вот такое ТЗ от американского босса, которого я никогда в живую не видел и с которым никогда не встречался, хотя работал на него много лет.
E>>Прекрасное ТЗ. Знаковость индекса можно выбирать любую...
E>>(И интересно посмотреть на место с битиком, тоже.)

BFE>И был выбран unsigned int. Просто из соображений — не ограничивать интерфейс. И это спасло от переделки интерфейса, когда появились пользователи захотевшие отображать данные из базы, где индексы оказались (вдруг) unsigned int.

Какой-то странный и редкий случай. Сейчас jIMHO вероятнее увидеть базу, у которой в индексе [u]int64_t, ибо ИНН, причём с префиксом пространства в старших битах...

Здравствуйте, netch80, Вы писали:

N>Настоящий джентльмен всегда сможет высказаться о 16-разрядных платформах, не прибегая к терминологии, не разрешённой в открытых источниках.

лично я на современном этапе встречал 16-битные камни только в таких местах, которые обсуждать в открытых источниках нельзя вовсе и не из-за терминологии...

N>Простите, этого не понял. Вот у меня программа на Си, написанная для установки с 80186 в "сердце" управления. Какой святой дух запретит мне переносить её, например, на Cortex?

Никакой не запретит. Вообще перенос 16-бит -> 32 бита не смертелен. Смертелен перенос обратно. Но он не бывает нужным...
То есть, если мы пишем 16-битный код, то мы всегда знаем про то, что он 16-битный. Очень мало шансов написать код, не зная о его битности, а потом он волшебным образом заработает на 16-битах, хотя по уму ему надо бы 32...

E>>1) 32-битное знаковое
E>>2) 64-битное знаковое
E>>3) целое, в которое можно затолкать указатель (но это уже почти никогда не нужно)
E>>3а) знаковое целое в которое можно класть индекс массива в памяти (но это уже совсем никогда не нужно)

N>Что-то не понял последнего — почему оно вдруг стало не нужно.
Потому, что обычно для индексов достаточно первых двух...

Здравствуйте, netch80, Вы писали:

N>Какой-то странный и редкий случай. Сейчас jIMHO вероятнее увидеть базу, у которой в индексе [u]int64_t, ибо ИНН, причём с префиксом пространства в старших битах...
Это давно было.