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

E>Я пользуюсь библиотекой, которую ты скорее всего не знаешь. Она чем-то похожа на MFC в области коллекций. Sort там реализован, а остальное вроде как бывает нужно крайне редко.
Название у библиотеки имеются? URL?

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

E>>И ещё меня, допустим, удивляет реализация CArray, где метод GetSize() возвращает int.
ПС>Это перестанет удивлять после дня, потраченного на поиск ошибки из-за беззнаковой арифметики.
Нахождение подобной ошибки ИМХО означает что "тут писали не подумав". Да и к слову находится она очень быстро по причине получающихся огромных значений которые мало того, что означают переполнение так и отслеживаются на ура.

ПС>За что? За то, что направляет новичков на грабли (беззнаковая арифметика)?
"И опыт, сын ошибок трудных"

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

E>Что-то мне подсказывает, что он таки столкнулся с переполнением, при попытке взыскать долг
Ага. И выдал мудрецу -1 зерно

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

RO>Как эту задачу решить правильно, я затрудняюсь сказать. В псевдокоде она решается одной строчкой:
RO>unsigned f(unsigned n, int s)
RO>{
RO> return s % n;
RO>}

Не вникал в задачу
ответ "наугад", можно сказать по интуиции

unsigned f(unsigned n, int s)
{
  return (s+n) % n;
}

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

E>И что? На каждый результат каждого действия писать другой тип?
E>Это же дополнительная работа программиста. Дополгнительное время.

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

Автор: CrystaX
Дата: 21.11.05

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

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

В целом я бы при таком переносе действовал так:

1) Мспользовал бы всюду вместо int мой тип, который в разных версиях программы можно превратить в long, int или специальный тип, типа int с контролем корректности.

2) Запустил бы какую-то тестовую выборку запросов и подобрал бы параметры так, чтобы запрос был типовым, а переполнений не было (места, где переполнения на типовом запросе неизбежны, по любому надо сделать long )

3) Откомпилил бы версию, в котрой int'ы остались int'ами и попрофилировал бы её на том самом "типовом, но беспроблемном" запросе.

4) Потмо откомпилил бы так, чтобы int'ы были long и тоже попрофилировал бы.

5) Сравнивая профили из 3 и из 4 переписал бы руками критичные места, производительность котоорых пострадала (это не только из-а int-long может бытьно и из-за многих других причин)


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

Могу посоветовать только учить С... дабы понимать что к чему и зачем.

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

По этому поводу я думаю, что:
а) понятно, что все проблемы возникают от того, что арифметика с конечной разрядностью существенно отличается от школьльной. При этом, в общем-то, unsigned и signed примерно одинаково плохи.
б) просто unsigned придвигает опасную границу близко к привычным нам числам. Если "три миллиарда" встречаются в основном в архиваторах и прочих софтах, работающих с массивами данных, то 0+- лапоть у нас на каждом шагу.
в) язык программирования должен помогать программистам, а не мешать им.
г) вполне неплохим решением могла бы быть полноценная поддержка в арифметике чисел с бесконечной разрядностью.
д) Интуитивно ясно, что это бы привело к проблемам с производительностью. Хотя я в этом вовсе не уверен. Разве нельзя делать операцию сложения полиморфной, и автоматически переключаться в нужную разрядность как только произошло целое переполнение? Вполне может оказаться, что производительность этого дела на современных CPU устроит всех потребителей. Надо ковыряться в деталях, смотреть на конкретный asm-код и особенности работы предсказателя переходов.
е) Другой альтернативой является checked арифметика, где после каждой операции проверяется бит переполнения. Штука тоже дорогая, но может оказаться дешевле, чем то же самое, но написанное вручную.
Потому, как если вы собрались даже посчитать среднее от двух чисел, неважно, знаковых там или беззнаковых, то банальное (a + b) / 2 не проконает. Нужно
— или обкладывать параметры проверкой на переполнение
— или расширять до следующей разрядности (что не всегда возможно)
— или ловить переполнение постфактум и выполнять дополнительные приседания.

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

