Почему кодят на сях и библиотеки, как правило имеют сишный интерфейс? если ООП произвёло революции в программировании? Например, библиотека gtk сначала имела, наверника, интрфейс для Си, а затем появился аналог на Си++ (gtkmm), и ещё библиотека Xlib имеет сишный интерфейс, и так далее и тому подобное. Си++ же был придума для поддержки больших проектов и причё изначально для UNIX.
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
«C» просто язык для работы с памятью (там всё прозрачно на этот счет). Да и для оптимизации подходит лучше, проще для серьёзных вещей написать сишную либу (набор хорошо продуманных функций), а потом использовать их в C++.
Ну и вообще Си просто более прозрачный во всех отношениях, а как будет вести себя С++ не совсем понятно.
Ну не все так просто…
Пожалуй, самая основная причина — это тот факт что ООП-дизайн сильно уступает в производительности дизайну «монолитному». Единственный выигрыш в ООП — в разбивке задачи, т.е. преимущество достигается на уровне программирования, а не выполнения. Поскольку программируем один раз, а выполняем много раз, то овчинка выделки не стОит.
С — стандарт для системного программирования. По причинам, изложенным выше. Соответственно, все библиотеки сначала пишутся на нем и енкапсулируются по желанию.
А про революцию в программировании — это ты немножко загнул… :-)
Good Luck,
UT
Мне кажется, что большинство императивных языков грамматически похоже на C. Зачем же ждать чего-то другого ? Кроме того, прошло достаточно времени для создания высокоэффективного компилятора C.
Насколько мне известно, очень хорошо оптимизирующих компиляторов C++ нет (хотя, возможно, и есть, но вот какова их стоимость?). Было бы странно, что софт, написанный на C, будет иметь единственный библиотечный интерфейс для использования в программах, написанных на Паскале.
А насчет революции… Да, очень много софта пишется с применением объектно-ориентированной методологии, но, по словам Брукса, «серебряной пули» нет. Не помогают UML, доказательство кода, функциональная парадигма. Могу посоветовать почитать книгу Йордона — «Марш камикадзе».
Кроме того, есть факт повторного использования кода, что объясняет многое.
Гм, я бы не был столь категоричным. Потому что есть FORT.
Это который FORTH, или что ты имеешь в виду?
Good Luck,
UT
Ага. Sorry, букву забыл.
FORTH — язык занятный. Но написано на нем не так уж много…
Все-таки С — стандарт для системного программирования. Из-за Юникса, наверное.
Good Luck,
UT
Если сравнивать по объему кода — скорее всего. Но и FORTH ничем не хуже. ;-)
Ну вот ушли от темы на какой-то FORTH.
На нем ты писать будешь? (только честно)
И тему считаю закрытой.
Кто вам мешет сделать свои классы всякие. который инкапсулируют Сишные функции?
Ничего не мешает. Но
Одна и та же прога, скомпилированная как С и как С++, во втором случае будет выполняться раза в полтора-два дольше.
Разбиение задач на подзадачи сильно помогает при планировке алгоритма и сильно вредит при оптимизации кода, особенно, если разные части были написаны разными людьми, не знавшими полной задачи (как и подразумевается ООПшной парадигмой).
Good Luck,
UT
Да, я согасен.
Раз ?board=flame; то немного отойду от темы.
Давно такого ответа не видел:
Да, я согасен. — на эту фразу нужно поставить законный копирайт (c)
А я — совершенно не согласен. Сам по себе ООП без шаблонов и исключений не особо тяжелее сишного кода. Проблема в разном манглинге символов разными компиляторами, что ухудшает (если не ломает совсем) совместимость на уровне объектных файлов. Вот стандарт на symbol mangling для c++ очень бы не помешал…
Угу, как же…. Как тока дерево классов разростается + вступает какое-то хитрое множественное наследование — тада совсем не понятно. Кроме того есть куча людей которые typedef-ят все что можно, типа
typedef vectorAnotherClass
и вот тогда без Go To Defenition в MSVS можно стрелятся!
И ваще ООП модель сложна для понимания в принципе. Ну не каждый в нее воткнуть может.
Считать можно что угодно. Каждому языку — своя ниша применения.
Если посчитать прямого потомка — PostScript — то написано дааааафига много всего
да и на самом Форте очень много управляющих программ написано. просто не все спецификации таких железок выложены в общий доступ и анонсированы.
с одним таким мааааленьким дополнением: при правильном использовании.
правда, при правильном использовании очень многое становится быстрым и лёгким, не только ООП.
основная цель использования объектов и классов в том, чтобы облегчить разработку созданием типовых наработок, которые создают юазис для минимально-рабочей (в смысле дерева объектов) структуры программы.
при этом совершенно не учитывается тот факт, что для работы некоторые части кода просто-напросто излишни.
избавиться от излишков могла бы система оптимизации, однако, при этом очень сильно бы страдала скорость компилирования и борки программ.
в своё время баловался такой штуковиной — оптимизацией кода, оставляемого в программе на основе классов.
объём кода… уменьшался в полтора-два раза. это только то, что лежало «на поверхности».
правда, должен сказать, что затраты на написание такого «оптимизатора» — очень большие. головёнка в то время, бывало, что и перегревалась.. :(
<font color=«grey»>к сожалению, винт со многими наработками накрылся медным тазом в 2001 году.. :((</font>
Не кажется, что от излишков помогают избавиться парадигма и дизайн языка ? Бывает, посмотришь на функциональный язык или Perl — от крестов плеваться хочется.
да-да. возьмём чисто ООП язык symbol…
давай ты всё же будешь учитывать контекст ведения рассуждений, а?
отвечалось в плане разницы C и C++, в разрезе использования ООП.
да, использовать Perl для некоторых задач — удобнее. на порядок-другой. вот только — и в нём использование классов несколько увеличивает время обработки, если ты этого не заметил.
зато упрощает написание программ….
в этом плане мне нравится чьё-то высказывание: «Perl-а нет, есть CPAN.» ;)
С чего ты взял, что я этого не заметил? Code reuse — хорошо, но, бывает, встречается и хорошо спроектированная стандартная библиотека. Пример — OCaml.
CPAN, безусловно, жжот.
с того, что привёл в качестве примера perl в контексте обсуждения эффективности программирования с использованием ООП.
может быть. но не по распространённости использования.
ps: что-то слишком ты от темы любишь отклоняться. :)
если интересует какой-то вопрос, давай, заводи новую тему.
pps: я понимаю, что тут флейм. но пустого флейма — не надо.
пусть будет интересный, конструктивный.
Хорошо.
Кто сказал, что ОО-программы нельзя писать на C?
А кто сказал, что нельзя забивать гвозди микроскопом ?
Вот тут уже я соглвсен.
Более того, из-за того, что подсознательно мы стремимся написать именно ООП программы (ну там, структурка, потом передаётся чему-то, что её проинициализирует, потом она же + ещё что-то другой процедуре и т.д.), то код C++ будет быстрее, чем на C. Быстрее потому, что C++ знает про объекты. Ну не медленнее, то точно.
P.S. Шаблоны CPU не отжирают, они отжирают память, а вот RTTI — да.