информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Блокировка российских аккаунтов... 
 Отзыв сертификатов ЦБ РФ, ПСБ,... 
 Памятка мирным людям во время информационной... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Зачем придираться к мелочам? 23.06.06 09:44  Число просмотров: 2556
Автор: Heller <Heller> Статус: Elderman
<"чистая" ссылка>
> ООП -- это стиль программирования, а не язык. Поэтому
ОПП - это парадигма программирования, а не стиль.

> принципы ООП можно реализовать и на Си.
Принципы ООП можно реализовать и в Ассемблере, но нужно ли это?

> Доказательство: вот такая вот дока:
> http://netsago.ellsec.org/download/ooc.PDF
Если в языке возможно что-либо реализовать, то это еще не значит, что он имеет для этого все средства.
<programming>
[C++] Программирование по Линуксом 22.06.06 20:50  
Автор: panter_dsd Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Есть такой вопросик.
На чем лучше писать под Линухой: c или с++? С учетом того, что мне нужно ООП.

С уважением.
Пантер.
С++ == С + ООП; ООП в языке Си нет в принципе. Естесственно, писать нужно на C++ 22.06.06 20:53  
Автор: Heller <Heller> Статус: Elderman
<"чистая" ссылка>
Поправочка. 23.06.06 09:14  
Автор: n0xi0uzz <Черкасов Виктор> Статус: Member
<"чистая" ссылка>
ООП -- это стиль программирования, а не язык. Поэтому принципы ООП можно реализовать и на Си.

Доказательство: вот такая вот дока: http://netsago.ellsec.org/download/ooc.PDF
Зачем придираться к мелочам? 23.06.06 09:44  
Автор: Heller <Heller> Статус: Elderman
<"чистая" ссылка>
> ООП -- это стиль программирования, а не язык. Поэтому
ОПП - это парадигма программирования, а не стиль.

> принципы ООП можно реализовать и на Си.
Принципы ООП можно реализовать и в Ассемблере, но нужно ли это?

> Доказательство: вот такая вот дока:
> http://netsago.ellsec.org/download/ooc.PDF
Если в языке возможно что-либо реализовать, то это еще не значит, что он имеет для этого все средства.
Просто делюсь информацией. 23.06.06 20:16  
Автор: n0xi0uzz <Черкасов Виктор> Статус: Member
Отредактировано 23.06.06 20:26  Количество правок: 1
<"чистая" ссылка>
> > ООП -- это стиль программирования, а не язык. Поэтому
> ОПП - это парадигма программирования, а не стиль.
Парадигма определяет стиль ;).

> > принципы ООП можно реализовать и на Си.
> Принципы ООП можно реализовать и в Ассемблере, но нужно ли
> это?
На самом деле, не всех устраивает реализация принципов ООП, представленная средствами C++.

> > Доказательство: вот такая вот дока:
> > http://netsago.ellsec.org/download/ooc.PDF
> Если в языке возможно что-либо
> реализовать, то это еще не значит, что он имеет для этого
> все средства.
То есть что-то реализовать можно (я употребил именно это слово), но средств для этого нет? Ну, это уже вопрос владения логикой ;)).

Ну, а в целом, действительно, просто делюсь информацией.
Тоже делюсь информацией 23.06.06 21:25  
Автор: Heller <Heller> Статус: Elderman
Отредактировано 23.06.06 21:26  Количество правок: 1
<"чистая" ссылка>
> > > ООП -- это стиль программирования, а не язык.
> Поэтому
> > ОПП - это парадигма программирования, а не стиль.
> Парадигма определяет стиль ;).
Но не наоборот ;)
(а вообще и само утверждение спорное)

>
> > > принципы ООП можно реализовать и на Си.
> > Принципы ООП можно реализовать и в Ассемблере, но
> нужно ли
> > это?
> На самом деле, не всех устраивает реализация принципов ООП,
> представленная средствами C++.
Не всех. Но на C++ программирует большинство и я еще ни разу не видел языка, у которого объективно есть более рациональный подход к ООП.

