Re[6]: Счетчик цикла, итераторы - C/C++

Приветствую.

— Меня вот всегда удивляло, почему в качестве счетчика цикла, который будет использоваться в качестве индексации масива / контейнера, зачастую используется знаковая целочисленная переменная?

Нет, ну я понимаю, что size_t многим просто не нужен — пишу себе под 32 бита и буду писать, думают они.

А вот почему бы не написать unsigned int, к примеру — ума не приложу. Лень написать лишние буквы?

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

— Допустим, нам надо выделить два одинаковых по размеру куска памяти одного и того же типа.

Использовали бы стандартный вариант

int *a = new int [n];
int *b = new int [n];

или

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

вот такой?

Здравствуйте, Аноним, Вы писали:

А>А вот почему бы не написать unsigned int, к примеру — ума не приложу. Лень написать лишние буквы?

Попробуйте написать цикл с использованием unsigned int, который перебирает элементы массива в обратном порядке — от хвоста к голове.

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

BFE>Попробуйте написать цикл с использованием unsigned int, который перебирает элементы массива в обратном порядке — от хвоста к голове.

Стандартная идиома:

for (unsigned i = n; i --> 0 ;)
    std::cout << i << std::endl;

Здравствуйте, 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>Потому, что это стандарт

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

Здравствуйте, Аноним, Вы писали:

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

Если говорить о встроенной операции индексирования вообще, то согласно стандарту она сводится к сложению указателя с целым числом и последующим разыменованием. И точно так же, как и операция сложения указателя с целым числом, операция индексирования обладает свойством коммутативности. Так, для любых массива array и целочисленного индекса index следующие выражения являются эквивалентными:

*(array + index)
*(index + array)
array[index]
index[array]

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

Здравствуйте, Сыроежка, Вы писали:

С>Все подготовлено для for. Поэтому пишем

С>

С>for ( size_t n = N; n--; ) a[n] = n;
С>

Это неправильный for! Правильный должен иметь такую сруктуру

for( инициализация; проверка условия; сдвиг итератора )

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

Все проблемы лечатся, конечно, кодом вроде такого:

for( unsigned int i = N - 1; i < N; i -= STEP )

но я бы не назвал его интуитивно понятным...

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

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

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

BFE>>>Попробуйте написать цикл с использованием unsigned int, который перебирает элементы массива в обратном порядке — от хвоста к голове.
C>>Стандартная идиома:

C>>for (unsigned i = n; i --> 0 ;)
C>>    std::cout << i << std::endl;

BFE>Стандартная? А где массив?

Вот честное слово, не вижу разницы для иллюстративных целей — индексировать массив числами от 9 до 0 или выводить в стандартный вывод числа от 9 до 0.

22.02.12 10:42, Erop написав(ла):
> Здравствуйте, Сыроежка, Вы писали:
> С>Все подготовлено для for. Поэтому пишем
> С>

> С>for ( size_t n = N; n--; ) a[n] = n;
> С>

> Это неправильный for! Правильный должен иметь такую сруктуру

for( инициализация; проверка условия; сдвиг итератора )

Это неправильный for! Классический for имеет вид for переменная=начало to конец step шаг, а современный — for переменная in коллекция.

> Но, на самом деле, гемор начинается чуть позже, когда тебе надо поитерировать массив с конца и с шагом step.

И с начала итерируя с шагом можно пролететь.

Как ни странно, но на этот раз Сыроежка прав.

Posted via RSDN NNTP Server 2.1 beta

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

MOP>В том, что идиоматичная итерация по беззнаковому назад в C++ выглядит так.
IMHO, это while...

Он, кстати, так и написал на автомате

В любом случае, IMHO, цельная концепция выглядит так, что for в обе стороны пишется ОДИНАКОВО, а индекс используется знаковый...

for( int i = 0; i < N; i++ ){}
for( int i = N-1; i >= 0; i-- ){}

Но другие подходы тое применяются, конечно...

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

MOP>Давным-давно, когда int был 16-битным…

Даже тогда ловить биты было себе дороже.
Если это не какой-то сверх-быстрый код, то верным решением всегда было "взять int подлиннее",
Если тебе надо считать миллиарды -- бери 64-битный, если десятки тысяч -- 32-битный и будет тебе счастье.
А от того, что ты один битик добавишь, счатье будет вс равно очен ненадёжным...

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

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

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

Я крайне редко использую разницу между указателями. И обычно я знаю какой из итераторов больше.

E>В любом случае, нужда, которую решили цовлетворить в std, когда выбирали беззнаковый индекс массива, не особо-то нужная...

E>Вообще весь std::vector плохо спроектирован очень много лет назад. Чего на него ориентироваться?

Потому, что это стандарт

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

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

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

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

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

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

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

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

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

Здравствуйте, Аноним, Вы писали:

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

