Интел делает шаг в сторону гнома

>Да. Как видишь, ее легко пропустить.

угу. легко, если ты ССЗБ и ручками набираешь все. А нормальные люди используют макросы =)

>Но не все такие ошибки проявляются так быстро и так очевидно.

а как насчет неочевидности того, какой именно виртуальный метод ты вызываешь в с++? =)

Заметьте - аналог с УК придумал защитник плюсов.

>C я не упомянул потому, что в такой постановке вопроса он становится лишним. Насчет ABI ObjectiveC я ничего не знаю, но особых проблемм и принципиальной невозможности общего ABI для разных OOP языков не вижу.

>как у вас все просто...язык, на котором написано 90% ОС - лишний :)

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

>Интересно, при чем тут интерпретируемость ruby?

>хотя бы при том, что у интерпретируемых языков есть куча всякой изменяемой рантайм инфы о классах

Вероятно интерпретатор может предоставить интерфейс для всех остальных языков (раздавать метаданные). А в остальном это то-же ооп. То, что функции могут появляться и исчезать в runtime прекрасно описывается таким понятием как функтор.

>Но не все такие ошибки проявляются так быстро и так очевидно.

>а как насчет неочевидности того, какой именно виртуальный метод ты вызываешь в с++? =)

trace/gdb?

>trace/gdb?

мечта программиста - отлавливать логические ошибки в чужих библиотеках :)

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

>это мало связано с языком, на котором ты пишешь.

ага. это проблема ООП вообще.

учите лучше функциональщину - гораздо более эффективная штука, чем ООП =)

Про функциональщину ни чего не скажу, не знаком. Но imo именно эта проблема ООП - не столь критична (что плохого в данном проявлении полиморфизма? =) ).

> А межязыковой OOP ABI вряд ли стандартизируют в обозримом будущем

разве что после всеобщего перехода на .NET

Не обязательно.


Сейчас заглянул /usr/include/c++ и обнаружил там кроме стандартной библиотеки C++ еще и такое:

/usr/include/c++/4.1.1/javax/swing/JButton.h:


// DO NOT EDIT THIS FILE - it is machine generated -*- c++ -*-

#ifndef __javax_swing_JButton__
#define __javax_swing_JButton__

#pragma interface

#include <javax/swing/AbstractButton.h>
#include <gcj/array.h>

extern "Java"
{
namespace javax
{
namespace accessibility
{
class AccessibleContext;
}
namespace swing
{
class JButton;
class Icon;
class Action;
}
}
}

>> ну ладно. А питон сойдет?

> У Питона нет проблем с обращением к Си++ - объектам (ну или я их не вижу в повседневной работе).

как вам это удаётся?

> Сейчас заглянул /usr/include/c++ и обнаружил там кроме стандартной библиотеки C++ еще и такое:

> /usr/include/c++/4.1.1/javax/swing/JButton.h:

каким боком это "межязыковой OOP ABI"?

Нет, я просто не знал, что из C++ можно вызывать код на java(gjc). Нужно будет опробовать.

в смысле boost, swig, pyrex или ещё что?

>смысл в том, что зачем запрещать обращение к каким-то данным, если _средствами_ _самого_ _языка_ эти запреты легко обойти =)

Зачем делать на мосту перила, если все равно через них можно легко перелезть?

>угу. легко, если ты ССЗБ и ручками набираешь все. А нормальные люди используют макросы =)

Можно легко похерить данные класса, если ты ССЗБ и напрямую лезешь в память. А нормальные люди делают это через интерфейсные методы =)

>Можно легко похерить данные класса, если ты ССЗБ и напрямую лезешь в память. А нормальные люди делают это через интерфейсные методы =)

Неее... Нормальные люди на плюсах не пишут :) Если уж ООП - то жаба (жабакодеры хотя бы не делают вид, что на жабе можно либы и тулкиты писать). А с++ это кастрированный ООП. Худший из возможных вариантов =)

>Если уж ООП - то жаба (жабакодеры хотя бы не делают вид, что на жабе можно либы и тулкиты писать).

Если ты не знаешь ни одной жабовской либы, то это не значит что их не существует.

>А с++ это кастрированный ООП. Худший из возможных вариантов =)

Для тебя --- возможно. Как и для многих других, но они, к сожалению, об этом не узнали вовремя....

Кстати, почему в сравнении не участвовали разные "недо-ООП"?