ПС>Здравствуйте, johny5, Вы писали:
J>>Хорошо, но вы согласны, что unsigned даёт просто больше декларативной информации чем int (целое и положительное vs целое)?
ПС>Да. Но, во-первых, эта декларативность не подкрепляется run-time-проверками (в широко используемых компиляторах).
ПС>Во-вторых, арифметика с unsigned int беззнаковая. В простых случаях (например, итерация массива в прямом порядке) беззнаковая арифметика не вызывает проблем. Но когда появляется беззнаковое вычитание, риск ошибиться возрастает (так как беззнаковая арифметика отличается от обычной в районе нуля). Беззнаковая арифметика — низкоуровневая техника. Она позволяет выжать из компьютера максимум (дополнительный бит), но за это приходится платить. Код с беззнаковой арифметикой хрупкий, подвержен ошибкам. От программиста требуется повышенное внимание/напряжение, иначе любое изменение кода может незаметно внести ошибку (которая проявляется только в граничном случае; например, когда vec.size() = 0). А вот код со знаковой арифметикой часто не содержит ошибок просто потому, что вычисляется именно то, что имел в виду программист.
Нет. Код со знаковой арифметикой как правило содержит ошибки, просто они редко проявляются. Я уже приводил пример вычисления среднего значения. Вот он:

int aver(int a, int b)
{
  return (a + b) / 2;
}

Он, конечно же, вычисляет именно то, что имел в виду программист. Но не всегда. Давайте посчитаем среднее от, к примеру, (2000000000 и 2000000000), а? Каждое число является вполне нормальным знаковым 32-х разрядным целым. Результат тоже. Но программист, наверное, имел в виду получить всё же 2000000000, а не -147483648, не так ли?

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

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

ПС>>А вот код со знаковой арифметикой часто не содержит ошибок просто потому, что вычисляется именно то, что имел в виду программист.
S>Нет. Код со знаковой арифметикой как правило содержит ошибки, просто они редко проявляются. Я уже приводил пример вычисления среднего значения. Вот он:
S>

S>int aver(int a, int b)
S>{
S>  return (a + b) / 2;
S>}
S>

S>Он, конечно же, вычисляет именно то, что имел в виду программист. Но не всегда. Давайте посчитаем среднее от, к примеру, (2000000000 и 2000000000), а? Каждое число является вполне нормальным знаковым 32-х разрядным целым. Результат тоже. Но программист, наверное, имел в виду получить всё же 2000000000, а не -147483648, не так ли?
Такой пример можно придумать для любого арифметического типа фиксированного размера (например, 32 бита), в том числе для unsigned int. Поэтому Ваш пример не относится к спору «знаковая арифметика vs. беззнаковая арифметика». Ваш пример относится к спору «фиксированная арифметика vs. динамическая арифметика».
Кстати, насколько я знаю, в языке Ruby целочисленная арифметика – динамическая.

S>В итоге, корректность кода обеспечивается, грубо говоря, тем, что в реальной жизни до двух миллиардов ни a ни b не дорастают. Ну или дорастают, где-то вылезает бяка, и в следующей версии продукта ее успешно чинят.
Да, но этому подвержена любая фиксированная арифметика – знаковая или беззнаковая.

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

ПС>Здравствуйте, Sinclair, Вы писали:

ПС>>>А вот код со знаковой арифметикой часто не содержит ошибок просто потому, что вычисляется именно то, что имел в виду программист.
S>>Нет. Код со знаковой арифметикой как правило содержит ошибки, просто они редко проявляются. Я уже приводил пример вычисления среднего значения. Вот он:
S>>

S>>int aver(int a, int b)
S>>{
S>>  return (a + b) / 2;
S>>}
S>>

