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

АТ>>Конечно, лучше! Вот только где бы найти такой оптимизатор... Т.е. ясно, что нет такого оптимизатора и быть не может, но все равно — лучше бы он...

E>А какие проблемы с принципиальным существованием такого оптимизатора?

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

E>Ведь в коде
E>

E>int i;
E>int size;
E>assert( 0 <= size );

E>if( 0 <= i && i < size ) {
E>    Do1();
E>}

E>if( unsigned( i ) < unsigned( size ) ) {
E>    Do2();
E>}
E>

E>Do1() и Do2() будут всегда вызываться одновременно.
E>Так что условия в if'ах совершенно эквивалентны.

Ну зачем же пытаться запутать участников дискуссии очевидно неверными утверждениями? Оба утверждения неверны и контрпример очевиден. Компилятор не имеет ни малейшего представления о реальном диапазоне значений 'i' и, соотвественно, не может быть уверен в том, что 'unsigned( i )' для отрицательных 'i' окажется заведомо больше 'unsigned( size )'. Поэтоум ожидать, что оптимизатор сумеет свести первое ко второму не приходится.

E>только первое условие понятнее.

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

E>О том, что в большинстве случаев это будет ещё и преждевременная оптимизация я скромно стараюсь не вспоминать

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

А я вот предпочитаю не делать первой ошибки вообще. Тогда и не надо будет вставлять в программу и "компенсаторы" этой ошибки. Ону просто будут не нужны. Удаление из кода соврешенно не нужных проверок, зачем-то туда засунутых — это не оптимизация, это банальное восттановление удобочитаемости и элегантности кода.

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

E>>Нет уж. Числа лучше бы использовать нормальные.
E>>И отлаживать проще и программировать и всё такое.

АТ>Не вижу в этом сообщении содержания. Соответственноо и ответить ничего содержательного не могу.

А писл-то зачем?


Видимо это была завуалированная просьба пояснить. Вот, пытаюсь:

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

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

А вдруг Вася разгильдяй. И иногда этот "рост" оказывается отрицательным?
Конечно можно напрячься, перенсти все члены во всех неравенствах в нужные стороны. Преобразовать все выражения как-то хитро и таки родить это всё на беззнаковой арифметике теки можно. не вопрос. толку-то только чуть. С простыми числами из математики так сказать проще.
Ну возникают отрицательные числа при работе с числовыми величинами естественным образм. Ну что с простым мат. фактом-то спорить?

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

АТ>>Неверно. 'atoi' и иже с ними — функции "мертвые" и практической ценности не представляющие.
E>А почему?

Интересно видеть, как пользователь Erop помечает сообщение через "выразить несогласие" и при этом одновременно задает вопрос "Почему?". На каком же основании Вы, уважаемый Erop, выражаете свое несогласие, не понимая при этом, о чем идет речь?

это просто разные типы данных. В одном случае знаковый 7-битный, в другом 8-битный.

Без второго большая часть известных библиотек практически нереализуема. Конкретный пример — нет ни одной ОС написанной на языках без безнаковых типов

Шахтер wrote:

> Речь идет не а выгодах. Речь идет о том, зачем вообще нужна беззнаковая
> арифметика (см. заглавную тему).
> Она нужна для решения огромного количества задач.
>
> Например, напиши struct IPHeader без беззнаковых типов. Или сделай
> алгоритм вычисления CRC (а так же SHA, DES, длинная арифметика и.т.п.).

Забавно, что без unsigned невозможно хранить в однобитовом члене 1. С signed
только -1 и 0.

#include <iostream>

int main()
{
     struct { int i : 1; } a = { 0 }, b = { 1 };
     std::cout << a.i << '\n' << b.i << '\n';
}

[max@k-pax test]$ bin/test
0
-1

--
Maxim Yegorushkin

No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own risk

Андрей Тарасевич wrote:

> Неверно. 'atoi' и иже с ними — функции "мертвые" и практической ценности
> не представляющие. Немножко "живее" — 'sscanf', который поддерживает
> unsigned, но и тот, к сожалению, неполноценен. Настоящие функции
> преобразования строк к целым из библиотеки С — 'strtol' и 'strtoul'
> (плюс 'll' версии в С99), из которых последняя как раз unsigned.

Чем sscanf неполноценен?

По крайней мере в gnu libc, sscanf использует strtoul(l). Было бы удивительно,
если бы другие реализации так же не поступали — обыкновенный code reuse.

http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/stdio-common/vfscanf.c?rev=1.115&content-type=text/x-cvsweb-markup&cvsroot=glibc