А>Использовали бы стандартный вариант

А>

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

А>или

А>

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

А>вот такой?

ни тот ни другой, стандартный вариант с динамикой ну ни как не связан:

  std::vector<int> a(n);
  std::vector<int> b(n);

Здравствуйте, Аноним, Вы писали:

А>Приветствую.

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

А>Нет, ну я понимаю, что size_t многим просто не нужен — пишу себе под 32 бита и буду писать, думают они.

А>А вот почему бы не написать unsigned int, к примеру — ума не приложу. Лень написать лишние буквы?

Здесь есть несколько факторов, которые влияют на это решение.
Во-первых, исторически так сложилось, что использовали тип int для счетчиков циклов, так как в С еще не существовало типа unsigned int. Этот тип появился позднее.
Во-вторых, есть некоторое противоречие. Дело в том, что разность между указателямми и итераторами, которую определяют, как имеющую тип difference_type, выражают через знаковый целочисленный тип, например, используют стандартный тип std::ptrdiff_t. В чем заключается противоречие? С одной стороны, обычно для всех контейнеров задают тип size_type как беззнаковый целочисленный тип. С другой стороны, разность между двумя указателями на элементы контейнера, которая как раз и определяет индекс элемента, задается как difference_type, то есть знаковый тип. То есть имеет место быть, что если n — это size_type, то есть беззанковый, то разность между элементами контейнера с прямым доступом, для которого память выделяется одним экстентом, &a[n] — &a[0] в общем случае не равна n. То есть в первом выражении мы получаем знаковое значение, а во втором беззнаковое, а знаковое не может представить в себе все значения беззнакового. Имеет место явное противоречие.

Это противоречие наглядно проявляется в объявление стандартных алгоритмов. Например, посмотрите объявление алгоритма count

template<class InputIterator, class T>
typename iterator_traits<InputIterator>::difference_type
count(InputIterator first, InputIterator last, const T& value);

С одной стороны вы его можете вызвать для массива, указав диапазон, как, [a, a + N), где N — это беззнаковое целое, как, например, size_t. А на выходе из вызова алгоритма вы получите уж знаковое значение, как, например, int.
Вот, чтобы избежать такого противоречия, программисты часто и используют знаковый тип в циклах.

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

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

А>Использовали бы стандартный вариант

А>

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

А>или

А>

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

А>вот такой?

Это плохой способ выделения памяти, так как кто-то может попытаться удалить указатель b, который не указывает на начало выделенной памяти, а потому это может привести к аварийному завершению программы. Так можно делать лишь в том случае, если вы самостоятельно разррабатываете системы выделения памяти для своей программы и, соответственно перегружаете операторы delete и delete[].

On 02/21/2012 10:59 PM, Аноним 226 wrote:

> — Меня вот всегда удивляло, почему в качестве счетчика цикла, который будет
> использоваться в качестве индексации масива / контейнера, зачастую используется
> знаковая целочисленная переменная?

Меня тоже. Поэтому использую всегда беззнаковые.

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

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

> — Допустим, нам надо выделить два одинаковых по размеру куска памяти одного и
> того же типа.
>
> Использовали бы стандартный вариант
>
> int *a =new int [n];
> int *b =new int [n];

Да, потому что не факт, что у них будет одинаковое время жизни (т.е. что их
удалять в одно и то же время).
Если будет, то надо делать из них структуру или массив.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Аноним, Вы писали:

А>А вот почему бы не написать unsigned int, к примеру — ума не приложу. Лень написать лишние буквы?

А зачем? Если разницы никакой — то да, лень.
А задачи, где разница есть, встречаются настолько редко, что далеко не каждому программисту хоть раз в жизни попадется.

Здравствуйте, Аноним, Вы писали:

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

Если можно индексом, то всегда перебираю индексом. Так короче писать.

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

BFE>Здравствуйте, Аноним, Вы писали:

А>>А вот почему бы не написать unsigned int, к примеру — ума не приложу. Лень написать лишние буквы?

BFE>Попробуйте написать цикл с использованием unsigned int, который перебирает элементы массива в обратном порядке — от хвоста к голове.

Это так сложно?!

const size_t N;
int a[N];

size_t n = N;
while ( n-- ) a[n] = n;

Всегда пишу unsigned int, ну т.е. не прям всегда, но когда переменная цикла служит только индесатором.

Здравствуйте, Сыроежка, Вы писали:

С>Это так сложно?!
С>

С>const size_t N;
С>int a[N];
С>size_t n = N;
С>while ( n-- ) a[n] = n;
С>

Так можно. Но это не цикл for, который был бы естественен здесь.

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

BFE>>Попробуйте написать цикл с использованием unsigned int, который перебирает элементы массива в обратном порядке — от хвоста к голове.
C>Стандартная идиома:

C>

C>for (unsigned i = n; i --> 0 ;)
C>    std::cout << i << std::endl;
C>