> > > Доказательство: вот такая вот дока:
> > > http://netsago.ellsec.org/download/ooc.PDF
> > Если в языке возможно что-либо
> > реализовать, то это еще не значит, что он имеет для
> этого
> > все средства.
> То есть что-то реализовать можно
> употребил именно это слово), но средств для этого нет? Ну,
> это уже вопрос владения логикой ;)).
Программа, написанная на C++ с использованием ООП, жпеговская картинка из Фотошопа, mp3-песенка - это все лишь набор единиц и нулей. То есть ты хочешь сказать, что в любом HEX-редакторе заложены "средства" сочинять mp3 и рисовать картины?

То что никто этого не делает, наверное, действительно вопрос владения логикой ;)
Re 23.06.06 22:33  
Автор: n0xi0uzz <Черкасов Виктор> Статус: Member
<"чистая" ссылка>
> > > > ООП -- это стиль программирования, а не
> язык.
> > Поэтому
> > > ОПП - это парадигма программирования, а не стиль.
> > Парадигма определяет стиль ;).
> Но не наоборот ;)
> (а вообще и само утверждение спорное)

Утверждение, что парадигма программирования определяет его стиль ни разу не спорное: http://ru.wikipedia.org/wiki/%D0%9F%D0%B0%D1%80%D0%B0%D0%B4%D0%B8%D0%B3%D0%BC%D0%B0_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F

> > > > принципы ООП можно реализовать и на Си.
> > > Принципы ООП можно реализовать и в Ассемблере, но
> > нужно ли
> > > это?
> > На самом деле, не всех устраивает реализация принципов
> ООП,
> > представленная средствами C++.
> Не всех. Но на C++ программирует большинство и я еще ни
> разу не видел языка, у которого объективно есть более
> рациональный подход к ООП.

Большинство на нем программирует, потому что в универе так научили. Некоторые, действительно, осознанно выбирают плюсы. Не суть, в общем. Речь-то не о том была.

> > > > Доказательство: вот такая вот дока:
> > > > http://netsago.ellsec.org/download/ooc.PDF
> > > Если в языке возможно что-либо
> > > реализовать, то это еще не значит, что он имеет
> для
> > этого
> > > все средства.
> > То есть что-то реализовать можно
> > употребил именно это слово), но средств для этого нет?
> Ну,
> > это уже вопрос владения логикой ;)).
> Программа, написанная на C++ с использованием ООП,
> жпеговская картинка из Фотошопа, mp3-песенка - это все лишь
> набор единиц и нулей. То есть ты хочешь сказать, что в
> любом HEX-редакторе заложены "средства" сочинять mp3 и
> рисовать картины?
>
> То что никто этого не делает, наверное, действительно
> вопрос владения логикой ;)

Ну, подобного я действительно не втречал, но, опять же, речь не об этом. Я привел тебе в пример конкретную доку, чтобы показать, что и как можно делать с помощью Си. И так делают. О чем споришь-то? ;)
Я бы сказал, что сама русскоговорящая Википедия -... 23.06.06 23:13  
Автор: Heller <Heller> Статус: Elderman
<"чистая" ссылка>
> > > > > ООП -- это стиль программирования, а не
> > язык.
> > > Поэтому
> > > > ОПП - это парадигма программирования, а не
> стиль.
> > > Парадигма определяет стиль ;).
> > Но не наоборот ;)
> > (а вообще и само утверждение спорное)
>
> Утверждение, что парадигма программирования определяет его
> стиль ни разу не спорное:
> http://ru.wikipedia.org/wiki/Парадигма_программирования

Я бы сказал, что сама русскоговорящая Википедия - сомнительный источник. Открой ту же страницу, но на английском: "A programming paradigm is a paradigmatic style of programming". Это разные вещи (в общем-то с таким понятием как "стиль программирования" я вообще лично не сталкивался, хотя слышать о нем приходилось много).