--
Maxim Yegorushkin

No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own risk

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

АТ>>>Неверно. 'atoi' и иже с ними — функции "мертвые" и практической ценности не представляющие.
E>>А почему?

АТ>Интересно видеть, как пользователь Erop помечает сообщение через "выразить несогласие" и при этом одновременно задает вопрос "Почему?". На каком же основании Вы, уважаемый Erop, выражаете свое несогласие, не понимая при этом, о чем идет речь?


Я не согласен, что atoi устарела больше, чем scanf, уважаемый эксперт Андрей
Мало того, твои аргументы меня так и не убедили

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

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

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

АТ>Есть такая полушутливая пословица "Если программа работает правильно, то это значит, что в ней содержится четное число ошибок". Вот этот пример кода выше — это как раз пример такой программы. Сначала был сделан ошибочный выбор в пользу знакового типа, а затем, чтобы "скомпенсировать" это ошибку, была добавлена еще одна — проверка значения [положительной по сути] знаковой переменной на отрицательность. В результате программа "работает".

АТ>А я вот предпочитаю не делать первой ошибки вообще. Тогда и не надо будет вставлять в программу и "компенсаторы" этой ошибки. Ону просто будут не нужны. Удаление из кода соврешенно не нужных проверок, зачем-то туда засунутых — это не оптимизация, это банальное восттановление удобочитаемости и элегантности кода.

Я уже не знаю, как тебе ещё объяснить, что если из числа что-то вычитается, то оно естественным образом может стать отрицательным?
Ну правда может

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

int step = 15;
for( int i = array.size() - 1; i >=0; i -= step )
    array[i] = i;

Тут всё хорошо понятно. Хотя при выходе из цикла i становится отрицательным.

А что ты будешь делать в случае unsigned?

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

L>Без второго большая часть известных библиотек практически нереализуема. Конкретный пример — нет ни одной ОС написанной на языках без безнаковых типов

Ну вопросы-то вызывает не использования беззнаковых целых в С++ для представления всяких странных объектов (наборов флажков, представления содержимого памяти, битовых масок, пикселей на экране и т. п.)

А в использовании беззнаковой арифметики, как более надёжной, наглядной и переносимой, например в задаче итерации массива от элементов с большим индексом к элементам с маленьким

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

E>Смотри, тебе уже тут наприводили вагон примеров.
E>Вот есть у тебя числовая величина. Скажем число деталей, которые произвёл сотрудник за месяц.
E>И не может эта штука быть отрицательной.

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

E>А вдруг Вася разгильдяй. И иногда этот "рост" оказывается отрицательным?
E>Конечно можно напрячься, перенсти все члены во всех неравенствах в нужные стороны. Преобразовать все выражения как-то хитро и таки родить это всё на беззнаковой арифметике теки можно. не вопрос. толку-то только чуть. С простыми числами из математики так сказать проще.
E>Ну возникают отрицательные числа при работе с числовыми величинами естественным образм. Ну что с простым мат. фактом-то спорить?

Стоп, стоп, стоп... Ты, по моему, пытаешья запутать участников дискуссии.

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

Итак, количество произведенных деталей отрицательным быть не может. Никаким естественным образом. Соответственно, для представления этих значений используется беззнаковый тип. Ранее ты утверждал, что эта величина для каких-то утилитарных целей (примеры с циклом и т.п.) должна иметь возможность принимать отрицательные значения. Теперь ты вдруг втихаря "перевел стрелки" с этой величины на совершенно и принципиально другую — разность между двумя такими значениями — и недеешся, что никто не заметит подмены? Сорри, это уже совсем другая песня.

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

Вот и все.

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

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

E>Я не согласен, что atoi устарела больше, чем scanf, уважаемый эксперт Андрей

Хм... Ты, по-видимому, невнимательно читаешь. Не в первый раз уже. Я никогда не утверждал, что "atoi устарела больше, чем scanf" (чем scanf??? ). Я утверждал, что 'atoi' устарела больше, чем 'strtol', если уж пользоваться не совсем подходящим в данном случае словом "устарела"...

E>Мало того, твои аргументы меня так и не убедили

"Не убедили"? Здесь не ромашка — убедили/не убедили. Аргументы против 'atoi' — формально строгие. Другими словами, бесполезность 'atoi' (и 'sscanf') для решения такой задачи в общем случае фактически констатируется стандартом языка. Так что никакого убедили/не убедили тут быть не может. Если у тебя есть какие-то фактические контраргументы — милости просим их сюда... А нет — значит вопрос решен.