Стандартная? А где массив?

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

BFE>Здравствуйте, Сыроежка, Вы писали:

С>>Это так сложно?!
С>>

С>>const size_t N;
С>>int a[N];
С>>size_t n = N;
С>>while ( n-- ) a[n] = n;
С>>

BFE>Так можно. Но это не цикл for, который был бы естественен здесь.

Это что-то на вас сегодня погода плохо действует. На самом деле имеет место законченное предложение for. Я, кстати сказать, когда написал while, подумал, а почему я не использовал for? Да исправить не знал как.

Итак, мы имеем

size_t n = N;
while ( n-- ) a[n] = n;

Все подготовлено для for. Поэтому пишем

for ( size_t n = N; n--; ) a[n] = n;

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

E>Здравствуйте, Сыроежка, Вы писали:

С>>Все подготовлено для for. Поэтому пишем

С>>

С>>for ( size_t n = N; n--; ) a[n] = n;
С>>

E>Это неправильный for! Правильный должен иметь такую сруктуру

for( инициализация; проверка условия; сдвиг итератора )

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

for ( for-init-statement conditionopt; expressionopt) statement

Обратите внимание, что у элемента expression справа приписано opt, что означает optional, то есть необязательный.
Можно вообще писать предложение for в виде

for ( ;; ) statement;

E>Но, на самом деле, гемор начинается чуть позже, когда тебе надо поитерировать массив с конца и с шагом step.

E>Все проблемы лечатся, конечно, кодом вроде такого:

for( unsigned int i = N - 1; i < N; i -= STEP )

но я бы не назвал его интуитивно понятным...

E>Второй минус такого подхода -- он на итераторы не обобщается, но в итераторах и не надо ходить вниз, с другой стороны.

Кто вам сказал, что в итераторах не надо "ходить вниз"?! А как быть с алогритмом copy_backward, reverse и со всеми реверсивными итераторами?!

E>Но я вообще противник использования беззнаковых целых, без крайней на то нужды. Слишком легко допустить переполнение...

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

Здравствуйте, Сыроежка, Вы писали:

С>Это "неправильный for" только в вашей голове. Любой компилятор на это for не жалуется, так как конструкция написана в соответствии со стандартом, в котором предложение for определяется следующим образом

"Неправильный", в данном случае, обозначает "нечитабельный"...

С>Кто вам сказал, что в итераторах не надо "ходить вниз"?! А как быть с алогритмом copy_backward, reverse и со всеми реверсивными итераторами?!

Тот, кто рассказал об обратных иетраторах...

С>Без крайней нужды не следует использовать те типы, область значений которых не соответствует области используемых значений. То есть в циклах с индексом как раз без крайней нужды не слледует использовать знаковые типы, так как предполагается, что индекс не может иметь отрицательное значение.

Ну вот я считаю такой подход ошибочным. Аргументация -- слишком велик шанс допустить переполнение и не заметить этого. А какой смысл в твоём подходе? Что он даёт? ограничения же не проверяются?

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

BFE>>>>Попробуйте написать цикл с использованием unsigned int, который перебирает элементы массива в обратном порядке — от хвоста к голове.
C>>>Стандартная идиома:
C>

C>>>for (unsigned i = n; i --> 0 ;)
C>>>    std::cout << i << std::endl;
C>

BFE>>Стандартная? А где массив?
C>Вот честное слово, не вижу разницы для иллюстративных целей — индексировать массив числами от 9 до 0 или выводить в стандартный вывод числа от 9 до 0.

Я спрсоня не смог правильно прочитать это цикл. Извините.
Спасибо за конструкцию. Столько лет программирую, а не знал

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

MOP>Это неправильный for! Классический for имеет вид for переменная=начало to конец step шаг, а современный — for переменная in коллекция.

Мы ещё о С++,

MOP>Как ни странно, но на этот раз Сыроежка прав.

Прав в чём? В том, что надо везде тулить беззнаковые? Я тк не считаю.
И циклы for со сдвигами итератора в проверке условия мне тоже не нравятся...

22.02.12 14:04, Erop написав(ла):
> Здравствуйте, gegMOPO4, Вы писали:
> MOP>Это неправильный for! Классический for имеет вид for переменная=начало to конец step шаг, а современный — for переменная in коллекция.
> Мы ещё о С++,

Мы о for. В C for неправильный. Впрочем, можно и о C++. The range-based for statement.

> MOP>Как ни странно, но на этот раз Сыроежка прав.
> Прав в чём? В том, что надо везде тулить беззнаковые? Я тк не считаю.

В том, что идиоматичная итерация по беззнаковому назад в C++ выглядит так.

Posted via RSDN NNTP Server 2.1 beta

