LINUX.ORG.RU

C++ специфичен сильно, да и много на программиста нагрузки, в java лучше.

Solace ★★
()

В каком из языков лучшая реализации ООП?

ни в каком, шо там шо там секс с байтиками и куча костылей

Deleted
()

Java. Нет множественного наследования (и не нужно), нет непонятного траходрома с public/protected/private наследованием. Теперь, вот, правда, есть имплементация в интерфейсах. Ну ок, не так страшно же.

Вопрос господам: слышал от пары сеньоров, что имплементация интерфейса и расширение класса в java вполне себе называется наследованием. Потому они считали, что в java множественное наследование «есть» и пытались этим троллить нубов. Проблема в их головах, я правильно понял?

bytecode ★★
()

smalltalk

по сабжу - Java, разумеется

jcd ★★★★★
()

cast анонiмус

а вообще

эскобар.жпег

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

Теперь, вот, правда, есть имплементация в интерфейсах. Ну ок, не так страшно же.

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

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

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от bytecode

Это какие-то неправильные сеньёры, наследование - это расширение функционала родителя + возможность полиморфизма. Реализация интерфейса - это всего лишь возможность объекта «играть какую-то роль», но назвать это наследованием нельзя.

Jefail ★★★★
()

лучшая реализации ООП

Какого из?

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

Java. Нет множественного наследования (и не нужно), нет непонятного траходрома с public/protected/private наследованием.

Интересная логика. Если множество A есть всего лишь подмножество B, то A оказывается лучше? Т.е. «лучше» в данном случае синоним «меньше»?

По теме: лучше в Eiffel, там к реализации ООП в статически-типизированном языке отнеслись очень тщательно. И получилось, что удивительно, вполне понятно.

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

наследование - это расширение функционала родителя

Воу, а кто такой «функционал» ?

Deleted
()

В C++ возможностей больше. На практике возможностей Java хватает. Хороший пример реализации ООП можно посмотреть в Erlang.

Legioner ★★★★★
()

В каком из языков лучшая реализации ООП?

Лучшая для чего? А так ООП в Java слизано с С++ практически 1 в 1, разница в деталях, хоть иногда и важных (рефлексия, множественное наследие и т.д.).

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

В Erlang есть ООП?

ООП есть везде в зависимости от фантазии и его определения.

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

А то! Все Erlang-еры с подачи Джо Армстронга в этом уверены!

PS. В дерьмокниге «Seven Concurrency Models in Seven Weeks» в главе «Actors» есть даже раздел, озаглавленный «More Object-Oriented than Objects». Так что здесь вам не тут :)

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

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

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

Erlang лучше поддерживает ООП, чем ООЯ.

Я бы хотел узнать что имеется ввиду под ООП в данном случае. Потому что некие закрытые снаружи «объекты», общающиеся через сообщения, можно писать вообще на чём угодно.

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

Потому что некие закрытые снаружи «объекты», общающиеся через сообщения, можно писать вообще на чём угодно.

Вот это и имелось в виду.

eao197 ★★★★★
()

В обоих говно :-) Продолжим :-) Итак, спасибо за простынь от eao197 - http://www.linux.org.ru/forum/talks/12318922?cid=12324988 (комментарий) :-) Именно такая и ожидалась :-) Правда, не обязательно было корякать f_tag, g_tag, можно было бы обойтись и enum class F { f, g } и специализировать структуру call_traits по ним :-) Ну да ладно :-) Что же касается http://www.linux.org.ru/forum/talks/12318922?cid=12324998 (комментарий), то нет, нужен один шаблон, в котором имеет смысл подставить только 2 функции, а другие бессмысленны :-) Также отличился и другой эксперт - http://www.linux.org.ru/forum/talks/12318922?cid=12325004 (комментарий), предложив использовать static_assert :-) Дорогой аноним :-) Да, можно сигнатуру ф-ии сделать параметром шаблона, но ведь было ожидаемо, что в такую ловушку ты и попадёшься :-) Видишь ли, в template<typename F> void h(F f) можно передать не только ф-ю, но и, как это принято у цепепешников говорить умное слово ФУНКТОР, который в template<void(*F)()> h() не передать :-) Что же касается твоего static_assert(F == f, ":-)"), то да будет тебе известно, но смайлик ты так и не увидишь, ибо компиляция не выполнится не по причине провала утверждения, а по причине неконстантного выражения F == f, если в качестве F будет не f :-) Смекаешь, эксперт? :-) Т.е. с таким же успехом static_assert(F == f, ":-)") можно заменить на constexpr auto a = F == f, и компиляция так же зафейлится :-) Так что зря ты утруждал себя написанием смайлика :-)

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

Видишь ли, в template<typename F> void h(F f) можно передать не только ф-ю, но и, как это принято у цепепешников говорить умное слово ФУНКТОР, который в template<void(*F)()> h() не передать :-)

Дура ты вертлявая, ты сам сказал, что нужно передавать только две определенные функции. А с функтором код не скомпилируется, как ты и хотел в своем условии. А теперь ты виляешь задом.

Что же касается твоего static_assert(F == f, ":-)"), то да будет тебе известно, но смайлик ты так и не увидишь, ибо компиляция не выполнится не по причине провала утверждения, а по причине неконстантного выражения F == f, если в качестве F будет не f :-)

Иди полы мой:

~$ cat ./test.cpp
#include <cstdio>

int f()
{
    return 100;
}

int g()
{
    return 100;
}

template<int(*F)()> 
int dummy()
{
    static_assert( F == f, ":-)" );
    
    return F();
}

int main()
{
    printf( "%d\n", dummy<g>() );
}
~$ clang++ -std=c++11 ./test.cpp
./test.cpp:16:5: error: static_assert failed ":-)"
    static_assert( F == f, ":-)" );
    ^              ~~~~~~
anonymous
()
Ответ на: комментарий от anonymous

А теперь ты виляешь задом.

Неа, я развиваю тему :-)

Иди полы мой:

Иди:

~ $ g++ -std=c++14 test.cpp
test.cpp: In instantiation of ‘int dummy() [with int (* F)() = g]’:
test.cpp:23:30:   required from here
test.cpp:16:5: error: non-constant condition for static assertion
     static_assert( F == f, ":-)" );
     ^
test.cpp:16:5: error: ‘(g == f)’ is not a constant expression
Т.е. даже матёрые цепепешиники этот самый цепепе до конца не знают :-) Вай какой язык хороший :-)

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

Поскольку из основной темы вы слились, то остается повторить здесь:

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

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

Т.е. без бесполезных простыней:

void g()
{ }

void f()
{
  constexpr auto a = f == g;
}

~ $ g++ -c -std=c++14 test2.cpp
test2.cpp: In function ‘void f()’:
test2.cpp:6:24: error: ‘(f == g)’ is not a constant expression
   constexpr auto a = f == g;
                       ^
anonymous
()
Ответ на: комментарий от eao197

Вот это и имелось в виду.

Значит ли это, что ООП есть в ассемблере, C, Haskell, Scheme и вообще всех остальных языках программирования?

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

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

Причём тут статическая типизация? :-) Поинт в том, что в цепепе язык шаблонов не ахти, а макросы считаются злом :-) Т.е. даже тупо сравнить 2 строчки в компайл-тайме - это целая проблема, решаемая километровыми трейтсами :-) Бугага :-)

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

ООП есть в ассемблере, C, Haskell, Scheme

Сам подумай :-) «ООП» - «объектно-ориентированное программирование» :-) «объектно-ориентированное» - это прилагательное :-) Понимаешь? :-) А «программирование» - это существительное :-) Правда, что на ассемблере, C, Haskell, Scheme можно программировать? :-) Если правда, то вопрос лишь в том, как это делать :-) А остальное *приложится* :-)

anonymous
()

почитай хотя бы про runtime polymorphism в крестах и окстись! за такие вбросы разве не положено -20?

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

Неа, я развиваю тему :-)

Можешь называть это так, суть не меняется.

Т.е. даже матёрые цепепешиники этот самый цепепе до конца не знают :-) Вай какой язык хороший :-)

Это недоработка в gcc, в данном случае g - это address constant expression, который допустим в constexpr и static_assert, и msvc и clang это знают.

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

Я бы хотел узнать что имеется ввиду под ООП в данном случае. Потому что некие закрытые снаружи «объекты», общающиеся через сообщения, можно писать вообще на чём угодно.

Это и есть идеал ООП. Ещё важна иммутабельность возвращаемых значений, чтобы с объектом можно было общаться исключительно через его интерфейс, а не косвенно. Код в ОО-стиле действительно можно писать практически на чём угодно. Например подсистема VFS в ядре Linux использует полиморфизм, хоть и написана на чистейшем C. Другой вопрос — насколько это удобно делать.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Значит ли это, что ООП есть в ассемблере, C, Haskell, Scheme и вообще всех остальных языках программирования?

Походу, вы воспринимаете мои слова всерьез. Я лишь сказал, что после публикации статьи Армстронга, на которую вы привели ссылку, некоторые Erlang-еры стали озвучивать мнение о том, что в Erlang-е есть поддержка ООП. Как раз потому, что со слов Алана Кея ООП — это про обмен сообщениями, а раз так, то ООП в Erlang-е есть.

Сам я это мнение не разделяю.

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

Это недоработка в gcc, в данном случае g - это address constant expression, который допустим в constexpr и static_assert, и msvc и clang это знают.

Да? :-) Ну ладно, я же не знал, что это недоработка gcc, поэтому и считал, что единственным решением являются простыни с полными специализациями шаблонов структур со статическими функциями-членами, именуемыми в простонародье «трэитсами» :-) Кстати, спасибо, кое-что новое узнал (про баг в gcc) :-)

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

Да, забыл, что разговариваю с идиотом.

Это не аргумент :-) Слив засчитан :-)

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

Хороший пример реализации ООП можно посмотреть в Erlang.

Зашёл, чтобы это написать.

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

вы воспринимаете мои слова всерьез

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

некоторые Erlang-еры стали озвучивать мнение о том, что в Erlang-е есть поддержка ООП

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

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

В дерьмокниге «Seven Concurrency Models in Seven Weeks»

Теперь понятно откуда ты черпаешь знания :-)

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

Потому что некие закрытые снаружи «объекты», общающиеся через сообщения, можно писать вообще на чём угодно.

Как всегда, всё упирается не в то, что можешь писать ты, а в то, что может написать твой сосед (и с чем тебе потом придётся трахаться).

Конечно, упёртый фортранщик напишет фортран-программу и на Erlang. Но ему будет трудно. Erlang-программисту достаточно быть более-менее ленивым, и он будет писать объектно-ориентированные программы.

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

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

Ну, кто ж тебе виноват, что ты такой непонятливый.

Я вот заметил там ООП ещё до того, как выучил синтаксис до конца.

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

Я вот заметил там ООП ещё до того, как выучил синтаксис до конца.

gen_server, сообщения и пачка костылей - это не ООП.

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