>Если ты не знаешь ни одной жабовской либы, то это не значит что их не существует.

бугога

>Для тебя --- возможно. Как и для многих других, но они, к сожалению, об этом не узнали вовремя....

не спорь, так и есть =) кроме того, ООП не оправдал надежд. Очень маленький класс задач действительно эффективнее решать с помощью ООП

>Кстати, почему в сравнении не участвовали разные "недо-ООП"?

например? :)

>не спорь, так и есть =)

Пока что только на твоих словах

>кроме того, ООП не оправдал надежд. Очень маленький класс задач действительно эффективнее решать с помощью ООП

А что, я где-то утверждал что этот ООП --- панацея?

>например? :)

Примеры ты сам же и приводил :)

> жабакодеры хотя бы не делают вид, что на жабе можно либы и тулкиты писать

Ну уж Вы либо выражайтесь точнее, либо объясните наличие кучи библиотек на jakarta.apache.org, а также тулкитов swing и swt..

Кстати, на жабе есть методы доступа даже к приватным данным. Через недокументировнность всякую...

>Ну уж Вы либо выражайтесь точнее

я думаю тот факт, что явовские библиотеки вне виртуальной машины являются просто кучей нулей и единичек - всем известно :)

Интересно, в чем кастрированность ООП в C++? И чем java ООПее чем C++? Не стесняйтесь аргументировать.

ELF вне операционной системы, да и просто код на C без glibc - тоже.

А шаренные библиотеки - при отсутствии ldd?;) На самом деле, просто надо аккуратнее в определениях контекста;)

>Интересно, в чем кастрированность ООП в C++? И чем java ООПее чем C++? Не стесняйтесь аргументировать.

в том что в С++ ООП не чистый. А со наследием С =)

>ELF вне операционной системы, да и просто код на C без glibc - тоже.

не соскакивай. Речь идет именно о системе - в данном случае - никсах и чужеродности С++ в них

>А шаренные библиотеки - при отсутствии ldd?;) На самом деле, просто надо аккуратнее в определениях контекста;)

на случай, если фанатики с++ станут придираться к словам и передергивать? уже начали, собственно, я от них ничего другого и не ожидал. В отсутствии аргументации кроме как "а мне нравицо" они сейчас будут говорить что С плох для смартфонов потому что там жаба

В каком смысле не чистый? С точки зрения именно ООП C++ ~= java( - множественное наследование, + пара новых слов для уже существующих понятий). С другой стороны ООП - не единственный путь написания программ на C++, есть и совместимость с C(ни как не мешает ООП), есть и шаблоны (во многом развивает ООП, и повышает уровень абстракции). Что в этом плохого - я не знаю.

В данный момент в этом треде на фанатика C++ похожу только я, но я не фанатик. Просто я считаю, что C++ - обладает весьма редкими возможностями, которые я использую и считаю важными.

> С точки зрения именно ООП C++ ~= java

Нифигассе ~= ... Довольно разные объектные модели. Вообще, невозможность стандартизовать в унихе объектный ABI вытекает из того, что у разных языков разные объектные модели. И стандарт может образоваться только если сама ОС начнет продвигать некую (фиксированную, один раз выбранную) объектную модель, начиная с базовых библиотек (грубо говоря, линух++ и glib++) - и тогда ОО языки просто поделятся на те, кто справился под нее подстроиться, и те, кто "ниасилил". А коль скоро в унихе нет такой "избранной" модели - вопрос совместимого ОО ABI остается неразрешимым ИМХО. Ну или нужно собрать конференцию разработчиков компиляторов-интерпретаторов ОО языков для униха - и попробовать им договориться. Но ИМХО легче Вавилонскую башню построить..

> Просто я считаю, что C++ - обладает весьма редкими возможностями, которые я использую и считаю важными.

Нет там редких возможностей. Там есть редкое СОЧЕТАНИЕ возможностей. Одним это сочетание нравится. Другие считают его противоестественным (практически инцестом%).

>Просто я считаю, что C++ - обладает весьма редкими возможностями, которые я использую и считаю важными.

это говорит только о том, что кроме С++ ты мало что знаешь =) Есть языки с возможностями и поширше, и которые при этом не пытаются стать _системными_ ЯП

>Просто я считаю, что C++ - обладает весьма редкими возможностями, которые я использую и считаю важными.