22.02.12 15:04, Erop написав(ла):
> Здравствуйте, gegMOPO4, Вы писали:
> MOP>В том, что идиоматичная итерация по беззнаковому назад в C++ выглядит так.
> IMHO, это while...

Да, напрасно в Си ввели такой for.

> В любом случае, IMHO, цельная концепция выглядит так, что for в обе стороны пишется ОДИНАКОВО, а индекс используется знаковый...

for( int i = 0; i<  N; i++ ){}
> for( int i = N-1; i>= 0; i-- ){}

Ну-ка, как посчитать от трёх миллиардов вниз на 32-битных целых? Детская ошибка.

Posted via RSDN NNTP Server 2.1 beta

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

MOP>Ну-ка, как посчитать от трёх миллиардов вниз на 32-битных целых? Детская ошибка.

Никак не надо считать так долго.
ы правда считаешь, что стоит бороться за этот битик? Особенно, когда речь идёт, например, об итерации массива интов?

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

MOP>Да, напрасно в Си ввели такой for.
Может быть, но маемо шо маемо.
У меня в команде, например, принято писать for'ы так, что изменения параметра цикла могут быть толко в соответствующей части for'а. А в теле или в условии параметр менять не нельзя. И это правда повышает читабельность. От for'ов не ждёшь всяки хитрых ходов...

23.02.12 00:00, Erop написав(ла):
> Здравствуйте, gegMOPO4, Вы писали:
> MOP>Ну-ка, как посчитать от трёх миллиардов вниз на 32-битных целых? Детская ошибка.
> Никак не надо считать так долго.
> ы правда считаешь, что стоит бороться за этот битик? Особенно, когда речь идёт, например, об итерации массива интов?

Давным-давно, когда int был 16-битным…

Posted via RSDN NNTP Server 2.1 beta