E>Тем не менее, часто довольно бывает так, что лексический анализ текстового потока происходит в одном месте, а преобразование чисел представленных строками в числовое представление в другом

Во-первых, "лексический анализ потока" (за исключением совсем уже вырожденных случаев) не позволяет определить принадлежности представленного числа целевому диапазону — именно это является основной проблемой 'atoi'. (Я подозреваю, что для спасения 'atoi' в рамках это дискуссии найдутся люди, которые бы с удовольствием реализовали "лексический анализ потока", который будет принимать 32767 и отвергать 32768 не используя функций первода, но тем не менее ценность такой "лексический анализ" будет представлять не более чем юмористическую )

Во-вторых, функция 'atoi' сама по себе содержит внутри себя некий недоступный снаружи "лескический анализ". Попытка ручного "воспроизведения" такого анализа где-либо еще в коде — кривой и потенциально гемморойный подход, приемлемый только в вынужденнных случях. В разумной реализации как на этапе "лексического анализа", так и в процессе конверсии строки в число, должен работать один и тот же анализатор. Как раз таки функции типа 'strtol' и предосталяют такую возможность, пусть в ограниченной сепени.

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

АТ>Я подозреваю, что следующим шагом будет попытка убедить меня в том, что "очень легко ошибиться" при вычитании первого из второго, т.е. забыть перевести вычисления в рамки знаковых типов. Над подобными аргументами можно только посмеяться.

А почему?

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

А потом другая нужда может возникнуть: "Сколько бы сделал Петя в августе, если бы прирост производительности был, как в январе, а в июле он сделал 5732 детали?"

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

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


ME>Забавно, что без unsigned невозможно хранить в однобитовом члене 1. С signed
ME>только -1 и 0.

Ну это же всё хаки, обусловленные таким вот "удачным" определеним языка С++.

Ясно, что елси вы как-то хитро-прехитро пакуете данные и экономите каждый бит, то там нужны всяческие извраты и bit fields и unsigned и много чего ещё.

Но когда ты занимаешься просто какими-то вычислениями.
Скажем итерериуешь массив, возможно с какими-то пропусками, скажем.
Ну на кой вот с unsigned страдать гемором?

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


АТ>Хм... Ты, по-видимому, невнимательно читаешь. Не в первый раз уже. Я никогда не утверждал, что "atoi устарела больше, чем scanf" (чем scanf??? ). Я утверждал, что 'atoi' устарела больше, чем 'strtol', если уж пользоваться не совсем подходящим в данном случае словом "устарела"...

Неверно. 'atoi' и иже с ними — функции "мертвые" и практической ценности не представляющие. Немножко "живее" — 'sscanf', который поддерживает unsigned, но и тот, к сожалению, неполноценен.

Выделение -- моё. (С) -- тут :shuffle:

Автор: Андрей Тарасевич
Дата: 14.11.06

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

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

АТ>>Есть такая полушутливая пословица "Если программа работает правильно, то это значит, что в ней содержится четное число ошибок". Вот этот пример кода выше — это как раз пример такой программы. Сначала был сделан ошибочный выбор в пользу знакового типа, а затем, чтобы "скомпенсировать" это ошибку, была добавлена еще одна — проверка значения [положительной по сути] знаковой переменной на отрицательность. В результате программа "работает".

АТ>>А я вот предпочитаю не делать первой ошибки вообще. Тогда и не надо будет вставлять в программу и "компенсаторы" этой ошибки. Ону просто будут не нужны. Удаление из кода соврешенно не нужных проверок, зачем-то туда засунутых — это не оптимизация, это банальное восттановление удобочитаемости и элегантности кода.

E>Я уже не знаю, как тебе ещё объяснить, что если из числа что-то вычитается, то оно естественным образом может стать отрицательным?
E>Ну правда может

Я уж не знаю, как тебе объяснить, что из того, что 3 — 5 = -2, совсем не следует того, что из корзины с тремя апельсинами можно вынуть пять апельсинов (и при этом там останется -2 апельсина).

E>Вот смотри, очередная итерация массива сверху вниз (считай, что размер массива знаковый):

E>

E>int step = 15;
E>for( int i = array.size() - 1; i >=0; i -= step )
E>    array[i] = i;
E>

E>Тут всё хорошо понятно. Хотя при выходе из цикла i становится отрицательным.

E>А что ты будешь делать в случае unsigned?

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