это говорит только о том, что кроме С++ ты мало что знаешь =) Есть языки с возможностями и поширше, и которые при этом не пытаются стать _системными_ ЯП

imo Шаблоны - то, чего нет ни в java ни в C#(точнее различие между templates и generics) мне и нравится в C++.

Перегрузка операторов позволяющая нормально использовать базовые типы в templates мне тоже весьма нравится. Согласен, это скорее сочетание возможностей.

Когда я говорил, про ~= я имел в виду то, что imo выделение понятия интерфейс и отрезание множ. наследования классов практически ничего не изменили. Перегрузка и templates - мало связаны с ООП и в этом смысле ООП в java imo мало отличается от ООП в C++.

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

Но и без этого imo интерпретируемым языкам было-бы не сложно реализовать потдержку C++ABI(хотя-бы просто классов и вирт методов), что убрало-бы необходимость в таком геморое как перегонка ООП через C(по крайней мере перегонка будет через ОО язык). В обратном направлении imo сложнее, так-как в этих языках бывает возможность изменения классов в runtime =>> взаимодействие возможно через интерфейс интерпретатора, он раздает функторы.

Да, папа, я виноват =((. Я не учил perl, lisp, ocaml, erlang. Плохо смотрел(т.к. блевал) fortran. <не стеб>Согласен, что я чего-то не знаю. Но может ты меня просветишь, что именно ты имел в виду. Как-то туманно звучит фраза "что кроме С++ ты мало что знаешь".

Но imo на данный момент C++ наиболее подходит на роль системного языка для unix просто потому, что он есть в 99,999% процентах систем. Его библиотека почти всегда входит в необходимый минимум библиотек. Он обратно совместим с C(почти полностью). Он компилируется(мне сложно представить интерпретатор или jit в ядре). И по возможностям он точно превосходит C. </не стеб>

> точнее различие между templates и generics

Ну это же такие мелочи. Это почти "плюсы мне нравятся, потому что у них плюсовый синтакс".

> Согласен, это скорее сочетание возможностей.

Ок, на этой точке считаем локальный консенсус достигнутым.

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

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

> убрало-бы необходимость в таком геморое как перегонка ООП через C

Поймите, это очень ПОЛЕЗНЫЙ геморрой. Нейтральность базового языка относительно объектной модели (на С можно использовать любую модель) - это большое благо. И это замечательно, что уних не стандартизовал никакую объектную модель - это предоставляет возможность разным языкам городить любые объектные модели, не думая о совместимости с базовой. Таким образом, С - это пластилин, который может принимать форму той объектной модели, которую надо. Если Вам надо слепить в одну конструкцию деревянный кубик и деревянный шарик - Вы просто склеите их пластелином (ну или чем-то таким же бесформенным, принимающим любую форму). Так же и с ОО. Два ОО куска кода "разной формы" лучше склеивать чем-то не-ОО.

>Но imo на данный момент C++ наиболее подходит на роль системного языка для unix просто потому, что он есть в 99,999% процентах систем. Его библиотека почти всегда входит в необходимый минимум библиотек. Он обратно совместим с C(почти полностью).

только вот _системный_ язык Си с С++ не совместим :) Предлагаешь выкинуть Си?

>И по возможностям он точно превосходит C

как говорится, 4.2 - Вызывающе неверная информация

>Да, папа, я виноват =((. Я не учил perl, lisp, ocaml, erlang.

зря. Тот же erlang куда более подходит для создания серверного ПО :)

а перл невозможно превзойти в части обработки текстов.

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

а пихать с++ во все дыры - это даже не красноглазие, а лоботомия какая-то

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

ps: вот когда .so умрут, и их место займут сервисы - тогда будет все равно, на чем писать. ;)

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

это то, что я называю бесполезными фантазиями :) Это реализуемо только в рамках единой среды.

>imo Шаблоны - то, чего нет ни в java ни в C#(точнее различие между templates и generics) мне и нравится в C++.

человеку даны мозги, а человек с мозгами может расширить полезными фичами хоть ассемблер, хоть С :) Ключевое слово - scheme

> ps: вот когда .so умрут, и их место займут сервисы - тогда будет все равно, на чем писать. ;)

Не дай Бог дожить;)

>Не дай Бог дожить;)