, что применение unsigned типов идет только на пользу!
в частности читать нужно со страницы 144 (абсолютный номер в этой PDF, а не по index'у): 3.4.2.2 Optimizing for Macro-fusion. и втыкать в частности пример на странице 146...

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

вот это зависит от того где будет находится данный код -- если внутри небольшого класса и lifetime обоих кусков будет одинаков, и наружу ничего "светиться" не будет, и есть требования по скорости\памяти -- отчего бы нет... во всех остальных случаях -- *НАХЕРНАДО*. (от этого кода за версту несет потенциальными проблемами)

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

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

хмм индекс массива иногда имеет смысл как знаковый и
бывает испрользуется при обработке массивов например

p[-1] p[-2] разумеется p это указатель а
не сам массив разумеется если индексировать сам массив
то знак бессмыслен поскольку он всегда ссылается на базу
а вот через указатель уже и знаковый индекс пригодится

сам пишу или int или UINT или size_t а вот unsigned int просто тупо лень больше букв
да и не нужно так как обрабатывается заведомо небольшой диапазон да и не припомню что бы надо было обрабатывать такие огромные диапазоны где бы int не хватило если это только не библиотека общего пользования которую надо делать с расчетом на максимальные нагрузки но такой код сильно отличается от того что мы пишем каждый день потому что в отличии от библиотеки общего пользования мы знаем предельные нагрузки и почти всегда хватает простого int выше крыши

согласен можно писать и unsigned int если не лень но смысла в этом не вижу

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

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

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

J>хмм индекс массива иногда имеет смысл как знаковый и
J>бывает испрользуется при обработке массивов например

J>p[-1] p[-2] разумеется p это указатель а
J>не сам массив разумеется если индексировать сам массив
J>то знак бессмыслен поскольку он всегда ссылается на базу
J>а вот через указатель уже и знаковый индекс пригодится

ну да, С++ позволяет кучу странных "фишек"... но никогда-НИКОГДА мне не нужно было иметь отрицательные индексы в массиве!

а кому нужно было на практике?? не чисто умозрительно-теоретически или из академического интереса -- а реально в "боевом коде"??
по моему такой код будет слегка выламывать моск читающему и поэтому должен быть отрефачен, а руки у написавшего должны болеть от побоев...
чем отрицательные индексы, могут быть лучше при обходе массива чем положительные, начинающиеся с конца??? (забудем на секундочку о существовании std::string::npos -- говорим об алгоритмах обхода элементов типа for_each)... могу допустить, что с небольшой вероятностью где-то во вселенной существует хитрющий (т.е. оч не простой!) алгоритм, оч требовательный к скорости\памяти, и потому заоптимизорованный по самое нибалуй, где это в принципе может встретиться -- но в "обычной жизни"

J>сам пишу или int или UINT или size_t а вот unsigned int просто тупо лень больше букв

ну для начала можно просто писать "unsigned" -- то что он int, в таком случае подразумевается... а во-вторых, может надо завести редактор приличный??? мой вот после нажатия 3х символов "uns" комплитит мне это в требуемый "unsigned"

-- поэтому для меня что "int", что "uns" -- все те же 3 буквы...

J>да и не нужно так как обрабатывается заведомо небольшой диапазон да и не припомню что бы надо было обрабатывать такие огромные диапазоны где бы int не хватило если это только не библиотека общего пользования которую надо делать с расчетом на максимальные нагрузки но такой код сильно отличается от того что мы пишем каждый день потому что в отличии от библиотеки общего пользования мы знаем предельные нагрузки и почти всегда хватает простого int выше крыши

да дело даже не в том, хватает или не хватает разрядности int/unsigned для хранения счетчика из 10ти элементов...

J>согласен можно писать и unsigned int если не лень но смысла в этом не вижу

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

ну и второй смысл, как я уже говорил, помочь компилятору сделать более эффективный код -- если применение unsigned вместо int в качестве счетчика сделает мой код чуть быстрее (НАХАЛЯВУ!), конечно надо использовать!... даже если бы не было у меня автокомплита все равно писал бы unsigned (нахера экономить на 10^-3 секунды в написании -- печатать быстро я научилсо давно уже -- мне не в лом!)

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

ну да, С++ позволяет кучу странных "фишек"... но никогда-НИКОГДА мне не нужно было иметь отрицательные индексы в массиве!

а кому нужно было на практике?? не чисто умозрительно-теоретически или из академического интереса -- а реально в "боевом коде"??
по моему такой код будет слегка выламывать моск читающему и поэтому должен быть отрефачен, а руки у написавшего должны болеть от побоев...
чем отрицательные индексы, могут быть лучше при обходе массива чем положительные, начинающиеся с конца??? (забудем на секундочку о существовании std::string::npos -- говорим об алгоритмах обхода элементов типа for_each)... могу допустить, что с небольшой вероятностью где-то во вселенной существует хитрющий (т.е. оч не простой!) алгоритм, оч требовательный к скорости\памяти, и потому заоптимизорованный по самое нибалуй, где это в принципе может встретиться -- но в "обычной жизни"

ну вот я использовал и не раз отрицательные индексы например
часто во время парсинга текста есть указатель p который скачет
по строке например после операции p = strstr вот теперь
нам надо проверить что предыдущий символ это например #
если нет делаем что то другое тогда в общем получается
такой код

p = strstr(text, 'magic pattern') 

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

иногда даже больше надо проверить не предшествующий а 2 — 3
символа до маски тогда получается такой код

p = strstr(text, 'magic pattern') 




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

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

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

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

ну и второй смысл, как я уже говорил, помочь компилятору сделать более эффективный код -- если применение unsigned вместо int в качестве счетчика сделает мой код чуть быстрее (НАХАЛЯВУ!), конечно надо использовать!... даже если бы не было у меня автокомплита все равно писал бы unsigned (нахера экономить на 10^-3 секунды в написании -- печатать быстро я научилсо давно уже -- мне не в лом!)

оптимизация можеть быть но честно я не готов работать за компилятор мне лень
и такое микроускорение в моих программах не самое главное

P.S кстати всех с праздником с Днем защитника отечества!

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

MOP>>Ну-ка, как посчитать от трёх миллиардов вниз на 32-битных целых? Детская ошибка.
E>Никак не надо считать так долго.
E>ы правда считаешь, что стоит бороться за этот битик? Особенно, когда речь идёт, например, об итерации массива интов?

Тут дело не в битиках, а в том, что стандартные контейнеры имеют размер выраженный через size_t. А ходить по массиву с индексом диапазон которого меньше размера мне не нравится из идеологических соображений. Поэтому я перешёл на итераторы.

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

J>ну вот я использовал и не раз отрицательные индексы например
J>часто во время парсинга текста есть указатель p который скачет
J>по строке например после операции p = strstr вот теперь
J>нам надо проверить что предыдущий символ это например #
J>если нет делаем что то другое тогда в общем получается
J>такой код

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

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

за пределы диапазона вылететь не боишься?

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

NB>за пределы диапазона вылететь не боишься?

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

p = strstr(text, 'magic pattern') 

if (p != text)

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


p = strstr(text, 'magic pattern') 

if (p - text >= 3)


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

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

BFE>Тут дело не в битиках, а в том, что стандартные контейнеры имеют размер выраженный через size_t. А ходить по массиву с индексом диапазон которого меньше размера мне не нравится из идеологических соображений. Поэтому я перешёл на итераторы.

Это же формальность? этот самый size_t можно реалтзовать только в случе ОЧЕНЬ БОЛЬШОГО массива char'ов...

IMHO, это крайне редкая ситуация, и на std::vector, например, не реализуемая, из-за его плитики переаллокации, например...

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

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

BFE>>Тут дело не в битиках, а в том, что стандартные контейнеры имеют размер выраженный через size_t. А ходить по массиву с индексом диапазон которого меньше размера мне не нравится из идеологических соображений. Поэтому я перешёл на итераторы.

E>Это же формальность?
Разумеется. И следование формальным правилам — ценное качество для программиста.

E>этот самый size_t можно реалтзовать только в случе ОЧЕНЬ БОЛЬШОГО массива char'ов...

E>IMHO, это крайне редкая ситуация, и на std::vector, например, не реализуемая, из-за его плитики переаллокации, например...

Ситуация редкая, но и память нынче дешевая. Что мешает написать:

 try{ 
   std::vector v;
   v.reserv(N);// N - беззнаковое целое прочитанное из первого поля файла данных, возможно результат
               // сериализации, которая учитывает размер поля на данной архитектуре "забив" на совместимость формата файлов.
 }
 catch (std::length_error& le) {
     cerr << "Size Matters! It is too large!";
 }

особенно если учесть, что часто оставляют int тридцатидвухбитным даже на 64-битной архитектуре.

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

E>>Это же формальность?
BFE>Разумеется. И следование формальным правилам — ценное качество для программиста.
Ценное качество для любого инженера, в том числе и программиста -- думать головой и понимать что зачем и почему именно так он делает...
В данном случае имеет место быть размен — ошибки переполнения около нуля, против ошибок переполнения около бесконечности.
Ноль дрстижим всегда, а бесконечность, наоборот, удобно сделать недостижимой, правильно выбрав разрядность целых.

BFE>Ситуация редкая, но и память нынче дешевая. Что мешает написать:

BFE>

BFE> try{ 
BFE>   std::vector v;
BFE>   v.reserv(N);// N - беззнаковое целое прочитанное из первого поля файла данных, возможно результат
BFE>               // сериализации, которая учитывает размер поля на данной архитектуре "забив" на совместимость формата файлов.
BFE> }
BFE> catch (std::length_error& le) {
BFE>     cerr << "Size Matters! It is too large!";
BFE> }
BFE>

адресного пространства не хватит. Этомесли мы всё ещё о size_t...
Мало того, Нормальная программа должна бы, прочитав N из файла, проверить его, как минимум на неотрицательность...

BFE>особенно если учесть, что часто оставляют int тридцатидвухбитным даже на 64-битной архитектуре.

Это ещё больше намекает нам, что даже 32-битный int на практике переполнить трудно. но если таКой шанс есть, то надо брать не беззнаковую версию, а 64-битную!

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

E>>>Это же формальность?
BFE>>Разумеется. И следование формальным правилам — ценное качество для программиста.
E>Ценное качество для любого инженера, в том числе и программиста -- думать головой и понимать что зачем и почему именно так он делает...
E>В данном случае имеет место быть размен — ошибки переполнения около нуля, против ошибок переполнения около бесконечности.
Для беззанаковых целых в С++ переполнения не бывает (в отличии от знаковых).
Если же говорить об ошибках допускаемых на крайних значениях, то их одинаково легко допустить для любого типа.

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

BFE>>Ситуация редкая, но и память нынче дешевая. Что мешает написать:
BFE>> v.reserv(N);// N — беззнаковое целое прочитанное из первого поля файла данных
E>адресного пространства не хватит. Этомесли мы всё ещё о size_t...
Может, да. А может и хватить.

E>Мало того, Нормальная программа должна бы, прочитав N из файла, проверить его, как минимум на неотрицательность...
это беззнаковое-то число?

BFE>>особенно если учесть, что часто оставляют int тридцатидвухбитным даже на 64-битной архитектуре.
E>Это ещё больше намекает нам, что даже 32-битный int на практике переполнить трудно.
Да, но ещё и потому, что "старый" код часто завязан на эту размерность.

E>но если таКой шанс есть, то надо брать не беззнаковую версию, а 64-битную!
И тут начинаются пляски с define'ами для подбора правильного int под размер данной платформы.

Здравствуйте, 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>

Здравствуйте, Аноним, Вы писали:
А>Приветствую.
А>- Меня вот всегда удивляло, почему в качестве счетчика цикла, который будет использоваться в качестве индексации масива / контейнера, зачастую используется знаковая целочисленная переменная?
потому что 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>>

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

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

Здравствуйте, 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). Определить операции преобразование одного в другой. И если так сделать, то... обретёшь проблемы взаимопонимания с коллегами.

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

