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

>> Или все-таки соглашаемся, что плюсовые либы - это худший вариант, чем плюсовые либы? =)

>Segmentation fault (core dumped)

Я так и знал - это бот!

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

Не понял, ты про что? Тебе не нравится, что ты не можешь из С обращаться непосредственно к закрытым данным класса? Так и из С++ ты тоже не сможешь этого сделать. Более того, ты и НЕ ДОЛЖЕН суметь этого сделать. Слово "инкапсуляция" тебе о чем-нибудь говорит?

>Я бы добавил еще и большую выразительность (за счет перегрузки операторов), но не стану: почему-то все считают, что перегрузка операторов - это плохо.

Не все, а только некоторые. Думаю, это те, кто не умеет этим безопасно пользоваться =)

>в обоих случаях прога грохнется :) обработал ты исключение или нет

Ну все, писец, приехали.... =)))

geek, ты жжош! Ты взаправду жжош!!! =)))))

>Ну все, писец, приехали.... =)))

я имел ввиду "не обработал ли ты исключение или не проверил результат"

вот так правильно =)

>То, что создатели этих языков договорились только до общего C вызова imo не есть хорошо, но не как не характеризует библиотеки каждого.

что значит "договорились"? С-вызов - это банальный call по адресу и последующий возврат в точку вызова. Если угодно - это фундаментальное свойство процессоров =) НИЖНИЙ УРОВЕНЬ. Других вариантов просто нет :)

>Geek, ты же вроде не нападаешь на java с требованием предоставить C биндинги к swing?

жаба - это вещь в себе. Хреновое взаимодействие с не-жабским окружением там заложено генетически. Единственный способ как-то пофиксить - это использовать взаимодействие через сокеты/dbus. Т.е. клиент-серверная модель :)

>Не понял, ты про что? Тебе не нравится, что ты не можешь из С обращаться непосредственно к закрытым данным класса?

ни к каким данным

>Слово "инкапсуляция" тебе о чем-нибудь говорит?

инкапсуляция - это не свойство ООП, если ты не в курсе =)

в общем, насколько я понял С++ популярен только у тех, кто не знает С =)

поколение next, блин.

>ни к каким данным

Хорошим стилем считается держать все данные закрытыми =)

>инкапсуляция - это не свойство ООП, если ты не в курсе =)

http://ru.wikipedia.org/wiki/Объектно-ориентированное_программирование

> Хорошим стилем считается держать все данные закрытыми =)<

Курс питона вам поможет, больной. Следующий.

>Хорошим стилем считается держать все данные закрытыми =)

тем не менее, в чем сакральный смысл с++ библиотеки? :)

>http://ru.wikipedia.org/wiki/Объектно-ориентированное_программирование

я даже читать не буду. Знаешь почему? потому что понятие "инкапсуляция" появилась ДО ООП =) А если ты и авторы статьи этого не знаете - это ваши трудности.

hint: Любая сишная библиотека является этой самой инкапсуляцией ;)

>я даже читать не буду. Знаешь почему? потому что понятие "инкапсуляция" появилась ДО ООП =) А если ты и авторы статьи этого не знаете - это ваши трудности.

Я знаю =)

Я лишь говорю, что инкапсуляция --- неотъемлемая часть ООП.

>Курс питона вам поможет, больной.

А что, в питоньем ООП все данные открыты?! Какой кашмар....

>Я лишь говорю, что инкапсуляция --- неотъемлемая часть ООП.

а плюсы у ООП где? зачем его использовать в _библиотеках_ ? :)

ради исключений? А что будет, если дергать такую либу из языка, где исключений нет? Опять упираемся в C++ - only?

>А что, в питоньем ООП все данные открыты?! Какой кашмар....

rtfm __getattr__ и __setattr__

На нем просто очень удобно писать =)

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

>На нем просто очень удобно писать =)

таки ты ниасилил С? =) btw, многие говорят что вижуал бейсик удобнее

imho, c++ - очень неудобный язык. неочевидный.