не волнуйся, доживем. Закон Мура пока ещё действует =) А там, глядишь - и какой-нибудь аналог d-bus будут прям в процы вставлять. Вместе со стеком tcp/ip :)

> точнее различие между templates и generics

>Ну это же такие мелочи. Это почти "плюсы мне нравятся, потому что у них плюсовый синтакс".

Действуют они совершенно различно. Java пытается их заранее компилить, просто подставляя тип по умолчанию. Могу привести реальный пример, в котором это важно.

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

imo не настолько и важно, агрегация обычно спасает. Но согласен, для этих случаев нужно менять стандарт.

>И поэтому единственный способ насадить такое решение - вывести на уровень системных библиотек типа glibc (типа остальным объектным моделям деваться будет некуда - либо валить с платформы, либо как-то справляться).

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

>Поймите, это очень ПОЛЕЗНЫЙ геморрой. Нейтральность базового языка относительно объектной модели (на С можно использовать любую модель) - это большое благо. И это замечательно, что уних не стандартизовал никакую объектную мод...

imo эта нейтральность приводит к сильной потере typesafe. Хотя всякое бывает, может сейчас она и полезна.

>только вот _системный_ язык Си с С++ не совместим :) Предлагаешь выкинуть Си?

Он сделал это. Да, предлагаю.

>И по возможностям он точно превосходит C

>как говорится, 4.2 - Вызывающе неверная информация

example?

>imo Шаблоны - то, чего нет ни в java ни в C#(точнее различие между templates и generics) мне и нравится в C++.

>человеку даны мозги, а человек с мозгами может расширить полезными фичами хоть ассемблер, хоть С :) Ключевое слово - scheme

В C++ есть весьма хорошее средство. В C/java/C# его нет. Я понимаю, внешними препроцессорами можно все, что угодно сделать, но imo бред. Или вы что-то другое имели в виду? Или просто, что-бы что-то сказать?

>ps: вот когда .so умрут, и их место займут сервисы - тогда будет все равно, на чем писать. ;)

Да, блин, теперь пол ночи кошмаров обеспечено. =)

>Он сделал это. Да, предлагаю.

:)

в морг

>example?

нет, это с тебя example. Раз "превосходит" :)

>В C++ есть весьма хорошее средство. В C/java/C# его нет. Я понимаю, внешними препроцессорами можно все, что угодно сделать, но imo бред. Или вы что-то другое имели в виду? Или просто, что-бы что-то сказать?

генерацией кода можно сделать горааздо больше чем шаблонами

>Да, блин, теперь пол ночи кошмаров обеспечено. =)

ну кто ж тебе виноват... =)

>imo эта нейтральность приводит к сильной потере typesafe. Хотя всякое бывает, может сейчас она и полезна.

эээ...а как сохранить typesafe в межязыковой ооп-модели? :) Ввести одинаковые типы и одинаковые правила работы с ними? Так это получится сделать из кучи языков один, а не "единая ооп-модель". Такой велосипед уже есть - .net называется. :)

>в морг

Это относится ответ на первое предложение, или на второе? Если на первое, то sorry, но я уже постов 25 об этом говорю. И думал, что ты это понял. Если ко второму, то я уже те-же 25 постов говорю почему. И imo привел аргументы.

>example?

>нет, это с тебя example. Раз "превосходит" :)

хотя-бы то, как на C выглядит ООП, то, через какую жопу к C прикручиваются шаблоны. То, зачем все это используется в C++ imo объяснять не нужно(если хочется - спроси). Я понимаю, с помощью внешнего препроцессора можно и из assembler-а сделать конфетку, но это называется написанием еще одного языка программирования.

>Да, блин, теперь пол ночи кошмаров обеспечено. =)

>ну кто ж тебе виноват... =)

Ты виноват, такое страшное будущее предсказываешь =))

>imo эта нейтральность приводит к сильной потере typesafe. Хотя всякое бывает, может сейчас она и полезна.

>эээ...а как сохранить typesafe в межязыковой ооп-модели? :) Ввести одинаковые типы и одинаковые правила работы с ними? Так это получится сделать из кучи языков один, а не "единая ооп-модель". Такой велосипед уже есть - .net называется. :)

На сколько я понимаю, мы и обсуждали межязыковую объектную модель. Верояно базовые типы в такой ситуации должны совпадать(их не так и много). .net/java - практически то, но там imo много лишнего фиксируется. Хотя этого и совсем imho.