nixp.ru v3.0

21 января 2017,
суббота,
11:39:51 MSK

Аутсорсинг Linux с компанией «Флант»
Fatal написал 25 марта 2005 года в 17:32 (395 просмотров) Ведет себя как мужчина; открыл 123 темы в форуме, оставил 484 комментария на сайте.

Почему кодят на сях и библиотеки, как правило имеют сишный интерфейс? если ООП произвёло революции в программировании? Например, библиотека gtk сначала имела, наверника, интрфейс для Си, а затем появился аналог на Си++ (gtkmm), и ещё библиотека Xlib имеет сишный интерфейс, и так далее и тому подобное. Си++ же был придума для поддержки больших проектов и причё изначально для UNIX.

iliya

«C» просто язык для работы с памятью (там всё прозрачно на этот счет). Да и для оптимизации подходит лучше, проще для серьёзных вещей написать сишную либу (набор хорошо продуманных функций), а потом использовать их в C++.

Ну и вообще Си просто более прозрачный во всех отношениях, а как будет вести себя С++ не совсем понятно.

Uncle Theodore

Ну не все так просто…

Пожалуй, самая основная причина — это тот факт что ООП-дизайн сильно уступает в производительности дизайну «монолитному». Единственный выигрыш в ООП — в разбивке задачи, т.е. преимущество достигается на уровне программирования, а не выполнения. Поскольку программируем один раз, а выполняем много раз, то овчинка выделки не стОит.

С — стандарт для системного программирования. По причинам, изложенным выше. Соответственно, все библиотеки сначала пишутся на нем и енкапсулируются по желанию.

А про революцию в программировании — это ты немножко загнул… :-)

Good Luck,

UT

anonymous
Fatal
Почему кодят на сях и библиотеки, как правило имеют сишный интерфейс?

Мне кажется, что большинство императивных языков грамматически похоже на C. Зачем же ждать чего-то другого ? Кроме того, прошло достаточно времени для создания высокоэффективного компилятора C.

если ООП произвёло революции в программировании? Например, библиотека gtk сначала имела, наверника, интрфейс для Си, а затем появился аналог на Си++ (gtkmm), и ещё библиотека Xlib имеет сишный интерфейс, и так далее и тому подобное. Си++ же был придума для поддержки больших проектов и причё изначально для UNIX.

Насколько мне известно, очень хорошо оптимизирующих компиляторов C++ нет (хотя, возможно, и есть, но вот какова их стоимость?). Было бы странно, что софт,  написанный на C, будет иметь единственный библиотечный  интерфейс для использования в программах, написанных на Паскале.

А насчет революции… Да, очень много софта пишется с применением объектно-ориентированной методологии, но, по словам Брукса, «серебряной пули» нет. Не помогают UML, доказательство кода, функциональная парадигма. Могу посоветовать почитать книгу Йордона   — «Марш камикадзе».

Кроме того, есть факт повторного использования кода, что объясняет многое.

anonymous
Uncle Theodore
Ну не все так просто…

С — стандарт для системного программирования. По причинам, изложенным выше. Соответственно, все библиотеки сначала пишутся на нем и енкапсулируются по желанию.

[skip]

Good Luck,

UT

Гм, я бы не был столь категоричным. Потому что есть FORT.

Uncle Theodore
redbeard
Гм, я бы не был столь категоричным. Потому что есть FORT.

Это который FORTH, или что ты имеешь в виду?

Good Luck,

UT

anonymous
Uncle Theodore
Это который  FORTH, или что ты имеешь в виду?

Good Luck,

UT

Ага. Sorry, букву забыл.

Uncle Theodore

FORTH — язык занятный. Но написано на нем не так уж много…

Все-таки С — стандарт для системного программирования. Из-за Юникса, наверное.

Good Luck,

UT

anonymous
Uncle Theodore
FORTH — язык занятный. Но написано на нем не так уж много…

Все-таки С — стандарт для системного программирования. Из-за Юникса, наверное.

Good Luck,

UT

Если сравнивать по объему кода — скорее всего. Но и FORTH ничем не хуже. ;-)

iliya

Ну вот ушли от темы на какой-то FORTH.

На нем ты писать будешь? (только честно)

И тему считаю закрытой.

Longobard

Кто вам мешет сделать свои классы всякие. который инкапсулируют Сишные функции?

Uncle Theodore
LONGOBARD
Кто вам мешет сделать свои классы всякие. который инкапсулируют Сишные функции?

Ничего не мешает. Но

Одна и та же прога, скомпилированная как С и как С++, во втором случае будет выполняться раза в полтора-два дольше.

Разбиение задач на подзадачи сильно помогает при планировке алгоритма и сильно вредит при оптимизации кода, особенно, если разные части были написаны разными людьми, не знавшими полной задачи (как и подразумевается ООПшной парадигмой).

Good Luck,

UT

Longobard

Да, я согасен.

sky
LONGOBARD
Да, я согасен.

Раз ?board=flame; то немного отойду от темы.

Давно такого ответа не видел:

Да, я согасен. — на эту фразу нужно поставить законный копирайт (c)

LONGOBARD
Да, я согасен.

А я — совершенно не согласен. Сам по себе ООП без шаблонов и исключений не особо тяжелее сишного кода. Проблема в разном манглинге символов разными компиляторами, что ухудшает (если не ломает совсем) совместимость на уровне объектных файлов. Вот стандарт на symbol mangling для c++ очень бы не помешал…