>Какая мне разница, чего и откуда кто-то там будет дергать, если благодаря обработке исключений сама либа будет устойчиво работать? Я могу вообще не выпускать исключения наружу, и совершенно пох, поддерживает их язык, на котором написан "дергающий" код, или не поддерживает.

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

>>Ты сказал, что она накладывала ограничения на распространение программ. Этого не было.

>а это, по-твоему, не ограничение, когда "вот тут можно, а вокруг - ни-ни!" ?

Ты сказал, что лицензия ограничивала распространение программ. Этого не было.

>>Стандарт .NET общий для: Си++, C#, J#. Стандарт общий Java: Java, Python, Groovy, (Ruby?).

>ты русский язык в албании учил?

Да кто бы уж говорил...

> Я говорю об _общем_ стандарте на ООП ABI . Понимаешь? ОБЩЕМ. Для виртуальных машин, интерпретаторов и компиляторов

Ну та жж0ш. Этот стандарт должен быть единым и для разных процессорных архитектур, да?

Ты знаешь, что общего стандарта вызовов нет и для не-ООП языков? Что ABI, о котором ты тут разливаешься - это Си ABI? И это не мешает ему использоваться из разных языков.

>даже для компиляторо единого стандарта на ООП ABI нет и не предвидится!

Да, гик не читатель, он писатель. Стандарт на Си++-ABI _есть_.

> в общем, насколько я понял С++ популярен только у тех, кто не знает С =)

Ты снова понял неправильно

> поколение next, блин.

Судя по твоей манере общения, ты и сам, мягко говоря, не очень стар.

> В реальности этого нет.

От тебя слова о "реальности" звучат просто смешно. Сколько раз ты допустил ляпы, показывающие незнакомство с предметом?

> Пишут на плюсах, и используют в плюсовой среде. Причин как правило две - "ООП это круто", "А на сях я не умею".

Си++ проггер не умеет писать на Си? Ну что тут сказать... Бу-га-га!

>А подумать, что они ограничивают рамки применения своего "продукта" они не могут.

А может, они не считают, что неудобство использования из чистого Си их ограничивает? Так же, как люди, которые пишут на Perl, Python, Ruby, Ocaml, Haskell?

Эх, гик, гик. Взрослей, набирайся опыта.

Инициализация структур - вещь удобная. А на плюсы забивать... О них просто не думаешь ваще, когда пишешь на С. Это примерно как думать "а будет ли это компилиться на жабе?".

>Ну та жж0ш. Этот стандарт должен быть единым и для разных процессорных архитектур, да?

хотя бы в рамках одной архитектуры. Впрочем, я уже говорил что это нереально. И именно поэтому либы на плюсах == геморрой

>Ты знаешь, что общего стандарта вызовов нет и для не-ООП языков? Что ABI, о котором ты тут разливаешься - это Си ABI? И это не мешает ему использоваться из разных языков.

да потому что C ABI прост как валенок. Проще некуда. Это до тебя никак не дойдет? Повторюсь - это нижний уровень. Всё. Можно реализовать параллельно другой ABI, но это все равно будет _процедурный_ ABI. ООП - оно уровнем ВЫШЕ. И реализовать единое представление объектов в памяти для всех ЯП НЕВОЗМОЖНО. ЕДИНОГО ООП ABI НЕ БУДЕТ НИКОГДА. Удавись.

>Да, гик не читатель, он писатель. Стандарт на Си++-ABI _есть_.

где? в С++? удивительно, если бы его там не было =)

я говорю про _взаимодействие_ с _не_ с++

>От тебя слова о "реальности" звучат просто смешно. Сколько раз ты допустил ляпы, показывающие незнакомство с предметом?

в студию примеры, как говорится

>Си++ проггер не умеет писать на Си? Ну что тут сказать... Бу-га-га!

не умеют. Потому что те, кто умеет - пишут на Си :)

>А может, они не считают, что неудобство использования из чистого Си их ограничивает?

какие неудобства?

> А что, в питоньем ООП все данные открыты?! Какой кашмар....

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

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

>>От тебя слова о "реальности" звучат просто смешно. Сколько раз ты допустил ляпы, показывающие незнакомство с предметом?

>в студию примеры, как говорится

Они давно в студии.

Кстати - так почему ты не убрал параметры со стека в вызове XSelectInput?

>Они давно в студии.

если тебе нечего сказать - лучше промолчи

>Кстати - так почему ты не убрал параметры со стека в вызове XSelectInput?

куда убрать? ты вообще понимаешь, о чем говоришь?

>Во-первых, ты выбрал простой вариант. Во-вторых, ты забыл убрать параметры со стека.

не заметил этой мессаги

отвечаю. Более сложные варианты отличаются лишь количеством push

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

тьфу блин, въехал, что ты имел ввиду

а что, одна команда после call сильно усложняет вызов?

>Левые ограничения в классах только создают ненужную головную боль.

В данном случае эти ограничения ИЗБАВЛЯЮТ от ненужной головной боли, потому что ты точно знаешь, что тот кто будет работать потом с созданным тобой классом, будет работать именно так, как ты это определил, через открытые методы. А не как ему взбредет в голову, случайно удалив указываемый объект, вызывая несуществующий элемент массива, или делая еще какие-нибудь неуправляемые вещи (которые легко отсекаются при обращении к данным через интерфейс класса).

> А что, в питоньем ООП все данные открыты?! Какой кашмар...

Интересно, как вообще можно данные внутри самого процесса вообще сделать закрытыми, помимо ограничений в самом языке? ;) Ассемблерные вставки - рулят... но некошерно, ибо непереносимо...

>если я правильно помню генплан, то скоро начнем обсуждать принципы построения AI в общем и системы распознавания образов в частности. Где-то постов через 50

количество постов зависит от ильича. Он неожиданно может что нибудь придумать, и тогда очередь AI может отодвинуться постов на 500

:-)

>В данном случае эти ограничения ИЗБАВЛЯЮТ от ненужной головной боли, потому что ты точно знаешь, что тот кто будет работать потом с созданным тобой классом, будет работать именно так, как ты это определил, через открытые методы. А не как ему взбредет в голову, случайно удалив указываемый объект, вызывая несуществующий элемент массива, или делая еще какие-нибудь неуправляемые вещи (которые легко отсекаются при обращении к данным через интерфейс класса).

в c++ уже отменили указатели и прямую работу с памятью? :)

afaik, нет. Получается интересная ситуация, когда в открытом поле поставили калитку и повесили табличку "не входить" :)

кроме того, использование c++ библиотеки (иначе какие классы и наследования) подразумевает использование с++, как основного языка проекта.

> В данном случае эти ограничения ИЗБАВЛЯЮТ от ненужной головной боли, потому что ты точно знаешь, что тот кто будет работать потом с созданным тобой классом, будет работать именно так, как ты это определил, через открытые методы. А не как ему взбредет в голову, случайно удалив указываемый объект,

Любые такие ограничения обойти все равно можно. Даже готовые решения есть, позволяющие получить доступ к любому объекту любого класса (видал такое, на асме). А чтобы не взбрело в голову, нужно головой этой самой ДУМАТЬ. Чтобы не нужно было помнить - рекомендуется метод для внешнего использования или нет, в питоне и готовое решение предлагается, в виде символов _ в имени.

>Использовать последнюю GPL версию ни кто не мешает. imo

Речь шла о том, что после изменения политики разработчиков qt, в результате которой произошла смена лицензии, придется сформировать сообщество разработчиков GPL QT, на что уйдет много времени.

>в c++ уже отменили указатели и прямую работу с памятью? :)

Ну при желании можно и х** сломать =)

>Ну при желании можно и х** сломать =)

это называется "аргументы кончились" ? =)

Нет.

Просто странные у тебя рассуждения: если можно получить доступ прямым обращением к памяти --- то значит нафиг не надо инкапсулировать данные, делаем их открытыми? о_О

>Просто странные у тебя рассуждения: если можно получить доступ прямым обращением к памяти --- то значит нафиг не надо инкапсулировать данные, делаем их открытыми?

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

Можно и jpg в виме смотреть, но этого обычно не делают.

>>То, что создатели этих языков договорились только до общего C >>вызова imo не есть хорошо, но не как не характеризует библиотеки >>каждого. 

>что значит "договорились"? С-вызов - это банальный call по адресу и >последующий возврат в точку вызова. Если угодно - это >фундаментальное свойство процессоров =) НИЖНИЙ УРОВЕНЬ. Других >вариантов просто нет :)

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


call или jmp - вызов на уровне ассемблера(НИЖНИЙ УРОВЕНЬ).


>>Geek, ты же вроде не нападаешь на java с требованием предоставить C >>биндинги к swing?


>жаба - это вещь в себе. Хреновое взаимодействие с не-жабским >окружением там заложено генетически. Единственный способ как-то >пофиксить - это использовать взаимодействие через сокеты/dbus. Т.е. >клиент-серверная модель :)


java/.net/ruby/.... - можно, C++ - нельзя?

>Инициализация структур - вещь удобная. А на плюсы забивать... О них >просто не думаешь ваще, когда пишешь на С. Это примерно как думать >"а будет ли это компилиться на жабе?".

Классы и шаблоны - вещь удобная. А на С забивать... О них просто не думаешь ваще, когда пишешь на С++. Это примерно как думать "а будет ли это компилиться на ассемблере?".

>java/.net/ruby/.... - можно, C++ - нельзя?

отличий между жабой, net, ruby и C++ не видишь? тады в морг =)

>Классы и шаблоны - вещь удобная. А на С забивать... О них просто не думаешь ваще, когда пишешь на С++. Это примерно как думать "а будет ли это компилиться на ассемблере?".

и в результате получается вещь в себе. Которая вроде бы есть, но которая стандартом не станет :)

вижу, но все они весьма замкнуты.

Я согласен, что стандартом она не стала. Но несовместимость с ruby/python/java/... - не вина C++.

Эти языки появились позже C++, и часто нуждаются в его библиотеках ==> м.б. это их проблеммы и нежелание договариваться о стандартах?

>Но несовместимость с ruby/python/java/... - не вина C++.

а несовместимость с Си? Кроме того, это вообще не чья-либо вина, вот если бы ABI у С++ было такое же как в ObjectiveC, то проблем не было бы вообще :)

>Эти языки появились позже C++, и часто нуждаются в его библиотеках ==> м.б. это их проблеммы и нежелание договариваться о стандартах?

предложи ООП ABI, который подойдет и компилируему языку (С++) и интерпретируемому языку (Ruby). Только боюсь. ничего не выйдет.

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

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

Проблеммы совместимости с чем угодно - забота интерпретатора/runtime libs.

> тьфу блин, въехал, что ты имел ввиду

Наконец-то

> а что, одна команда после call сильно усложняет вызов?

Да. Как видишь, ее легко пропустить. В данном случае это не так страшно, потому что прога быстро упадет. Но не все такие ошибки проявляются так быстро и так очевидно.

> в c++ уже отменили указатели и прямую работу с памятью? :)

> afaik, нет. Получается интересная ситуация, когда в открытом поле поставили калитку и повесили табличку "не входить" :)

Вот как раз это называется "аргументы кончились". Знаешь, воровство и убийства тоже запрещены. Но какой-нибудь отморозок может подойти к тебе, дать арматуриной по голове, и забрать бумажник. Так что, отменим УК?

> Так что, отменим УК?

А что - плюсовый компилятор уже выдает хотя бы warnings (не говоря уж про error) на работу с обычными указателями?

Нет, а должен?

Использование указателей может быть разное, и далеко не всегда оно нарушает инкапсуляцию.

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

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

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

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