Здравствуйте, 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>>>

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, ибо ИНН, причём с префиксом пространства в старших битах...
Это давно было.

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

E>>>Даже там оно так непоследовательно сделано... Когда индексируешь вектор, то беззнаковое, а когда итератор произвольного доступа, то вроде бы знаковое...

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

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

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

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

(1) и (2) не эквивлентны, если для mtPos важна знаковость...

Вообще-то (если подумать) всё логично и последовательно. (1) — unsigned (2) — signed (при условии, что numeric_limits<size_t>::max() <= numeric_limits<difference_type>::max())

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

Я тут полез опять смотреть стандарт и узнал, что даже арифметика с обычными указателями не защищена от arithmetic overflow и undefined behavior (5.7/5 и 5.7/6).
Т.е. можно (теоретически) создать такой массив, что к некоторым элементам этого массива нельзя доступиться через arr[myPos] если myPos имеет тип std::ptrdiff_t. Более того, если вычесть указатель на первый элемент массива из указателя на последний элемент массива, то можно arithmetic overflow обрести. Впрочем, авторы стандарта за всё это безобразие перекладывают ответственность на плечи разработчиков компилятора.

BFE>>Потому, что это стандарт

:
E>И что с того? Это же стандарт наа библиотеку, а не на образ мысли?
Наl стандартом столько лет трудилось много умных людей. Почему бы не воспользоваться результатами этого труда, казалось бы.

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

