LINUX.ORG.RU
Ответ на: комментарий от dave

> Но, создавать подобие объектов и плодить их иерархию на голом C - это уже полный абзац... (или речь об объектной ориентированности в GObject все-таки не идет?)

Язык С, не будучи ОО, _годится_ для ОО программирования. Не сильно меньше, чем ОО С++. Примеры - windows.h, gobject, xlib.

svu ★★★★★
()
Ответ на: комментарий от svu

> Язык С, не будучи ОО, _годится_ для ОО программирования. Не сильно меньше, чем ОО С++. Примеры - windows.h, gobject, xlib.

Согласен, что годится. Здесь можно даже вспомнить, и про первый компилятор для C++, создававший C-код из C++ -кода, и загаловочный файлы COM, где таблица виртуальных методов имитировались также на голом C. Но речь идет о другом. Считаю, что заниматься OO-программированием (и ООА, и OOD) значительно проще, если сущности этого самого OO поддерживаются на уровне языка.

Безусловно, стандартный C++ не так идеален. Там не хватает пары вещей, и мне, например, нравятся такие расширения Qt как сигналы и слоты (напомниающие делегаты .NET). Но как средство OO-программирования С++ - лучше, чем просто C.

С другой стороны, я видел код очень многих программеров (на C, C++, Delphi, C#, Java). Часто то ли там использовалось OO? Нет, довольно редко, даже если бы в нем был смысл. Причем, это - люди с вышим техническим образованием (специальность ПС), пару-другую лет занимающихся оффшором.

Может быть, вопрос даже следует поставить в иную плоскость.

Для какого способа ОО-программирования годится "просто C"? Для использования библиотек (1), или для их создания (2)?

Мой личный ответ: (1) - да, (2) - это просто тихий ужас...

dave ★★★★★
()
Ответ на: комментарий от dave

>> "Там не хватает пары вещей, и мне, например, нравятся такие расширения Qt как сигналы и слоты"

Советую взглянуть на:

http://www.boost.org/doc/html/signals.html

великолепная штука без всяких трольских извратов с "расширениями С++".

Ron
()
Ответ на: комментарий от Ron

Да, но у этого решения на шаблонах (см. также libsig++, являющийся основой для gtk--), есть один недостаток - оно может не очень хорошо поддерживаться некоторыми компиляторами. gcc3 обычно с такими штуками работает "на ура", а вот например у msvc6, помнится, были проблемы.

int19h ★★★★
()
Ответ на: комментарий от svu

> Язык С, не будучи ОО, _годится_ для ОО программирования. Не сильно меньше, чем ОО С++. Примеры - windows.h

windows.h - OO-программирование? Не смешите =)

А вот из удачных примеров могу еще вспомнить QNX Photon.

int19h ★★★★
()
Ответ на: комментарий от Ron

> Советую взглянуть на: > http://www.boost.org/doc/html/signals.html > великолепная штука без всяких трольских извратов с "расширениями С++".

Спасибо! Это - очень полезная ссылка для меня. Прежде не знал о ней.

dave ★★★★★
()
Ответ на: комментарий от Ron

И еще. Тролльские "извраты" ведь не ограничиваются сигналами и слотами - там еще и метаданные всякие, для GUI-дизайнеров.

int19h ★★★★
()
Ответ на: комментарий от int19h

Re:

А Александр Боковой давеча на GObject'е динамическую типизацию с загрузкой типов из внешних источников (XML, SQL) замутил. Будем соревноваться, что гибчее? :-)

AlexM ★★★★★
()
Ответ на: Re: от AlexM

А я где-то вел речь о гибкости? =)

И вообще, для вышеописанных извратов имхо доктор все же прописал Java.

int19h ★★★★
()
Ответ на: Re: от AlexM

Извиняюсь, не понял, о чем идет речь. Я думал вы о рефлекшенах всяких =)

Ладно, тогда .NET с его System.Reflection.Emit. Это имхо переплюнуть сложно.

int19h ★★★★
()
Ответ на: Re: от AlexM

Эээ, в smalltalk? =)

int19h ★★★★
()
Ответ на: Re: от AlexM

