Это - копия документа, находившегося на http://dz.ru. Авторские права, если не указано иначе, принадлежат Дмитрию Завалишину и/или Евгении Завалишиной. Все изменения, внесенные мной, находятся в этой рамочке.Пожалуйста, прочитайте disclaimer. |
"Трейдмарка" MP3 удивительно успешна и этим стремятся воспользоваться все, кому не лень. Идут даже на то, чтобы сузить (на словах) применимость продукта - лишь бы увязать с MP3.
MP3 Anywhere - продукт, не имеющий, насколько я могу судить, почти никакого отношения к MP3, цифровому звуку, Интернету и т.п. Это просто комплект из радиопередатчика и радиоприёмника. В передатчик засовываем обычный аналоговый звук - с выхода любого магнитофона, проигрывателя, приёмника, телевизора или звуковой карты. Передатчик его передаёт, приёмник ловит и выдаёт на выход. Который, в свою очередь можно подключить к любому другому аудиоустройству, например, домашнему стереокомплексу.
Фактически, комплект представляет собой всего лишь "беспроводной провод" для соединения любых звуковых устройств. Радионаушники видели? Вот то же самое, но минус наушники.
Однако, производитель придумал для него шикарную легенду. Вам же хочется слушать MP3-шки с Интернета? Неужели вы будете слушать его на своих тщедушных пластиковых колонках, что приделаны к компьютеру? Зачем - у вас же есть стереокомплекс! На нём - лучше. Вот вам радиомост, две коробочки - одну втыкаете в компьютер, вторую - в стереокомплекс. Плюс в комплекте пульт, который позволит управлять компьютером дистанционно. Это, собственно, единственная часть поставки, которая сделана специально для слушания MP3. Самая, кстати, дешёвая.
Всё же остальное (spread-spectrum радиомост для звукового сигнала) легко заменяется десятком метров экранированного провода с разъёмами типа "тюльпан" на концах.
Ничего не хочу сказать плохого - набор найдёт своего покупателя, безусловно удобен и, по большому счёту, недорог - всего $88. Но поставить пять за него надо маркетёрам, а не инженерам. Ибо сужением области применения и удорожанием за счёт стоимости пульта всего комплекта они безусловно повысили на него спрос - к бабке не ходи.
Вот же хотел же вчера упомянуть об этом, но забыл, устал, отвлёкся, нет мне прощения.
Так вот. Вокруг ООП понаписано очень много книг самой разной толщины, цвета и сорта бумаги, но примерно одинакового содержания. Почти все они призваны исправить кособокость Си++ и подобных ему ООП языков и состоят, как правило, из тысячи и одной рекомендации из серии "как не упасть на льду". Опять же, как правило, такие книги ужасно фрагментарны. Они порождены пониманием того факта, что на ОО языках тоже нельзя писать как попало и нужна некоторая методика, но поскольку "общей теории всего" в мире ОО по большому счёту так и нет, все, что можно сказать человеку в такой книге - это "не наследуй то-то так-то" и "не используй public без совсем крайней нужды".
На фоне всех этих мешков с советами (я, в принципе, к ним хорошо отношусь, но факт есть факт - это прост мешки советов) попытки выстроить нечто более ценное зачастую воспринимаются тривиализованно, если можно так сказать.
Вот пример:
Привет, Дмитрий. Прежде всего, хочу поблагодарить тебя за интересные статьи и обозрения на "dz online". Особенно приятно, что, практически в каждой статье, присутствует незаметное "IMHO" - то, чего не хватает многим и-нет журналистам (и что понятно, имея ввиду твое FIDO-шное прошлое :-) Касательно твоей последней статьи - у меня возник ряд комментариев и вопросов. Во первых, не путаешь ли ты программирование и кодирование, собственно? Говоря о использовании исключений ты сводишь разговор, по моему, исключительно на кодирование, так как это сугубо технический прием. Если же говорить о надежном программировании (именно программировании), то существуют, и давно, ряд методик (например, ставшая стандартом в Великобритании SSADM), позволяющих составлять надежные и безопасные алгоритмы. Но... Все бы было хорошо, но к большому сожалению, эти методики весьма дорогие и ресурсоемкие и только очень немногие компании могут позволить себе их применение. Да, такие методики оправданы в случае сравнительно небольших или же очень критичных к ошибкам программ. Но на динамичном современном маркете фирма, которая рискнет применить такие методики для создания продукта "массового спроса", неизбежно окажется банкротом, IMHO. Чисто технические меры (например, обязательное использование исключений etc.) не решают ситуации. Да, допустим, что программа не завершится авраийно по run-time error, но она может не выполнить необходимых в данной ситуации действий, что для некоторых приложений (например, realtime задачи) равносильно той-же ошибке. Так что, по моему - увы, ошибки в программах - это реалии не только сегодняшнего, но и завтрашнего дня :-(
WBR, Sergey N. Svinolobov |
Спасибо за комплимент и за интересный комментарий. Увы, несмотря на его интересность он не совсем в ту степь, о которой я говорил. Упоминание исключений вовсе не было связано с надёжностью, хоть это может показаться удивительным.
Использование (обязательное!) исключений необходимо по причинам отнюдь не утилитарным, а вовсе концептуальным. Если правильно ими пользоваться, мало того, что код становится на порядок более понятен, и писать его становится куда более просто (см. мою ста-арую статью на тему), так ещё и выясняется, что некоторые другие механизмы ОО начали работать так, как им положено. К примеру, автоматическое преобразование типов без исключений использовать крайне трудно - можно, но лишь в тривиальных случаях. В сложных, когда в конструкторе может случиться облом, лишь глобальное использование исключений позволяет этот облом корректно обработать без всякой дополнительной головной боли.
Попытаюсь обобщить - exceptions хороши не потому, что решают те или иные задачи, а потому, что выводят на удобную дорогу, ведут к удобной и простой методике программирования.
И посему, конечно, речь идёт не о кодировании - вопрос об использовании или неиспользовании тех же исключений с учётом их глобального влияния должен ставиться гораздо раньше. Самое позднее - когда идёт раскладка по классам. А это уж точно не кодирование, согласитесь.
Все процессоры программируемые, но тот, что обсуждался в номере за 19-е - программируемый в квадрате. Пластилиновый. Чуть что - подмял его под задачу и далее поехал.
Привет. Насчет программирумых процессоров (от 19 числа). IMHO самое то для них - 3D аккселераторы. Все есть - необходимость (и возможность) массового параллелизма, настройка на конкретный engine (для разных игр требуются разные буфера, разная методика обработки текстур, разные алгоритмы расчета освещения, возможна оптимизация по поводу просчета геометрии и много другого). Сейчас все это пытаются запихнуть в железо. Само собой, с одной стороны, половина возможностей простаивает (в виду невостребованности), а вторая половина реализована у кого как. Эта карта то поддерживает, другая - другое... В результате, или пишешь if-else для всех карт, или исходя из минимального общего набора... Если реализовать 3D акселератор как программируемый процессор! Тот самый твой фотошоп, только действительно нужный в реальном времени. И программировать его нужно будет один раз - при старте программа сообщает драйверу, что же именно ей понадобится - и все. И не надо будет клепать все новые железяки, все новые акселераторы. Ну, то есть можно - но просто такой же, но еще быстрее, или еще больше ;-) А этому рынку еще расти и расти. При нынешнем состоянии, до сравнимого (с реальным) качества еще лет десять расти. А с программируемыми процессорами - за год-два можно обернуться ;-) Пока
|
Действительно! Просто сам бог велел. Вот только, наверное, нет таких плотно упакованных матриц, чтобы позволяли на маленькой платке видеоконтроллера уместить нужное число элементов. Наверное, для таких целей, всё же, придётся делать специализированне схемы, а не использовать стандартные FPGA.
А сама идея легла на благодатную почву. Тут вот как раз народ геймопишущий вокселями увлёкся, так для них стандартный акселератор - мёртвому припарки. Он рассчитан на иные методы работы с графикой, и если игра строит модель существенно отлично от Quake, польза от использования традиционного акселератора уменьшается. А вот "пластилиновый" бы мог потянуть.
Кстати, к звуковым картам это тоже относится.