S>>Он, конечно же, вычисляет именно то, что имел в виду программист. Но не всегда. Давайте посчитаем среднее от, к примеру, (2000000000 и 2000000000), а? Каждое число является вполне нормальным знаковым 32-х разрядным целым. Результат тоже. Но программист, наверное, имел в виду получить всё же 2000000000, а не -147483648, не так ли?
ПС>Такой пример можно придумать для любого арифметического типа фиксированного размера (например, 32 бита), в том числе для unsigned int. Поэтому Ваш пример не относится к спору «знаковая арифметика vs. беззнаковая арифметика». Ваш пример относится к спору «фиксированная арифметика vs. динамическая арифметика».
Мой пример относится к утверждению "вот код со знаковой арифметикой часто не содержит ошибок".

ПС>Да, но этому подвержена любая фиксированная арифметика – знаковая или беззнаковая.
Совершенно верно.

Здравствуйте, Sinclair, Вы писали:
ПС>>>>А вот код со знаковой арифметикой часто не содержит ошибок просто потому, что вычисляется именно то, что имел в виду программист.
S>>>Нет. Код со знаковой арифметикой как правило содержит ошибки, просто они редко проявляются. Я уже приводил пример вычисления среднего значения. Вот он:
S>>>

S>>>int aver(int a, int b)
S>>>{
S>>>  return (a + b) / 2;
S>>>}
S>>>

S>>>Он, конечно же, вычисляет именно то, что имел в виду программист. Но не всегда. Давайте посчитаем среднее от, к примеру, (2000000000 и 2000000000), а? Каждое число является вполне нормальным знаковым 32-х разрядным целым. Результат тоже. Но программист, наверное, имел в виду получить всё же 2000000000, а не -147483648, не так ли?
ПС>>Такой пример можно придумать для любого арифметического типа фиксированного размера (например, 32 бита), в том числе для unsigned int. Поэтому Ваш пример не относится к спору «знаковая арифметика vs. беззнаковая арифметика». Ваш пример относится к спору «фиксированная арифметика vs. динамическая арифметика».
S>Мой пример относится к утверждению "вот код со знаковой арифметикой часто не содержит ошибок".
По моим понятиям, функция aver не содержит ошибок. А числа порядка миллиарда – это большая экзотика. 32-битного int-а хватает почти всегда с хорошим запасом.

Здравствуйте, Пётр Седов, Вы писали:
S>>Мой пример относится к утверждению "вот код со знаковой арифметикой часто не содержит ошибок".
ПС>По моим понятиям, функция aver не содержит ошибок.
А можно пояснить эти понятия? По моим понятиям, aver(x, x) == x должно быть true для любого x.
Функция aver в данном варианте содержит малоприятный баг, который тем более опасен, что проявляется не всегда.

ПС> А числа порядка миллиарда – это большая экзотика. 32-битного int-а хватает почти всегда с хорошим запасом.
Для чего хватает?

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

S>Здравствуйте, Пётр Седов, Вы писали:
S>>>Мой пример относится к утверждению "вот код со знаковой арифметикой часто не содержит ошибок".
ПС>>По моим понятиям, функция aver не содержит ошибок.
S>А можно пояснить эти понятия? По моим понятиям, aver(x, x) == x должно быть true для любого x.
S>Функция aver в данном варианте содержит малоприятный баг, который тем более опасен, что проявляется не всегда.
Дело в том, что для знаковой арифметике проблема может быть решена, т.к. нужно контролировать только переполнение:

int aver(int a, int b)
{
  return (a & b) + ((a ^ b) >> 1);
}

А вот в signed/unsigned проблемы удваиваются, т.к. помимо signed проблем еще и проблема смешивания добавляется.

double Foo(unsigned int X,unsigned int Y, double D)
{
    return (X-Y)*D;
}

Хотя я лично считаю, что Sun зря не ввел unsigned хотя бы как несовместимый с signed тип, реализация низкоуровневых вещей получается ну очень многословной и с кучей грабель.

Здравствуйте, aka50, Вы писали:
A>Дело в том, что для знаковой арифметике проблема может быть решена, т.к. нужно контролировать только переполнение:
A>

