попрошу проаргументировать эту точку зрения. Лично мне программы на С напоминают глобальную кашу ф-ций и данных. Потуги программистов хоть как-то их разделить неизбежно приводят к ++ подобному коду («Телесистемы»: Конференция «Микроконтроллеры и их применение»)

попрошу проаргументировать эту точку зрения. Лично мне программы на С напоминают глобальную кашу ф-ций и данных. Потуги программистов хоть как-то их разделить неизбежно приводят к ++ подобному коду

(«Телесистемы»: Конференция «Микроконтроллеры и их применение»)

Отправлено DASM 30 сентября 2005 г. 00:32
В ответ на: Я боюсь, что цивилизацию как раз разрушит плюсплюснутый Си. отправлено Bill 30 сентября 2005 г. 00:28

Составить ответ ||| Конференция ||| Архив

Ответы

Ведь объет это "черный ящик". Его содержимое знает только тот, кто его создал. — Bill (30.09.2005 00:57 195.239.108.229, 1211 байт, ссылка)
- 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, пустое)

Перейти к списку ответов ||| Конференция ||| Архив ||| Главная страница ||| Содержание ||| Без кадра

E-mail: info@telesys.ru