> > > > > принципы ООП можно реализовать и на Си.
> > > > Принципы ООП можно реализовать и в
> Ассемблере, но
> > > нужно ли
> > > > это?
> > > На самом деле, не всех устраивает реализация
> принципов
> > ООП,
> > > представленная средствами C++.
> > Не всех. Но на C++ программирует большинство и я еще
> ни
> > разу не видел языка, у которого объективно есть более
> > рациональный подход к ООП.
>
> Большинство на нем программирует, потому
> что в универе так научили. Некоторые, действительно,
> осознанно выбирают плюсы. Не суть, в общем. Речь-то не о
> том была.
Правда? А вот меня в Универе учили программировать на Паскале. А многие хорошие программисты вообще в институтах не учились. Ну да действительно не о том. Просто заявление, что "C++ выбирают потому что так сказали в универе" - тянет по масштабности на дискриминацию широких слоев населения. И вообще тема "C++ vs. все-все-все" уже достаточно широко избита. Самые ярые спорщики - паскалисты, которые единственное что могут разумного придумать, так это то что "C++ излишне усложнен" (само по себе смешное заявление). Вырвалось.

>
> > > > > Доказательство: вот такая вот дока:
> > > > >
> http://netsago.ellsec.org/download/ooc.PDF
> > > > Если в языке возможно
> что-либо
> > > > реализовать, то это еще не значит, что он
> имеет
> > для
> > > этого
> > > > все средства.
> > > То есть что-то реализовать
> можно
> > > употребил именно это слово), но средств для этого
> нет?
> > Ну,
> > > это уже вопрос владения логикой ;)).
> > Программа, написанная на C++ с использованием ООП,
> > жпеговская картинка из Фотошопа, mp3-песенка - это все
> лишь
> > набор единиц и нулей. То есть ты хочешь сказать, что в
> > любом HEX-редакторе заложены "средства" сочинять mp3 и
> > рисовать картины?
> >
> > То что никто этого не делает, наверное, действительно
> > вопрос владения логикой ;)
>
> Ну, подобного я действительно не втречал, но, опять же,
> речь не об этом. Я привел тебе в пример конкретную доку,
> чтобы показать, что и как можно делать с помощью Си. И так
> делают. О чем споришь-то? ;)
Я не спорю, а объясняю очевидные вещи, в которых ты запутался ;)
ООП - это надстройка на процедрным программированием. И надтройка не стиллистическая, а скорее синтаксическая, заложенная в самом языке.

Еще пример: любая математическая задача, требующая численных результатов, сводится в конце концов к арифметике. Любой интеграл в конечном счете придется считать циферками. Вот что говоришь ты: "Я тебе могу показать, что интеграл можно взять не пользуясь интегрированием!". И это действительно можно сделать (хотя бы геометрическими методами). Однако можно ли из этого делать вывод, что "интегрирование - это всего лишь такой стиль арифметики"?

ЗЫ. И вообще это флейм и оффтоп. Пора завязывать.
Re 24.06.06 00:32  
Автор: n0xi0uzz <Черкасов Виктор> Статус: Member
<"чистая" ссылка>
Я тут про Паскаль ни слова не сказал, кстати. А сказал я то, что в С++, возможно, представлена не самая лучшая реализация принципов ООП. И показал реально хорошую доку. И сделал это для того, чтобы у интересующегося товарища ООП ассоциировался не только с С++, какой вывод он, возможно бы сделал из твоего ответа, а отталкивался от реально поставленной задачи и программировал не шаблонами. И ни в чем я не запутался, я говорю вполне конкретные вещи, которые ни каких-либо дополнительных объяснений, ни оспаривания, ИМХО, не требуют. Насчет русскоязычной википедии согласен.

> Еще пример: любая математическая задача, требующая
> численных результатов, сводится в конце концов к
> арифметике. Любой интеграл в конечном счете придется
> считать циферками. Вот что говоришь ты: "Я тебе могу
> показать, что интеграл можно взять не пользуясь
> интегрированием!". И это действительно можно сделать (хотя
> бы геометрическими методами). Однако можно ли из этого
> делать вывод, что "интегрирование - это всего лишь такой
> стиль арифметики"?

Абсолютно неуместный пример.

> ЗЫ. И вообще это флейм и оффтоп. Пора завязывать.

Согласен.
[C++] Читайте стандарты 05.07.06 14:12  
Автор: honeybeer Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Уважаемые, вы зря спорите.
Стандарт ANSI однозначно определяет Си как процедурный, Си++ как ООЯ. Все остальное от лукавого =)
[C++] Драсти-приехали 05.07.06 17:24  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Уважаемые, вы зря спорите.
> Стандарт ANSI однозначно определяет Си как процедурный,