BFE>Вообще-то (если подумать) всё логично и последовательно. (1) — unsigned (2) — signed
Только не поняятно, на кой эти все красоты тут нужны. Цель-то в чём? Поддержать массив длинной 0хС0000000? Так это сделать всё равно не удалось...

А то ведь, при таком подходе, надо вообще всем числам в программе приписать какие-то размерности и строго следить что какого типа объявлять. Но так обычно не делаают, и IMHO, правильно делают, что не делают

BFE>(при условии, что numeric_limits<size_t>::max() <= numeric_limits<difference_type>::max())

Ага-ага. И часто ты встречал реализации, где это усовие соблюдаеся?

BFE>Я тут полез опять смотреть стандарт и узнал, что даже арифметика с обычными указателями не защищена от arithmetic overflow и undefined behavior (5.7/5 и 5.7/6).
BFE>Т.е. можно (теоретически) создать такой массив, что к некоторым элементам этого массива нельзя доступиться через arr[myPos] если myPos имеет тип std::ptrdiff_t. Более того, если вычесть указатель на первый элемент массива из указателя на последний элемент массива, то можно arithmetic overflow обрести. Впрочем, авторы стандарта за всё это безобразие перекладывают ответственность на плечи разработчиков компилятора.

Дык вся идея с беззнаковым size_t и погоней за битиком, изначально была тухлая и нежизненная...

BFE>Над стандартом столько лет трудилось много умных людей. Почему бы не воспользоваться результатами этого труда, казалось бы.
Ну, уж в чём, в чём, а в области древних частей стандартной библиотеки, таких как потоки или size_t, С++ является редкостным уродом...

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

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

BFE>>Вообще-то (если подумать) всё логично и последовательно. (1) — unsigned (2) — signed
E>Только не поняятно, на кой эти все красоты тут нужны.

Это "идеологически верно".

E>Цель-то в чём? Поддержать массив длинной 0хС0000000? Так это сделать всё равно не удалось...

Цель, видимо, указать, что это принципиально два разных типа: размер не может быть отрицательным, в отличии от смещения.

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

BFE>Это "идеологически верно".

Эти слова не значат вообще ничего.
Можешь хоть как-то обрисовать профит?

E>>Цель-то в чём? Поддержать массив длинной 0хС0000000? Так это сделать всё равно не удалось...

BFE>Цель, видимо, указать, что это принципиально два разных типа: размер не может быть отрицательным, в отличии от смещения.

Зачем это указывать? Почему, например, для синусов не заводят тип "целое с плавающей точкой от -1 до 1", а для sizeof'а заводят таки специальный size_t?

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

BFE>>Это "идеологически верно".

E>Эти слова не значат вообще ничего.
E>Можешь хоть как-то обрисовать профит?

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

E>>>Цель-то в чём? Поддержать массив длинной 0хС0000000? Так это сделать всё равно не удалось...

BFE>>Цель, видимо, указать, что это принципиально два разных типа: размер не может быть отрицательным, в отличии от смещения.
E>Зачем это указывать?

Для ясного понимания.

E>Почему, например, для синусов не заводят тип "целое с плавающей точкой от -1 до 1",

Целое с плавающей точкой ? Это как?

Почему не заводят? Некоторые заводят. Причём это может быть сделано из двух разных соображений:
1) для ленивых вычислений
2) для увеличения точности — число с фиксированной точкой от -1 до 1

Но на практике такое встречается редко.

E>а для sizeof'а заводят таки специальный size_t?

видимо, чтобы не ограничивать возможность реализации "лишними" соглашениями

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

BFE>>>Цель, видимо, указать, что это принципиально два разных типа: размер не может быть отрицательным, в отличии от смещения.
E>>Зачем это указывать?

BFE>Для ясного понимания.
Для ясного понимания чего?
Вот зачем показывать, что число std::end( array ) — std::begin( array )
и число size( array ) -- это одинаковые значения разных типов?

BFE>

