|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Alexandr S. Agranovsky 2:5020/400 02 Jan 2003 01:39:27
To : Vladimir Bormotov
Subject : Re: Re: <none>
--------------------------------------------------------------------------------
Hi, Vladimir Bormotov
VB> PY> У меня есть знания в области С++, но просто яникогда не писал проги в
VB> PY> Линукс использую оконный интерфейс...
VB> Знания C++ никому не мешали. Hо, из факта наличия знаний С++ не следует
VB> что их нужно применять всегда. Для написания оконного интерфейса в *nix
VB> знания C++ нужны чуть ли не в последнюю очередь.
Мда... Согласен. Я нижецитируемую статьу (автор не я)
приберегал, не хотел без нужды постить, но, похоже, наступил
такой момент. Считайте его аргументом против бездумного
применения С++
=======cut
ОБЪЕКТHО-ОРИЕHТИРОВАHHЫЙ СТИЛЬ "В ЖИЗHИ"
Мне приходилось довольно много контактировать с программистами,
в основном - разработчиками прикладных программ. Большинство
этих вполне толковых и умных людей пишут на С++. Мне не повезло:
я ни разу не видел программ, написанных на этом модном языке с
интенсивными применением его инструментария (как например,
глубокое наследование классов и использование private
элементов), которые превосходили бы свои аналоги на допотопном С
хотя бы по одному из следующих критериев :
Читаемость и понятность кода
Величина исполняемого модуля
Быстродействие.
Hо вот обратных примеров более чем достаточно. В разрабатываемой
нами довольно сложной машине один из сигналов датчика оказался
довольно зашумлённым и содержащим резкие выбросы. Поскольку вся
обработка этого сигнала и использование её результатов были
реализованы в программе на С++, решение проблемы было достаточно
тривиальным. Я написал простенькую программу на С, включающую
медианный фильтр и "скользящее среднее" и выбрал необходимые
значения пары параметров. Всё выглядело довольно скромно: длина
обрабатываемого массива не превышала 2 тысяч чисел, а оба
фильтра надо было применять по скользящей последовательности
7-13 элементов. Вся программа содержала строк 30-40 и
выполнялась за несколько миллисекунд на процессоре 486 - 66 МГц.
Так что не думая худого, я приготовил описание программы (оно
потребовало уже нескольких страниц) и отдал программистам для
кодировки.
То, что случилось потом, я бы не смог себе представить даже в
кошмарном сне. Через пару недель работы первая версия была
готова, и мне предложили проверить, всё ли в порядке. Я запустил
её с одним из файлов данных, на котором отрабатывал алгоритм.
Всего лишь за полсекунды (Пентиум - 166МГц) программа выдала
какой-то случайный (как мне казалось) набор чисел. Мои попытки
убедить программистов, что что-то не в порядке, привели к тому,
что мне было предложено самому найти ошибку. Когда я глянул на
программу, то понял, почему им так трудно. Во-первых, это была
распечатка страниц на семь. Во-вторых, никаких простых
одномерных массивов не было - они были заменены коллекциями,
услужливо поставляемыми какой-то стандартной библиотекой
классов. Единственная ошибка была в том, что коллекции не были
отсортированы по времени поступления реальных данных (то есть
естественный порядок входных данных был утерян в самом начале).
Ещё полчаса заняло исправление ошибок - и всё было в порядке.
Всё считалось правильно - всего лишь за секунду на серию данных.
Много позже (тогда я уже работал в другом проекте) этот этап -
обработка данных - стал лимитировать быстродействие робота (т.е.
механическая подвижка образца и оптические измерения шли
быстрее, чем простой счёт). Как и следовало ожидать, написать
более быструю программу никто не предложил - было решено
поставить более сильный процессор и добавить память.
Примерно через год я держал в руках резюме парня, претендующего
занять вакантное место программиста на С++. Он прошёл
основательный курс обучения этому языку (примерно полгода),
включавший несколько проектов. Один из них назывался "программа
решения квадратного уравнения". Я не поверил своим глазам и
связался с претендентом, чтобы узнать подробности. Оказалось,
что проект включал четыре класса с наследованием. Судя по
энтузиазму, с которым парень описывал проект, можно было не
сомневаться: когда ему потребуется вставить алгоритм решения
квадратного уравнения, он будет использовать только эту
разработку. После этого мне стали понятны причины изысков с
сортировками коллекций в предыдущем эпизоде.
=======cut
- ---
Alexandr S. Agranovsky llb@udmnet.ru
--- ifmail v.2.15dev5
* Origin: LLB, LLC (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
| Тема: |
Автор: |
Дата: |
|
<без заголовка> |
Postrekhin Yuri |
31 Dec 2002 12:59:41 |
 Re: <none> |
Artem Chuprina |
31 Dec 2002 15:11:43 |
|
Re: <none> |
Vladimir Bormotov |
31 Dec 2002 15:17:19 |
|
Re: <none> |
Victor Wagner |
31 Dec 2002 15:56:54 |
 Re: <none> |
Vladimir Bormotov |
31 Dec 2002 16:12:36 |
  <none> |
Postrekhin Yuri |
01 Jan 2003 20:30:03 |
 Re: <none> |
Alexandr S. Agranovsky |
01 Jan 2003 23:08:50 |
|
Re: <none> |
Vladimir Bormotov |
02 Jan 2003 00:27:09 |
|
Re: Re: <none> |
Alexandr S. Agranovsky |
02 Jan 2003 01:39:27 |
|
Re: <none> |
Aleksandr Skobelev |
02 Jan 2003 20:39:30 |
|
Re: <none> |
Vladimir Bormotov |
02 Jan 2003 20:44:34 |
|
Re: Re: <none> |
Alexandr S. Agranovsky |
03 Jan 2003 00:50:22 |
|
Re: <none> |
Sergey Bezrukov |
04 Jan 2003 13:31:02 |
|
Re: <none> |
Aleksei Gusev |
02 Jan 2003 21:34:50 |
|
<none> |
Postrekhin Yuri |
01 Jan 2003 20:26:22 |
|
Re: <none> |
Vladimir Bormotov |
02 Jan 2003 00:31:41 |
|
<без заголовка> |
Roman Tuchegromoff |
31 Dec 2002 17:09:06 |
|
|