Хотя вот кстати подумалось, что если скомбинировать этот ваш "динамический GObject" с libtcc (который Tiny C Compiler), то пожалуй что и да, очень даже можно...

int19h ★★★★
()
Ответ на: комментарий от dave

> Считаю, что заниматься OO-программированием (и ООА, и OOD) значительно проще, если сущности этого самого OO поддерживаются на уровне языка.

А я не спорю. Просто С++ не годится на роль той самой Silver Bullet. И Java не очень годится. И С#. А человек - существо адаптивное, быстро привыкает в ОО программированию на не-ОО языке.

> Для какого способа ОО-программирования годится "просто C"? Для использования библиотек (1), или для их создания (2)?

> Мой личный ответ: (1) - да, (2) - это просто тихий ужас...

Вот тут я в корне несогласен. Мне очень нравятся ОО библиотеки на С. Более того, я не знаю ни одной более-менее обширной библиотеки на С (особенно - в областях, относящихся к GUI), где бы не был использован ОО подход. Вы знаете? И те из них, которые хорошо продуманы - вполне удобны в использовании. gtk/gobject - из их числа.

svu ★★★★★
()
Ответ на: комментарий от int19h

> windows.h - OO-программирование? Не смешите =)

Да, это ОО подход. Местами криво реализованный - но тем не менее ОО. Что такое окно, если не объект, у которого реальное содержимое запрятано от глаз за безликим Handle?

> А вот из удачных примеров могу еще вспомнить QNX Photon.

Возможно. Я не видел их API, ничего не могу сказать...

svu ★★★★★
()
Ответ на: комментарий от svu

Это не `OO' подход. `Объектный', но не `Объектно-ориентированный'. Потому что есть инкапсуляция, но нет наследования.

Ron
()
Ответ на: комментарий от Ron

> Потому что есть инкапсуляция, но нет наследования.

Возможно, тут Вы правы. Я не помню, как там дела с наследованием (100 лет не видел в глаза windows.h). Ну я же признал уже - местами кривоватая реализация:)

svu ★★★★★
()
Ответ на: комментарий от Ron

> Это не `OO' подход. `Объектный', но не `Объектно-ориентированный'. Потому что есть инкапсуляция, но нет наследования.

Строго говоря, сабклассинг можно обозвать наследованием, т.к. можно перехватывать window messages и обрабатывать их по своему желанию. Так что полиморфизм имеет место быть.

int19h ★★★★
()
Ответ на: комментарий от sin_a

> письмо спамобойка не прибила?

Не прибила. А вот я до вас не могу достучаться:

... while talking to time.fannet.ru.:

>>>>>> DATA <<< 550 5.0.0 error 377 554 5.0.0 Service unavailable

int19h ★★★★
()
Ответ на: комментарий от svu

>> Для использования библиотек (1), или для их создания (2)?

>> Мой личный ответ: (1) - да, (2) - это просто тихий ужас...

> Вот тут я в корне несогласен. Мне очень нравятся ОО библиотеки на С. Более того, я не знаю ни одной более-менее обширной библиотеки на С (особенно - в областях, относящихся к GUI), где бы не был использован ОО подход. Вы знаете? И те из них, которые хорошо продуманы - вполне удобны в использовании. gtk/gobject - из их числа.

Обращаю внимание - речь шла о том, что если _использовать_ такие библиотеки вполне можно, то вот _создавать_ их - очень тяжело. Хотя бы потому, что требует создания всей соответствующей инфраструктуры (GObject), и ее корректного применения в дальнейшем (компилятор-то в полной мере не может следить за происходящим, т.к. не имеет представления о всех этих ОО-штучках).

int19h ★★★★
()
Ответ на: комментарий от svu

> А я не спорю. Просто С++ не годится на роль той самой Silver Bullet. И Java не очень годится. И С#. А человек - существо адаптивное, быстро привыкает в ОО программированию на не-ОО языке.

Полностью согласен. Для одних задач хорош C++, а для других - Java или C#. И вряд ли, существует "золотая середина"...