Целое с плавающей точкой ? Это как?
Это так число из интервала [-1.0, 1.0]

E>>а для sizeof'а заводят таки специальный size_t?

BFE>видимо, чтобы не ограничивать возможность реализации "лишними" соглашениями

Этого совсем не понял. Так что там с разницой конца и начала массива? Она не обязана быть равна size, или что?

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

BFE>>>>Цель, видимо, указать, что это принципиально два разных типа: размер не может быть отрицательным, в отличии от смещения.
E>>>Зачем это указывать?
BFE>>Для ясного понимания.
E>Для ясного понимания чего?
E>Вот зачем показывать, что число std::end( array ) — std::begin( array )
E>и число size( array ) -- это одинаковые значения разных типов?

Немного философии: бывают некоторые координаты в неком пространстве, пара координат задаёт вектор, длинна вектора неотрицательна...
Короче, разница двух индексов это не то же самое, что индекс. Разница двух индексов — это, по сути, вектор (так как важен порядок). А вот модуль этого вектора — длинна.
Индекс, разница двух индексов, модуль разности двух индексов — это три разных типа: итератор, difference_type, size_t.

BFE>>

Целое с плавающей точкой ? Это как?
E>Это так число из интервала [-1.0, 1.0]

Их там целых три?

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

А>>- Меня вот всегда удивляло, почему в качестве счетчика цикла, который будет использоваться в качестве индексации масива / контейнера, зачастую используется знаковая целочисленная переменная?
А>>Нет, ну я понимаю, что size_t многим просто не нужен — пишу себе под 32 бита и буду писать, думают они.

M>Есть у size_t одна неприятность, когда это возвращаемое значение и нам надо вернуть еще признак ошибки. В случае знакового целого я верну -1 и не буду париться. Поэтому есть size_t, а есть ssize_t. А еще, бывает, надо из одного size_t вычесть другой, где отрицательный результат тоже имеет смысл.

У меня тут на днях, грубо говоря, неприятность случилась. Обнаружили, что там, где мы раньше просто передавали счётчик в 8 байтах, надо передавать ещё два значения — типа "ошибка снятия" и "отсутствие источника". Расширять некуда — грубо говоря, это embedded, протоколы и форматы в общем установлены. Но параметры не так быстро растут, чтобы переполнить 64 бита.
Так что выдвинул на внутреннее обсуждение предложение: "на ходу" сократить его до 63 бит, а случай старшего бита равного 1 применить на спец-значения. Вот жду до понедельника, будут ли фатальные возражения... По сути тут как раз и получилась замена беззнакового типа на знаковый.
Чувствую себя сотрудником Microsoft — согласно уровню извращений — заказчикам тоже придётся перестраиваться (хоть и не срочно).

M>Имхо, беззнакомый size_t это наследие 16-битных платформ, в частности DOS. Тут жертвуя старшим битом мы из 64k получаем 32k, что ощутимо неприятно. Уже на 32-битных платформах разница межу 2G и 4G не играет большой роли. Ситуация, когда надо именно 3G, но при этом заведомо меньше 4G, экзотична. А в случае 64-бит пожертвовать одним битом еще более не жалко. Отрицательные числа их же не зря ввели, они естественных образом получаются из целых.

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

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

(BTW, странно, что для поддержки длинной арифметики нет функции типа {a,b} -> {carry,sum} в стандартной библиотеке. В Verilog она есть.)

M>Беззнаковые хороши для битовый масок, когда операции сложения и вычитания используются только во всяких битовых хаках а-ля (x^(x-1)+1)>>1 при которых результат остается беззнаковым. Вообще, для таких случае рулят модульные типы Ada.

Я что-то не вижу, чем они "рулят". Они выглядят точно так же как сишные беззнаковые целые со всей их неуправляемостью.
Вот если бы Вы сказали про типы, для которых, например, 65535+1 генерировало бы исключение переполнения — тогда да, "рулят", потому что дают что-то новое по сравнению с текущей реализацией.
Сейчас, чтобы сделать такое эффективно, приходится придумывать аццкий бутерброд из ассемблера и C++.

	От:	MasterZiv
	Дата:	22.02.12 09:49
	Оценка:

От:	Mystic	http://mystic2000.newmail.ru
Дата:	06.03.12 11:28
Оценка:	+3

	От:	Аноним
	Дата:	21.02.12 18:59
	Оценка:

	От:	B0FEE664
	Дата:	22.02.12 00:10
	Оценка:	+2

	От:	Centaur
	Дата:	22.02.12 07:23
	Оценка:	8 (1)

От:	netch80	http://netch80.dreamwidth.org/
Дата:	28.02.12 05:58
Оценка:

	От:	Сыроежка
	Дата:	21.02.12 19:41
	Оценка:

От:	johny5	https://www.facebook.com/TachyonWars/
Дата:	24.02.12 06:35
Оценка: