Свежие комментарии

ну вот это малость меняет дело...

Светосильная оптика (а это фиксы) дает заметно более качественную картинку в отличие от темных зумов. Для очень большого количества фотографов, мало уделяющих внимания обработке, это единственная возможность качественно "вырасти". Но деньги есть не у всех, чтобы затариться фиксами покрывающими весь фокусный диапазон, вот и делают выбор в пользу одного-двух.
35-ка хороша тем, что "универсальна" как на кропе так и на ФФ. 135-й вот особо не подрос, т.к. достаточно узко применим.

Все ИМХО конечно.

Возможно все желающие купить 135/2 его уже купили (так как соотношение цена/качество именно этого стекла в линейке кенон IMHO экстремально),
а 35/1.4 хоть и крут, но сильно дороже и, наверняка, у многих стоял в wish-листе. Японию тряхнуло, люди психанули, поняли - надо таки брать. Вырос спрос - выросла цена.

согласен, это правильный workaround который уместно, и даже нужно использовать.
но это отнюдь не "хорошо во всех смыслах"

Пока мы имеем обратную ситуацию: появление истинного UB в линуксе сломало софт и, я гарантирую, сломает еще.
Удаление этого UB - починит софт. Правильное удаление (не вернуть копирование вперед, а memove) - починит много софта на много лет вперед.

Алиас memcpy на memmove не нарушает текущих писаных стандартов.

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

Если уж менять стандарт, то нужно всё-таки добавить функцию соответствующую сегодняшнему memcpy, то есть без проверки пересечения, и добавить к её имени суффикс _У_МЕНЯ_ПРЯМЫЕ_РУКИ . И пусть это проверка на сегодняшних машинах может и ничтожна, но можно представить ситуацию когда вносит весомый вклад (libc не только для x86). Например, будет супер память, в которой данные от одной ячейки непосредственно пойдут в другую, и само копирование будет происходить мгновенно.
Но блин, такие уступки будут ввести к засорению стандарта deprecated хлама (потом будет, _У_МЕНЯ_ТОЧНО_ПРЯМЫЕ_РУКИ, потом _У_МЕНЯ_ТОЧНО_ПРЯМЫЕ_РУКИ_И_РАСТУТ_НЕ_ИЗ_ЖОПЫ_И_Я_НЕ_ИНДУС, и т.д.).
Если не добавлять такую функцию, получится потеря изначальной гибкости(в стандарте!), из-за каких-то индусов.

Стандарт не меняется, а уточняется. Вот такое вот уточнение:
#define memcpy(a,b,c) memmove(a,b,c)
не нарушает существующего стандарта на memcpy никоим образом. И всем становится хорошо.

А ускорение, ради которого весь сыр-бор - внести в memmove в случай копирования непересекающихся регионов

В смысле стандарт менять?
Если не менять стандарт, а делать с определённым поведением, то это просто workaround. То есть грязная игра, но, естественно, продиктованная сильной необходимостью.. Я бы выбрал этот workaround, но это далеко не идеальное решение.

Да нет же. Хорошо - это сделать memcpy с определенным поведением. В точности как у memmove().

> Сейчас же - часто и хорошо.
и за это спасибо!

Да, я видел.

Но у предыдущей модели, 8000-й такой же вес, что навело меня на мысли. А русский сайт эти мысли подтвердил (на нем указан вес для 18000 в 515 граммов). Т.е. на оф-сайте - опечатка (cut-n-paste с другой модели)

Баян, но в чём-то схожая ситуация(а именно наличием Flash и его пользователей):
http://www.apple.com/hotnews/thoughts-on-flash/
http://www.youtube.com/watch?v=YPb9eRNyIrQ&feature=related

Вкратце - пройдя через муки выбора между пользователями довольными официальной поддержкой(даже не поддержкой, а разрешением быть) Flash'а и баблом будущем с открытыми стандартами, Apple выбрала последнее то есть бабло выкинула Flash нах. И ничего, кактусы яблоки как ели так и едят. И это при том, что помимо пользователей, есть ещё и Adobe, которая портирует photoshop и т.п. на их ось.

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