Отправлено Bill 30 сентября 2005 г. 00:57 В ответ на: попрошу проаргументировать эту точку зрения. Лично мне программы на С напоминают глобальную кашу ф-ций и данных. Потуги программистов хоть как-то их разделить неизбежно приводят к ++ подобному коду отправлено DASM 30 сентября 2005 г. 00:32

Представь себе два баллона с газом, на которых не написано какие газы в них находятся. Тот, кто их заполнял, допустим знает, что в одном водород, а в другом кислород. А тот, кто не знает, мжет сделать все что угодно. Например, смешать эти газы, а потом ему захочется закурить. И что будет?
Манипуляция с объектами, о которых неизвестно почти ничего, чревата непредсказуемыми последствиями. Можно добавить, что легкость, с которой создаются коды в ООП, приводит к быстрому разрастанию программ и к затруднению контроля за ними. Т.е., если в ассемблере 1 строка исходного текста программы эквивалентна одной команде, то для программы из 100 инструкций потребуется 100 строк. Допустим, что оператор Си соответствует 5 инструкциям, и в этом случае потребуется написать только 20 строк текста. Для Си++ это значение будет еще меньше. Но программист пишет определенное количество строк в день. Поэтому за день он может "настрогать" на Си++ раз в 20 больше, чем на ассемблере. И это все может выйти из-под контроля. А если в компиляторе глюк, который обнаружится далеко не сразу? Что будет тогда? Поэтому использование языков сверхвысокого уровня требует большой аккуратности.
Собственно, я об этом уже заикался.

• http://onembedding.com/articles/progtools/

