Общие вопросы по программированию (1302 стр)

Dmitry_Milk
> "сделай свой (у)инт_с_бесконечностью"
Нет, мой поинт как раз в том чтобы ничего лишнего не делать.

Dmitry_Milk
> в "этом нашем петухоне"-то как раз с этим все красиво и не сломается, и ничего придумывать не надо потому что:
Потому что в интерпретаторе питона все уже придумано за нас ;)

Dmitry_Milk
> плавучий +inf, который будет складываться/вычитаться с интами именно с таким поведением, какое мне и надо
Какой смысл складывать и вычитать из бесконечности, и главное, зачем для хранения бесконечности выделять избыточную память? Тут явно проблемы связанные с нарушениями логики программы, а не с возможностями языка/интерпретатора.

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

Dmitry_Milk
> инт безразмерный, сколько надо, столько и влезет
Так не должно быть, если мы говорим о чем-то, что измеряется в штуках. У тебя должен быть какой-то разумный диапазон для измерения их числа, после которого считается что штук очень много.
В сишке это достаточно просто реализуется путем выделения необходимого числа бит для хранения счетчика, и одного бита для признака бесконечности, в этом случае достаточно простой проверки на < 0.

Dmitry_Milk
> ок, я твою мысль понял. "Выбери в качестве бесконечности миллион.
Заведи для хранения поставщиков с бесконечным ресурсом отдельную структуру и тогда ваще ничего складывать и вычитать не нужно будет.

Dmitry_Milk
> Но это очень некошерный совет, даже хуже, чем использовать дабл для хранения интов.
Чем же он плох? просто обрезаешь по маске все, что не укладывается в выделенный диапазон и при этом выставляешь значащий бит в 1. Это все же лучше, чем использовать формат IEEE 754 не по назначению.

totoro
> У тебя должен быть какой-то разумный диапазон для измерения их числа, после которого считается что штук очень много.

"У Вас случайно нет брата в Питере?" Билл Гейтс Вам случайно не родственник? :)

totoro
> Заведи для хранения поставщиков с бесконечным ресурсом отдельную структуру

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

Dmitry_Milk
> А наличие специального значения в типе, обрабатываемого автоматически (процессором, в случае плавучки, или программной логикой реализации типа) избавляет от лишнего ручного кода.
А зачем оно надо? Код пишется не ради написания кода, а для того чтобы
а) быть эффективным
б) тебе и окружающим был максимально понятен смысл, который в него заложен

Ну сходил сначала в одну структурку, посмотрел, а там нет нужного поставшика. Ага, пошел в другую структурку, достал оттуда кол-во товара. Вроде все предельно прозрачно.

З.Ы.
Как вариант, можно вообще обойтись одной структурой, а признак неисчерпаемости ресурса зашить непосредственно в идентификатор поставщика, в виде того же специального бита ;)

totoro, ты забыл еще

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

Это, конечно связано с "максимально понятен", но не одно и то же.

totoro, впрочем, я подумал,  и согласен с тобой.

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

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

Dmitry_Milk
> Сложные условия, написанные вручную по собственным (а не компилятора) требованиям, эту вероятность увеличивают.
Перекладывание сколь-нибудь нетривиальной логики на плечи вычислительного устройства/интерпретатора эту вероятность еще больше увеличивает.

totoro
> Перекладывание сколь-нибудь нетривиальной логики на плечи вычислительного устройства/интерпретатора эту вероятность еще больше увеличивает.

Зависит от количества. Если много - то однозначно лучше переложить (даже несмотря на риск ошибки в реализации в устройстве/интерпретаторе), т.к. у человека страдает внимательность.

Dmitry_Milk
> Зависит от количества. Если много - то однозначно лучше переложить
Это ты сейчас в контексте метапрограмирования говоришь, это другое. Хотя я и такое не приветствую тоже. Шаблоны и статический полиморфизм уместны, но в меру.

Dmitry_Milk
> у человека страдает внимательность.
Ага, а потом гадай, что оно там за тебя навертело и во что развернулось.

totoro
> Ага, а потом гадай, что оно там за тебя навертело и во что развернулось.

Ага, а потом гадай, что где-то в одном из многих случаев выражение корректно написал, точку с запятой в конце поставил, но забыл перед выражением написать присваивание в переменную :)

Dmitry_Milk
> у человека страдает внимательность.
Прошивку для процессора, поди, не робот пишет, а условный ронника (а конпелятор, условный Тарас), так что человеческий фактор тоже не исключен. Оттуда, кстати, стало модно интринсины всякие просовывать наружу, чтоб обычные жалкие людишки тоже могли порулить железкой немного. Однако, если этим злоупотреблять, диатез может появиться, как у маленьких детей которые переели сладкого ;)

Да что ж такое ? :)
Опять виноват Тарас.