decvar
Сам по себе ООП без шаблонов и исключений не особо тяжелее сишного кода

Угу, как же…. Как тока дерево классов разростается + вступает какое-то хитрое множественное наследование   — тада совсем не понятно. Кроме того есть куча людей которые typedef-ят все что можно, типа

typedef vectorAnotherClass

и вот тогда без Go To Defenition в MSVS можно стрелятся!

И ваще ООП модель сложна для понимания в принципе. Ну не каждый в нее воткнуть может.

anonymous
iliya
Ну вот ушли от темы на какой-то FORTH.

На нем ты писать будешь? (только честно)

И тему считаю закрытой.

Считать можно что угодно. Каждому языку — своя ниша применения.

Genie
FORTH — язык занятный. Но написано на нем не так уж много…

Если посчитать прямого потомка — PostScript — то написано дааааафига много всего

да и на самом Форте очень много управляющих программ написано. просто не все спецификации таких железок выложены в общий доступ и анонсированы.

Сам по себе ООП без шаблонов и исключений не особо тяжелее сишного кода.

с одним таким мааааленьким дополнением: при правильном использовании.

правда, при правильном использовании очень многое становится быстрым и лёгким, не только ООП.

основная цель использования объектов и классов в том, чтобы облегчить разработку созданием типовых наработок, которые создают юазис для минимально-рабочей (в смысле дерева объектов) структуры программы.

при этом совершенно не учитывается тот факт, что для работы некоторые части кода просто-напросто излишни.

избавиться от излишков могла бы система оптимизации, однако, при этом очень сильно бы страдала скорость компилирования и борки программ.

в своё время баловался такой штуковиной — оптимизацией кода, оставляемого в программе на основе классов.

объём кода… уменьшался в полтора-два раза. это только то, что лежало «на поверхности».

правда, должен сказать, что затраты на написание такого «оптимизатора» — очень большие. головёнка в то время, бывало, что и перегревалась.. :(

<font color=«grey»>к сожалению, винт со многими наработками накрылся медным тазом в 2001 году.. :((</font>

anonymous
Genie
избавиться от излишков могла бы система оптимизации, однако, при этом очень сильно бы страдала скорость компилирования и борки программ.

Не кажется, что от излишков помогают избавиться парадигма и дизайн языка ? Бывает, посмотришь на функциональный язык или Perl — от крестов плеваться хочется.

Genie
Не кажется, что от излишков помогают избавиться парадигма и дизайн языка ? Бывает, посмотришь на функциональный язык или Perl — от крестов плеваться хочется.

да-да. возьмём чисто ООП язык symbol…

давай ты всё же будешь учитывать контекст ведения рассуждений, а?

отвечалось в плане разницы C и C++, в разрезе использования ООП.

да, использовать Perl для некоторых задач — удобнее. на порядок-другой. вот только — и в нём использование классов несколько увеличивает время обработки, если ты этого не заметил.

зато упрощает написание программ….

в этом плане мне нравится чьё-то высказывание: «Perl-а нет, есть CPAN.» ;)

anonymous
Genie
да, использовать Perl для некоторых задач — удобнее. на порядок-другой. вот только — и в нём использование классов несколько увеличивает время обработки, если ты этого не заметил.

С чего ты взял, что я этого не заметил?  Code reuse — хорошо, но, бывает, встречается и хорошо спроектированная стандартная библиотека. Пример — OCaml.

зато упрощает написание программ….

в этом плане мне нравится чьё-то высказывание: «Perl-а нет, есть CPAN.» ;)

CPAN, безусловно, жжот.

Genie
С чего ты взял, что я этого не заметил?

с того, что привёл в качестве примера perl в контексте обсуждения эффективности программирования с использованием ООП.

Пример — OCaml.

может быть. но не по распространённости использования.

ps: что-то слишком ты от темы любишь отклоняться. :)

если интересует какой-то вопрос, давай, заводи новую тему.

pps: я понимаю, что тут флейм. но пустого флейма — не надо.

пусть будет интересный, конструктивный.

anonymous
Genie
ps: что-то слишком ты от темы любишь отклоняться. :)

если интересует какой-то вопрос, давай, заводи новую тему.

pps: я понимаю, что тут флейм. но пустого флейма — не надо.

пусть будет интересный, конструктивный.

Хорошо.

myst

Кто сказал, что ОО-программы нельзя писать на C?

anonymous
myst
Кто сказал, что ОО-программы нельзя писать на C?

А кто сказал, что нельзя забивать гвозди микроскопом ?

myst
cebka
А я — совершенно не согласен. Сам по себе ООП без шаблонов и исключений не особо тяжелее сишного кода. Проблема в разном манглинге символов разными компиляторами, что ухудшает (если не ломает совсем) совместимость на уровне объектных файлов. Вот стандарт на symbol mangling для c++ очень бы не помешал…

Вот тут уже я соглвсен.

Более того, из-за того, что подсознательно мы стремимся написать именно ООП программы (ну там, структурка, потом передаётся чему-то, что её проинициализирует, потом она же + ещё что-то другой процедуре и т.д.), то код C++ будет быстрее, чем на C. Быстрее потому, что C++ знает про объекты. Ну не медленнее, то точно.

P.S. Шаблоны CPU не отжирают, они отжирают память, а вот RTTI — да.

ecobeingecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.