unsigned step = 15;
for(unsigned i = array.size() - 1; i < array.size(); i -= step)
  array[i] = i;

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

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

unsigned step = 15;
for(unsigned i = array.size() + nstep - 1; i >= nstep; ) {
  i -= step;
  array[i] = i;
}

Это мне нравится больше.

А могу, под настроение, сделать даже так

if (array.size() > 0) {
  unsigned step = 15;
  for(unsigned i = array.size() - 1; ; i -= nstep) {
    array[i] = i;
    if (i < nstep)
      break;
  }
}

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

E>>Вот смотри, очередная итерация массива сверху вниз (считай, что размер массива знаковый):

E>>

E>>int step = 15;
E>>for( int i = array.size() - 1; i >=0; i -= step )
E>>    array[i] = i;
E>>

---

1)
АТ>

АТ>unsigned step = 15;
АТ>for(unsigned i = array.size() - 1; i < array.size(); i -= step)
АТ>  array[i] = i;
АТ>

2)
АТ>

АТ>unsigned step = 15;
АТ>for(unsigned i = array.size() + nstep - 1; i >= nstep; ) {
АТ>  i -= step;
АТ>  array[i] = i;
АТ>}
АТ>

3)
АТ>

АТ>if (array.size() > 0) {
АТ>  unsigned step = 15;
АТ>  for(unsigned i = array.size() - 1; ; i -= nstep) {
АТ>    array[i] = i;
АТ>    if (i < nstep)
АТ>      break;
АТ>  }
АТ>}
АТ>

---

Всё так.
Ты просто забыл указать какой имеено из вариантов 1, 2 или 3 читабельнее, компактнее и переносимее оригинального, со знаковой арифметикой?

Ну а что касется прмера с корзинами и апельсинами, то тебе сюда

Автор: k55
Дата: 22.11.05

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

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

Что касается флейма, то он, по-моему, "пошел" намного раньше и идет уже некоторое время — в первую очередь в заголовках Ваших сообщений.

АТ>>Хм... Ты, по-видимому, невнимательно читаешь. Не в первый раз уже. Я никогда не утверждал, что "atoi устарела больше, чем scanf" (чем scanf??? ). Я утверждал, что 'atoi' устарела больше, чем 'strtol', если уж пользоваться не совсем подходящим в данном случае словом "устарела"...

E>

E>Неверно. 'atoi' и иже с ними — функции "мертвые" и практической ценности не представляющие. Немножко "живее" — 'sscanf', который поддерживает unsigned, но и тот, к сожалению, неполноценен.

E>Выделение -- моё. (С) -- тут :shuffle:

Автор: Андрей Тарасевич
Дата: 14.11.06

Смысл, который я вкладывал в эту часть своего сообщения, заключается именно в том, что если 'sscanf' и "живее" 'atoi', то ненамного (см. выделенное Вами же слово "немножко"). Для устранения неоднозначностей я приписал дополнительно, что "и тот, к сожалению, неполноценен" (процитировано, но не выделено Вами). В непроцитированной же части моего сообщения сказано, что полноценными функциями преобразования являются функции групппы 'strto...'. По-моему, все это достаточно ясно из оригинального текста.

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

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

E>А в использовании беззнаковой арифметики, как более надёжной, наглядной и переносимой, например в задаче итерации массива от элементов с большим индексом к элементам с маленьким

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

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

ME>Забавно, что без unsigned невозможно хранить в однобитовом члене 1. С signed
ME>только -1 и 0.

Строго говоря, и в С и в С++ битовое поле, объявленное с типом просто 'int' может быть как signed, так и unsigned. Это implementation defined. Чтобы везде было именно signed, надо явно писать 'signed int'. Это, кажется, единственное место в С/С++, где просто 'int' может быть синонимом для 'unsigned int'.

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

>> Неверно. 'atoi' и иже с ними — функции "мертвые" и практической ценности
>> не представляющие. Немножко "живее" — 'sscanf', который поддерживает
>> unsigned, но и тот, к сожалению, неполноценен. Настоящие функции
>> преобразования строк к целым из библиотеки С — 'strtol' и 'strtoul'
>> (плюс 'll' версии в С99), из которых последняя как раз unsigned.

ME>Чем sscanf неполноценен?

Тем, что, согласно его спецификации, переполнение при переводе вызывает неопределеное поведение.

ME>По крайней мере в gnu libc, sscanf использует strtoul(l). Было бы удивительно,
ME>если бы другие реализации так же не поступали — обыкновенный code reuse.

Это разумно, но это деталь реализации.