A>int aver(int a, int b)
A>{
A>  return (a & b) + ((a ^ b) >> 1);
A>}
A>

Дело совершенно не в этом. Дело как раз в том, что вот такой простейший код делает совершенно не то, чего ожидал программист.
Починить его относительно нетрудно; но это нужно делать руками.

A>А вот в signed/unsigned проблемы удваиваются, т.к. помимо signed проблем еще и проблема смешивания добавляется.
Никакого удвоения не происходит. Это та же самая проблема выхода за диапазон. Просто диапазон другой.

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

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

A>>А вот в signed/unsigned проблемы удваиваются, т.к. помимо signed проблем еще и проблема смешивания добавляется.
S>Никакого удвоения не происходит. Это та же самая проблема выхода за диапазон. Просто диапазон другой.
Я имел ввиду неоднозначность преобразования. Что будет умножаться на signed double. unsigned int или signed int.

Здравствуйте, aka50, Вы писали:
A>Я имел ввиду неоднозначность преобразования. Что будет умножаться на signed double. unsigned int или signed int.
Всё однозначно: разность двух unsigned int – тоже unsigned int. Это называется «беззнаковое вычитание».
(Речь идёт о C/C++.)

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

ПС>>По моим понятиям, функция aver не содержит ошибок.
S>А можно пояснить эти понятия?
Если int – 32-битный, то его ограниченностью можно пренебречь (в большинстве случаев).

S>По моим понятиям, aver(x, x) == x должно быть true для любого x.
За такую строгость придётся дорого платить.

S>Функция aver в данном варианте содержит малоприятный баг, который тем более опасен, что проявляется не всегда.
Bug – это скорее свойство не функции, а программы. Например, функция aver может использоваться только для чисел 0 .. 100. Это можно выразить явно:

int aver(int a, int b)
{
  assert((0 <= a) && (a <= 100));
  assert((0 <= b) && (b <= 100));
  return (a + b) / 2;
}

Тогда ошибки нет даже по Вашим понятиям.

ПС>> А числа порядка миллиарда – это большая экзотика. 32-битного int-а хватает почти всегда с хорошим запасом.
S>Для чего хватает?
Для работы с целыми числами.

Здравствуйте, Пётр Седов, Вы писали:
ПС>За такую строгость придётся дорого платить.
С чего вы взяли, что за нестрогость придется платить дешевле?
S>>Функция aver в данном варианте содержит малоприятный баг, который тем более опасен, что проявляется не всегда.
ПС>Bug – это скорее свойство не функции, а программы.
Конечно же да! Но полагаться на "авось" — не лучший способ обеспечивать безошибочность программы.
ПС>Например, функция aver может использоваться только для чисел 0 .. 100. Это можно выразить явно:
Это нужно выражать явно. Иначе рано или поздно ракета упадет, а начисленная зарплата окажется отрицательной.
ПС>

ПС>int aver(int a, int b)
ПС>{
ПС>  assert((0 <= a) && (a <= 100));
ПС>  assert((0 <= b) && (b <= 100));
ПС>  return (a + b) / 2;
ПС>}
ПС>

ПС>Тогда ошибки нет даже по Вашим понятиям.
Совершенно верно. Но это — совсем другой код.
ПС>Для работы с целыми числами.
Ок. Если придете к нам на собеседование, не забудьте упомянуть об этой дискуссии.

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

CC>

CC>unsigned int i = count;
CC>while (i--)
CC>   do_somthing (i);
CC>

CC>Коротко и просто. Будет работать как для int так и для uint. В чем проблема то? Что то мне все больше кажется что в личной неприязни к unsigned.
Мало того, что это несколько нечитабельно, так ты ещё и невнимательно прочитал что хочется. Хочется итерировать с щагом...

скажем с шагом step...

CC>"Как? Ви не любите кошекЪ??? Та ви просто не умеете их готовить!!!" (С)