• Bill? ты начинался черти чего и, похоже, серъезно не пробовал на ++ писать. Естественно любая сторонняя библиотека должны быть ЧЕТКО документирована в терминах ИНТЕРФЕЙСОВ. И этого более чем достаточно. Никакой легкости создания объектов в ООП нет (+) — DASM   (30.09.2005 01:05 217.118.78.1, 650 байт)
  • Так я о том и говорю, что требуется АККУРАТНОСТЬ везде. И чем выше уровень, — Bill   (30.09.2005 01:25 195.239.108.229, 1166 байт)
    • вообще мы от идее разделения код от данных и полиморфизма объектов как-то странно перетекли на библиотеки, которые к С++ вобщем-то не относятся — DASM   (30.09.2005 01:34 217.118.78.1, пустое)
      • Ну почему же не относяться? Библиотеки компонентов (объектов) — Bill   (30.09.2005 01:48 195.239.108.229, 33 байт)
      • Да нет, мы с STL начинали... С массива битового. Что есть чиста библиотека. — SM   (30.09.2005 01:36 213.141.159.26, пустое)
  • Этого недостаточно! Еще необходима гарантия отсутствия ошибок (ха-ха), или хотя бы бесплатного и БЫСТРОГО их устранения. Только тогда можно допустить библиотеку к использованию в проекте. — SM   (30.09.2005 01:08 213.141.159.26, пустое)
    • Вот именно что БЫСТРОГО. В ++ достаточно исправить ошибку в базовом классе, и все объекты исправлены. Объекты отлаживаются почти независимо друг от друга, т.е. отлаживается сравнительно небольшой кусок программы. А в СИ все взаимосвязанно, там можно по всей программе искать и не найти. Просто СИ++ - это другой способ мышления и для вас с Billом здесь пока психологический барьер. SM, у тебя же голова золотая, попробуй врубиться в ++, ты то сразу все преимущества просечешь. — Михаил Е.   (30.09.2005 01:23 83.237.32.94, пустое)
      • Барьера психологического нет. Я пока просто не вижу необходимости его использования. — Bill   (30.09.2005 01:27 195.239.108.229, 31 байт)
      • Да отлично знаю я эти ++, и разбираюсь в них. Не подходят они ни к одной из моих задач. Не делаю я монстров. — SM   (30.09.2005 01:24 213.141.159.26, пустое)
        • ой, да ладно отлично :-) Его Страуструп отлично то не знает :-D — DASM   (30.09.2005 01:33 217.118.78.1, пустое)
          • Я хочу сослаться на твой пример с битами. Как все замечательно выглядит в исходном тексте! — Bill   (30.09.2005 01:42 195.239.108.229, 370 байт)
            • мы не говорим про ATTINY etc. Вот сейчас активно использую stl в LPC2138. 512 к флеша и 32 к рам есть. Рам хотелось бы побольше, но в целом на ++ уже достаточно комфортно. И у меня есть уверенность что этот код будет работать и на любом другом процессоре. — DASM   (30.09.2005 01:51 217.118.78.1, пустое)
              • Всякому овощу свой фрукт. Я же не против Си++ как такового. Я просто говорю о том, — Bill   (30.09.2005 02:02 195.239.108.229, 332 байт)
                • И с точки зрения размера поражаемой зоны, Си++ гораздо мощнее — Bill   (30.09.2005 02:10 195.239.108.229, 249 байт)
                  • и опять же за счет механизма обработки исключений и строгой типизации С++ БЕЗОПАСНЕЙ чем С — DASM   (30.09.2005 02:27 217.118.78.1, пустое)
                    • Чем больше разных механизмов, тем больше вероятность того, что они дадут сбой. — SM   (30.09.2005 09:41 213.141.159.26, пустое)
                      • Именно. Лом надежней перфоратора именно из-за простоты конструкции. — †   (30.09.2005 11:20 81.23.109.150, пустое)
              • PS уже сейчас темпы выхода новых процев таковы, что чем сидеть писать свое под имеющийся проц - быстрее подождать подходящий. Ибо быстрее получится =) — DASM   (30.09.2005 01:52 217.118.78.1, пустое)
                • И ждать его можно очень-очень долго. Так как подходящих что-то не делают. Вот у холтека например мне вроде подходящий, но дороговат зараза... Быстрее и проц самому сделать :) :) :) — SM   (30.09.2005 01:55 213.141.159.26, пустое)
            • Ну тут народ уже давно перестал ресурсы считать - не влезет, так проц в два раза толще воткнут :) :) — SM   (30.09.2005 01:49 213.141.159.26, пустое)
              • Ну, это само собой. Как говорится, сила есть - ума не надо. Только лично мне не хочется — Bill   (30.09.2005 01:55 195.239.108.229, 177 байт)
                • Абсолютно поддерживаю. Далеко не все (а думаю мало кто) могут пожертвовать N баксов/девайс только ради красоты кода и экономии пары недель-месяца времени. — SM   (30.09.2005 01:57 213.141.159.26, пустое)
                  • Особенно эсли это N твое личное, и идет тебе в карман :) :) — SM   (30.09.2005 01:58 213.141.159.26, пустое)
          • Да вот только сейчас сообразил, а ведь я пишу на ++ (+) — SM   (30.09.2005 01:35 213.141.159.26, 95 байт)
        • И красота программы в моих представлениях (+) — SM   (30.09.2005 01:29 213.141.159.26, 153 байт)
          • :) :) А читаемость кода (+) — SM   (30.09.2005 01:51 213.141.159.26, 101 байт)
            • ладно. Предлагаю остановится на том, что самый лучший язык - это женский и на этом разойтись =))) — DASM   (30.09.2005 02:12 217.118.78.1, пустое)
    • гарантию может дать только полис сами знаете чего. Тем не менее документированный (часто объем документации > объема сурцев) код имеет меньше шансов быть ошибочным, ведь его использовали уже десятки фирм и находили и исправляли ошибки. В то время как небольшая фирма не может позволить себе больших затрат на тестирование. — DASM   (30.09.2005 01:12 217.118.78.1, пустое)
      • Извиняюсь, прочитал плохо. Да, если библиотека поставляется в виде хорошо документированного КОДА, а не интерфейса, то я только за. Такую библиотеку можно самостоятельно исправить, если что. — SM   (30.09.2005 01:21 213.141.159.26, пустое)
      • Да-да... Конкретный пример GPL-софт. Все кому не лень находят глюки, исправляют, куча патчей выходит, куча веток и полный разброд. Извини, но если я приобретаю либу у фирмы, так пусть она свои глюки исправляет, и гарантирует, что сделает она это в приемлемые сроки. А не десятки фирм. — SM   (30.09.2005 01:18 213.141.159.26, пустое)
        • для начала хотелось бы посмотреть на библиотеку безглючную общего пользования, которую напишешь ты и твои коллеги — DASM   (30.09.2005 01:20 217.118.78.1, пустое)
          • Я не буду писать библиотек общего пользования, ибо априори знаю, что безглючность (точнее стремящаяся к нулю вероятность глюка) у нее только в тех условиях, в которой ее оттестировал я. И гарантий на другие условия я дать не могу. — SM   (30.09.2005 01:23 213.141.159.26, пустое)