> Вот тут я в корне несогласен. Мне очень нравятся ОО библиотеки на С. Более того, я не знаю ни одной более-менее обширной библиотеки на С (особенно - в областях, относящихся к GUI), где бы не был использован ОО подход. Вы знаете? И те из них, которые хорошо продуманы - вполне удобны в использовании. gtk/gobject - из их числа.

Вот, здесь хорошо за меня ответил int19h - поддерживаю его.

_____

Могу затронуть еще одну прелюбопытную тему :)

В последнее время стало возникать понимание того, что одного OO (даже в купе с процедурным подходом) - недостаточно для программирования. Мы создаем языки для того, чтобы потом с помощью их создавать модели объектов и процессов реального мира, а наш мир много богаче, чем то, что можно уложить в рамки просто "классов", "объектов", "функций" и т.п. Поэтому, в будущем возможно появление совершенно новых технологий программирования. Скорее всего, этот процесс - даже бесконечный...

Так что, боюсь, одним gobject не обойтись! :)

Кстати, на сановском сайте java.sun.com изредка бывают очень интересные статьи на эту и похожие темы.

dave ★★★★★
()
Ответ на: комментарий от int19h

> Обращаю внимание - речь шла о том, что если _использовать_ такие библиотеки вполне можно, то вот _создавать_ их - очень тяжело.

Извините, я Вас неправильно понял. Да, создание ОО структуры на С - процесс тяжкий и муторный, это правда. Но ведь у нас уже есть GObject:)

И компилятор действительно не очень помогает - одна надежда на правильные макросы (которые, увы, в С очень тупы и ненадежны).

Да, не все в порядке в датском королевстве - но в мире GObject жить вполне можно...

svu ★★★★★
()
Ответ на: комментарий от dave

> Поэтому, в будущем возможно появление совершенно новых технологий программирования. Скорее всего, этот процесс - даже бесконечный...

Это очевидно. Кто, вообще, тут сказал, что ОО - венец программистской мысли?:)) Прогресс - бесконечен и неизбежен. Неотвратим, я бы сказал:))

svu ★★★★★
()
Ответ на: комментарий от svu

Да кто ж спорит, что можно. А на макросах я вам и на nasm'е объектно-ориентированное наваяю - тоже можно будет =)

Но все равно это сродни закручиванию шурупов кувалдой, имхо...

int19h ★★★★
()
Ответ на: комментарий от svu

> Да, создание ОО структуры на С - процесс тяжкий и муторный

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

int19h ★★★★
()
Ответ на: комментарий от int19h

> Речь шла о том, что и использование этой самой структуры для создания своих классов - тоже занятие не для слабонервных. А вот использовать готовые классы уже можно без особых проблем.

Да, создавать эти классы - тоже не пикник. Правда, немного упрощает жисть gob. А использование - действительно достаточно просто и ненапряжно...

svu ★★★★★
()
Ответ на: комментарий от svu

в гамаке, стоя, в противогазах...

> Да, создавать эти классы - тоже не пикник.

У меня складывается впечатление, что большинство разработчиков GNOME родом из Китая -- сами себе создают проблемы, а потом героически решают.

Куда ни глянь -- везде "закат Солнца вручную"...

Dselect ★★★
()
Ответ на: в гамаке, стоя, в противогазах... от Dselect

> У меня складывается впечатление, что большинство разработчиков GNOME родом из Китая -- сами себе создают проблемы, а потом героически решают.

Проблемы созданы задолго до гнома. Гном их пытается решить. Так же как КДЕ. Методы решения - разные. То, что КДЕ считает, что использование С++ решает некоторые проблемы - это его право. Гном считает, что С++ (в качестве базового языка) создает больше проблем, чем решает. Я НЕ ХОЧУ в этот могосотенный тред еще и укладывать ставший традиционным флейм про С++:)

svu ★★★★★
()
Ответ на: комментарий от int19h

К сожалению, тут я Вам не помощник. Я код на Objective видел издалека и немного. Есть подсознательное ощущение, что эта вестч менее крива, чем С++ - но браться это доказывать я не возьмусь (вообще, это может быть ошибочное мнение). Так что лучше Вы нам про него расскажите:)

svu ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.