Это ж где в стандарте "ISO/IEC 9899:1990, Programming languages - C"

> Си++ как ООЯ. Все остальное от лукавого =)

или в стандарте "ISO/IEC 14882:2003, Programming languages — C++" такое написано?
Вам нужна точная фраза? И может быть чистый Си держит... 06.07.06 08:18  
Автор: honeybeer Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > Уважаемые, вы зря спорите.
> > Стандарт ANSI однозначно определяет Си как
> процедурный,
>
> Это ж где в стандарте "ISO/IEC 9899:1990, Programming
> languages - C"
>
> > Си++ как ООЯ. Все остальное от лукавого =)
>
> или в стандарте "ISO/IEC 14882:2003, Programming languages
> — C++" такое написано?
Вам нужна точная фраза? И может быть чистый Си держит полиморфизм, перегрузку операторов?
Да, мне нужна точная фраза. 06.07.06 14:00  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> > > Уважаемые, вы зря спорите.
> > > Стандарт ANSI однозначно определяет Си как
> > процедурный
,
> >
> > Это ж где в стандарте "ISO/IEC 9899:1990, Programming
> > languages - C"
> >
> > > Си++ как ООЯ. Все остальное от лукавого =)
> >
> > или в стандарте "ISO/IEC 14882:2003, Programming
> languages
> > — C++" такое написано?

Подтверждающая слова, которые я выделил болдом. А то понимаете ли какая незадача. Волею судеб у меня есть оба этих стандарта и у меня не вышло найти "однозначно определяющие" пункты. Вот хочу, чтобы Вы мне помогли избавиться от своей неграмотности

> Вам нужна точная фраза? И может быть чистый Си держит
> полиморфизм, перегрузку операторов?

Может напомнить Вам, КАКИМИ были первые компиляторы C++ или сами вспомните?

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

НО!!! Ведь была однозначно указана платформа. Человеку, сидящему под линуксом насрать на удобство. Более того, заявления о том, что не особо хочется трахать мозг конфигурацией X-сервера (видеокарты, шрифтов, раскладки и пр..), подбором ключей для монтирования и записи CD-ков и пр., воспринимаются примерно "А, лузер, не хватает мозгов ну и сиди в своей винде". Так что совершенно не факт на чем в данном случае вести разработку.

Ну а Ваша попытка сослаться на стандарт тоже не сделала Вам чести.
Опять же, вопрос логики. 06.07.06 11:25  
Автор: n0xi0uzz <Черкасов Виктор> Статус: Member
<"чистая" ссылка>
Я тут по ходу треда дал ссылку на документ, где написано, КАК это сделать.
К тому же, речь идет как раз не о стандартах и шаблонах, а о нестандартному подходу к программированию в целях максимальной оптимизации.
В целом я больше согласен, чем не согласен 06.07.06 14:20  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> К тому же, речь идет как раз не о стандартах и шаблонах, а
> о нестандартному подходу к программированию в целях
> максимальной оптимизации.

Но здесь на мой взгляд ты попал под воздействие стереотипов. C++ ничуть не медленнее C. Из средств, которые дают сравнительно большой оверхед в рантайме в плюсах только исключения и RTTI. Но эффективность исключений измеряется не количеством исключений в единицу времени, а УДОБСТВОМ передачи информации об исключении из места его возникновения (например библиотеки) в место, где известно, что с ним делать (в клиента этой библиотеки). Ну RTTI - это вообще страшная вещь. Ситуаций, когда он дейтствительно необходим очень мало, но есть криворукие программеры сующие его куда надо и куда не надо.
Твоя правда. 07.07.06 00:19  
Автор: n0xi0uzz <Черкасов Виктор> Статус: Member
<"чистая" ссылка>
Насчет скорости C++ и стереотипов согласен.
Я просто за то, что если в данной конкретной ситуации наиболее оптимальным решением будет использование C, то надо использовать C, а не уходить в сторону шаблонов и стандартов, которые вдолбили в мозг в универе/интернете или где-либо ещё. Грубо говоря, я имею ввиду то, что думать надо.
Огромное спасибо за разъяснение. С уважением. Пантер. 22.06.06 21:05  
Автор: panter_dsd Статус: Незарегистрированный пользователь
<"чистая" ссылка>
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach