C++ vs Java (в реализации ООП)

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

О том, как трахаться с Erlang, я могу писать очень много. Начиная с библиотек из стандартной поставки, и заканчивая плачевным состоянием килотонн говнокода с github и отсутствием репозитария вроде cpan или hackage.

Кстати, я давно заметил странную тенденцию программистов на Erlang пихать это несчастное ООП на gen_server повсюду, даже где это сто лет не нужно.

В C++ гибче. Но надо знать, что делаешь. И уметь.

В Java практичнее для быдлокодинга, что для индустрии важнее.

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

Сейчас сделали реализацию в интерфейсах. И эту реализацию «наследуют» классы, которые реализуют интерфейс.

Бла бла бла. Пишите код, мазафакерз!!!

C++, Java - это прикладные языки для решения реальных задач. Их пользователи делом заняты и на абстрактный срач у кого длиннее (вызов main) не поведутся.

Хочешь потрепаться - упоминай Lisp, Haskel и Erlang.

А по теме не важно какой у кого OOP, главное чтобы круглые скобочки к месту использовались.

Бла бла бла. Пишите код, мазафакерз!!!

Глаза уже и так красные от цепепе :-) Кстати, а кому-нибудь цепепе по ночам снится? :-)

Глаза уже и так красные от цепепе :-)

Ёптыть, что мешает зарабатывать на жизнь программированием на C (за который вы тут регулярно агитируете) или на Lisp-е (на который вы придрачиваете)?

делом заняты и на абстрактный срач не поведутся.
java

looool

О том, как трахаться с Erlang, я могу писать очень много.

Я тоже. Так ООП вообще ущербная концепция, всё правильно.

ООП на gen_server

ООП — это не gen_server, это процессы и сообщения.

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

Могу и на C, могу и на Lisp :-) Мне другое интересно :-) Почему макре, который проверяет параметр на предмет того, что он может быть только f или g, т.е.

(defmacro run-f-or-g (f)
  (if (member f '(f g))
      `(,f)
      (error "Neither f nor g")))

PS. Один мой знакомый web-дизайнер, когда увидел какой-то заголовочный файлик из boost воскликнул: «вот это да, сколько тут HTML-тегов!» :-) Это так его шаблоны цепепе вдохновили :-) Гг :-)

Могу и на C, могу и на Lisp :-)

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

макросы - суть зло? :-)

Кто вам доказывает, что в Lisp-е макросы — суть зло?

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

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

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

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

В C без макр вообще никак :-) В C++ можно без макр, но бывают случаи, когда когда иерархии состоят из сотен классов, которые имеют общего предка и вместо написания бойлерплэйта из десятка строк в каждом классе гораздо более разумно упаковать этот бойлерплэйт в макру, которую писать в области объявлений членов класса :-) Так это макры - это добро :-) Хватит ли ума понять? :-)

Сказано, что можно

Раз вы этого не делаете и глаза у вас красные от C++, то, очевидно, что нельзя. Так почему?

Но какое это имеет отношение к справедливой критике необходимости написания километровых простыней «трэитсов» лишь для того, чтобы оставаясь в рамках цепепе

Потому что вы идиот и не понимаете, что если программа пишется на C++, то приемы из Lisp-а к ней не применимы. И, следовательно, ваш вопрос нужно переформулировать по другому: почему софт все еще массово разрабатывается на C++, а не на вашем любимом Lisp-е?

И ответ вполне очевиден: потому что Lisp, по большому счету, никому не всрался. Причем уже очень и очень давно. Тем более в областях, где между собой толкаются C, C++, Ada, Eiffel, Modula и недавно подключившиеся Go с Rust-ом.

Это, кстати, и причина того, что на жизнь программированием на Lisp-е вы заработать себе не можете. Отсюда и необходимость приходить и пытаться троллить C++ников.

Так это макры - это добро :-) Хватит ли ума понять? :-)

Докажите это на вашей же задаче. В C++.

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

не веришь мне - спроси у старого

кто все эти люди?

Сформулируй критерий оценки «лучше».

Раз вы этого не делаете и глаза у вас красные от C++, то, очевидно, что нельзя. Так почему?

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

Потому что вы идиот и не понимаете, что если программа пишется на C++, то приемы из Lisp-а к ней не применимы.

Опять же логика из оперы «ветер дует, т.к. деревья ветками машут» :-) Приёмы и идиомы - суть зависимости языка программирования, а не наоборот :-) Т.е. то, что в цепепе нельзя сравнить строчку в компайл-тайме, а в Лиспе - можно, - это проблема цепепе как языка, а не приёмов :-) (С помощью которых там принято вызывать статические функции косвенно через аргумент шаблона :-)

И, следовательно, ваш вопрос нужно переформулировать по другому: почему софт все еще массово разрабатывается на C++, а не на вашем любимом Lisp-е?

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

И ответ вполне очевиден: потому что Lisp, по большому счету, никому не всрался. Причем уже очень и очень давно.

Но почему? :-)

Это, кстати, и причина того, что на жизнь программированием на Lisp-е вы заработать себе не можете. Отсюда и необходимость приходить и пытаться троллить C++ников.

Опять демонстрация фэйла логического анализа :-)

Докажите это на вашей же задаче. В C++.

Да легко :-) Когда надо с помощью using ввести в область видимости наследника имена предка - конструкторы и статические члены - в сотне мест - короче завернуть эти using в макру и использовать в сотне наследников, чем вручную, получая «неимоверное удовольствие», писать эти 4-5 using в каждом классе-наследнике :-)

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

Вы темой не ошиблись? Здесь люди обсуждали разницу в уровне поддержки ООП в Java и C++. А вы хотите, чтобы вам объяснили, почему Lisp давным-давно не нужен.

Да легко

Код покажите. Чтобы функция принимала на вход функцию, но в компайл-тайм проверялось, что это либо функция A::f или B::g. Ваше условие. Покажите ваше решение в C++ на макросах.

Код покажите. Чтобы функция принимала на вход функцию, но в компайл-тайм проверялось, что это либо функция A::f или B::g. Ваше условие. Покажите ваше решение в C++ на макросах.

Бугага :-) Я ему про Фому, а он мне про Ярёму :-) Про использование макросов в цепепе уже было объяснение - уменьшить бойлерплэйт в объявлениях классов наследников, которых много :-) Задачу про A::f и B::g я решал в своём коде километровыми специализациями шаблонов структур со статическими членами :-) Вот так:

enum class Path_component_type { base, dir };

template<Path_component_type T>
struct Parse_what;

template<>
struct Parse_what<Path_component_type::base> {
  static auto f(char *path) { return basename(path); }
};

template<>
struct Parse_what<Path_component_type::dir> {
  static auto f(char *path) { return dirname(path); }
};

template<Path_component_type Tp>
std::string path_component(const std::string& path)
{
  std::string result;
  auto pathstr = strdup(path.c_str());
  try {
    result = Parse_what<Tp>::f(pathstr);
  } catch (...) {
    free(pathstr);
    throw;
  }
  free(pathstr);
  return result;
}

inline
std::string path_basename(const std::string& path)
{
  return path_component<Path_component_type::base>(path);
}

inline
std::string path_dirname(const std::string& path)
{
  return path_component<Path_component_type::dir>(path);
}

Ну теперь понятно, почему у вас от C++ глаза красные: начиная от велосипедостроения на ровном месте и заканчивая неумением использовать RAII.

Ну теперь понятно, почему у вас от C++ глаза красные:

Конечно, язык потому что утомительный дюже :-)

начиная от велосипедостроения на ровном месте

Где тут велосипедостроение? :-) Нежелание использовать турбо-мега-мостра boost::filesystem для банального парсинга пути? :-) Зачем мне это говно, если есть функции стандартного POSIX.1-2001? :-)

и заканчивая неумением использовать RAII.

Бугага :-) Если бы я ещё на каждый такой чих создавал шаблоны классов вроде Path, то глаза были бы ещё красней :-) RAII :-) Бугага :-)

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

Меня всегда умиляли люди, считающие достоинством отсутствие фич.
Вы, часом, не поклонник Apple?

Значит ли это, что ООП есть в ассемблере

ООП есть в ассемблере уже очень давно, а точнее со времен появляения TASM: http://www.heiho.net/download/oo-asm.txt

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

Почему так нелестно? // Не читал, но собирался читать.

Где тут велосипедостроение?

Да, блин, на каждом шагу, мать вашу. Все тоже самое можно было сделать много проще. Например (код не компилировался, так что опечатки возможны):

template< typename F >
std::string process_path(const std::string & path, F f)
{
  std::vector< std::string::value_type > tmp;
  tmp.reserve(path.size()+1);
  tmp.insert(tmp.begin(), path.begin(), path.end());
  tmp.push_back('\0');
  return f(&tmp[0]);
}

inline std::string path_basename(const std::string& path)
{
  return process_path(path, basename);
}

inline std::string path_dirname(const std::string& path)
{
  return process_path(path, dirname);
}

И все! Никаких, блин, простыней с потоками сознания.

Бугага :-) Если бы я ещё на каждый такой чих создавал шаблоны классов вроде Path, то глаза были бы ещё красней :-) RAII :-) Бугага :-)

Идиот, прочтите, наконец, документацию по unique_ptr. Ваши пляски вокруг strdup-а и free легко заменяются на unique_ptr с кастомной функцией освобождения памяти. Что-то вроде:

std::unique_ptr<char, void(*)(char*)> tmp(strdup(path.c_str()), free);

Кстати говоря, возвращаемое значение strdup нужно контролировать. Иначе нарветесь на крах программы.

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

Если не сложно, зайдите ко мне в блог, я там как раз вчера и сегодня писал (ссылка в профиле). Но это сугубо мое субъективное мнение.

Я тоже. Так ООП вообще ущербная концепция, всё правильно.

ООП тут не причём. Я имел ввиду косяки самого Erlang и программистов на нём.

ООП — это не gen_server, это процессы и сообщения.

Почти все примеры «ООП на Erlang», которые я видел, основывались на gen_server. В любом случае, как же наследование, классы и прочая фигня?

И все! Никаких, блин, простыней с потоками сознания.

Мне нужно было обернуть лишь 2 функции - basename, dirname в цепепешный вариант :-) Мой шаблон имеет смысл только для этих 2-х ф-ий - отсюда и ограничение, которое было возложено на компилятор :-) В твоём же говнокоде в process_path можно передать любую ф-ю, а не только удовлетворяющую семантике basename/dirname :-) И это делает адепт цепепе, где по заявлениям его создателя «упор делается на технологию компиляции» :-) Браво :-)

Идиот, прочтите, наконец, документацию по unique_ptr. Ваши пляски вокруг strdup-а и free легко заменяются на unique_ptr с кастомной функцией освобождения памяти. Что-то вроде:

А я не хочу uniqu_ptr :-) Я хочу try/catch - это ведь стандартные конструкции языка :-) И если для тебя или ещё кого-то использование стандартных конструкций языка является чем-то плохим, не идиоматичным, как вы там любите говорить, то тогда такой язык ущербен - в нём много матерных слов - try/catch :-) Ч.т.д.

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

Субъективное мнение :-) А язык уродлив, это факт :-) Семантика особенно :-)

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

Нет, в этом он таки прав: C++ действительно уродлив из-за гигантского чемодана говна, которое тянется с 80х.

В очередной раз забыл, что беседую с идиотом.

Обилия говна в C++ я не отрицаю. Но в контексте разговора проблемы две:

1. Заменять его в тех нишах, где он остается, особенно-то и нечем.

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

Обилия говна в C++ я не отрицаю.

Ну ещё бы, ведь глядя на твой, так сказать, код

template< typename F >
std::string process_path(const std::string & path, F f)
{
  std::vector< std::string::value_type > tmp;
  tmp.reserve(path.size()+1);
  tmp.insert(tmp.begin(), path.begin(), path.end());
  tmp.push_back('\0');
  return f(&tmp[0]);
}

Т.е., здравствуй Си :-)

Шиза косит? Это же вам потребовалось задействовать C-шные функции для C++ных строк. Отсюда и необходимость в промежуточной C-шной строке. Для чего нужен буфер, с нулевым символом в конце.

Использование vector дает этот самый буфер. Причем с RAII сразу. Причем с исключением в случае нехватки памяти.

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

Ну и если смущает, что process_path может дернуть кто угодно и передать что угодно, то решается это несколькими способами. Самый простой — определить process_path внутри пространства имен impl или details и объявить это пространство имен деталями реализации. Соответственно, если кто-то вызвал process_path, тот сам себе буратино. Если же хочется хардкорного контроля, то опять же без трехэтажных шаблонов:

class path_processor {
  friend std::string path_basename(const std::string &);
  friend std::string path_dirname(const std::string &);

  template<typename F>
  static std::string process(const std::string &, F f) {...}
};

ООП, чем ООЯ.

ООЧЁ?

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

всё так

ООЯ — объектно-ориентированный язык(и).

1. Заменять его в тех нишах, где он остается, особенно-то и нечем.

Каких?

Сложный высокопроизводительный софт, как правило инфраструктурный, но не обязательно: GCC, clang/LLVM, HHVM, MSSQL, MySQL, MongoDB, RethinkDB, Couchbase, Chrome, Firefox, IE, Opera, Lightroom/Photoshop и т.д, и т.п.

Firefox

О да, C++ настолько хорош, что Mozilla изобрели новый язык чтобы его заменить. К тому же, о производительности Chrome и Firefox ходят легенды.

Задачу про A::f и B::g я решал в своём коде километровыми специализациями шаблонов структур со статическими членами :-) Вот так

#include <iostream>
#include <libgen.h>
using namespace std;

string path_basename(const string& path) {
  return basename( (char*) string( path ).data() );
}

string path_dirname(const string& path) {
  return dirname( (char*) string( path ).data() );
}


int main()
{
  const char* s = "/please/dont/use/c++";  
    
  cout << path_dirname( s ) << endl;
  cout << path_basename( s ) << endl;
}

Чтобы функция принимала на вход функцию, но в компайл-тайм проверялось, что это либо функция A::f или B::g. Ваше условие.

Пусть будет так: функция на вход принимает указатель на интерфейс I. И надо чтобы в фунции в компайл-тайм проверялось, что реализация приходит только из класса 'class A : public I' или 'class B : public I'. Теперь внимание вопрос: какой в этом смысл?

Все тоже самое можно было сделать много проще.
И все! Никаких, блин, простыней с потоками сознания.

Ну почему, почему люди не любят KISS :( Какие исключения, какие шаблоны, какие unique_ptr, какие вектора, - задача, блин, в одну строку.

Хотя это наверное еще надо радоваться, что вслед за лиспером и полусишником не пришел джавер и не прикрутил к этому всему IoC. Тогда бы точно был бы финиш.

Нормальная книга. Зря ты погнал.

Тебе не понравилось, что автор использует clojure или elixir в своих примерах? Но надо же на каком-то языке, пусть даже псевдо-коде, иллюстрировать идеи. Считай clojure за тот-же псевдо-код. А то, что clojure даже есть нужные библиотеки, это только плюс.

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

Количество говнокода в этой теме поражает.

template< typename F >
std::string process_path(const std::string & path, F f)
{
  std::vector< std::string::value_type > tmp;
  tmp.reserve(path.size()+1);
  tmp.insert(tmp.begin(), path.begin(), path.end());
  tmp.push_back('\0');
  return f(&tmp[0]);
}

std::string process_path(const std::string & path, F f)
{
  std::string tmp = path;
  return f(tmp.data());
}

В любом случае, как же наследование, классы и прочая фигня?

Это один из вариантов реализации, возможно, самый популярный, но далеко не единственный. См., например, JavaScript.

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

В Erlang есть ООП?

Да какая разница, что там есть. Он просто принадлежит к тройке божественных языков: Lisp, Haskel, Erlang.

(char*) string( path ).data()

Метод basic_string::data() возвращает константный указатель, а модификация значения по этому указателю — это UB. тыц