Поломана совместимость с С в С++11?

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

Он его не определяет, а ограничивает. На мой взгляд это попадает под понятие «иметь отношение».

Поэтому я добавил «вроде».

Ну так и я написал, что отношение малое. ;-)

Java - говно. Scala - хороша, да. Да прикладного софта - самое то.

Кстати, есть опыт ее использования на андроиде? Как оно?

Ну так и я написал, что отношение малое.

Если я всё-таки правильно помню, то дженерик из шарпа похож на полиморфную функцию из хаскеля.

Для ф-ции

foo a b = a+b

В шарпе невозможно произвести вывода типов таким образом (ибо там есть функции-синонимы), поэтому приходится constraint'ы приходится указывать явно. Но итоговая-то сигнатура будет выглядеть одинаково.

хаскель сам выведет тип как foo :: (Num a) => a -> a -> a. Иначе этот код смысла не имеет.

Но ведь не все полиморфные функции требуют ограничение тайпклассом. Та же map например.

Тайпклассы все же, ИМХО, больше нужны для ad-hoc полиморфизма (перегрузки), что в шарпе делается наследованием. Т.е. хаскелл и шарп тут как бы противоположны: в хаскелле параметрический полиморфизм (функций и типов) «первичен», а специальный (тайпклассы) «прикручен сбоку», в шарпе наоборот — специальный (наследование и перегрузка методов) «первичен», а параметрический (дженерики) «прикручен сбоку».

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

Ну это все несколько условно и грубо, наверное.

Пояснение (за корректность шарпового кода не ручаюсь):

class Foo a where
   foo :: a -> a
 
bar a = foo a -- Автоматически вывели тип: bar :: Foo a => a -> a

abstract class IFoo
{
  public abstract IFoo foo(IFoo );
}
class Bar<T> where T:Foo
{
  T bar(T a) // в переводе на haskell: (IFoo T) => T -> T -> T
  {
    return IFoo.foo(a); 
  }
}

Что-то это немного не то. Повтори этот код на шарпе.

Вот на шаблонах мне товарищ подсказал.

Java и Scala божественны. Советую

Но не их поклонники: http://ru-scala.livejournal.com/34683.html

Not in scope: `a'

Если я правильно понял задумку, то instance меняем на наследование от IFoo и всё.

На шаблонах все таки имитация. Концепты нужны.

На шаблонах все таки имитация. Концепты нужны.

С этим никто не спорит, но пока у нас только шаблоны vs дженерики. =)

Да, опечатался.

Всмысле так:

abstract class IFoo
{
  public abstract IFoo foo(IFoo);
}

class IFoo_int : IFoo {
  private int content = 0;
  public IFoo_int(int content) {
    this.content = content;
  }
  public IFoo foo(IFoo other) {
    // а здесь что?
  }
}

class Bar<T> where T:IFoo
{
  T bar(T a) // в переводе на haskell: (IFoo T) => T -> T -> T
  {
    return IFoo.foo(a); 
  }
}

шаблоны vs дженерики

Я-то рассуждал о параметрическом полипорфизме + typeclass constraints vs. дженерики.

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

Issue уже открыт?

Я-то рассуждал о параметрическом полипорфизме + typeclass constraints vs. дженерики.

Ты говорил, что тайпклассы ближе к дженерикам, чем к шаблонам. А на самом деле не так уж и ближе.

Всмысле так: ... ?

Вообще на самом деле вот так. И никаких дженериков.

Например: http://ideone.com/s3FhtG

А на самом деле не так уж и ближе.

Так, ещё раз: почему? Я же указал на разницу между шаблонами и дженериками: проверка типов происходит на разных этапах, и в этом смысле дженерики как раз ближе.

Так, ещё раз: почему?

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

Например: http://ideone.com/s3FhtG

Во-первых, у тебя foo — функция двух аргументов (this и a), а не одного, как в хаскелльном варианте.

Во-вторых, она делает не то же, что хаскелльная.

В-третьих, и где же дженерики? =)

Я же указал на разницу между шаблонами и дженериками: проверка типов происходит на разных этапах, и в этом смысле дженерики как раз ближе.

На практике это не имеет значения и на близость никак не сказывается.

С++ может уйти в рекурсию инстанцирования шаблонов и компилятор свалится =) По этой причине никак там зависимых типов полноценных не сделать(хотя в простых случаях можно сымитировать.

Например?

Пример цикла? Или пример простых случаев зависимого типа? Самый простой случай:

template<unsigned N>
class A : public A<N-1> {
// тут что-нибудь полезное
};
// специализация для 0
template<>
class A<0> { // Останавливаем рекурсию(не наследуемся)
// ...
};

Так вот, если мы будем идти снизу в верх(т.е. будем брать некоторое число в качестве параметра и уменьшать его - все будет ок. А вот вверх(т.е. N+1) мы уже никогда не поднимемся - уйдем в постоянную попытку инстанцировать шаблон.

Ну это понятно. А зачем нужен N+1? Понятно что единственное что можно сделать на <your favorite language> типа хаскель, лисп, you name it, это факториал. Почему это проблема шаблонов плюсов?

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

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

С++ это все унаследовал

Общие сложности по обе стороны неравенства я сократил;)

по простой причине - она включает по факту почти всю документацию по С

Меньшая часть. По сравнению с остальным - копейки.

удобно гордится простотой ЯП

Да, это подход С. В этом его сила. Остальное - над ним.

Но ты пока так и не объяснил, зачем тебе С, «когда есть плюсы».

Зачем тебе яблоки, когда есть колбаса.

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

Сказочно. А ничего, что без gobject vala был бы невозможен?

ПРИДЕТСЯ вызывать руками некий unref

Так ведь и в плюсах нет автоматического полноценного сборщика мусора. Именно что там «полу». В плюсах все «полу». Полуавтоматическая сборка. Полу-ОО.

Тут где-то был эпичный пример. Даны два «вектора», которые заполняются динамически(!), путь и параллельно(но размер не известен на этапе компиляции. Нужно на этапе компиляции вызова функции гарантировать, что векторы будут одной и той же длины(т.е. компилятор не даст вызвать функцию для двух «векторов» разной длины). С этим справляются даже дженерики java(через «рекурсивные» дженерики), а плюсы - нет... А это может быть полезно для дополнительных контрактов в коде.

ничем не подкрепленное заявление о программистах на С++.

Честно скажу - про 2013 год не знаю. В 1990х было именно так. Подкреплялось относительной сложностью языков и сферой применения.

сишники, не переходящие на С++ как раз плохие программисты

Торвальдс смотрит с удивлением. Программисты иксов и пр. и пр. офигевают.

по сравнению с С++ ООП.

Ну и что? А С++ ООП - полное фуфло по сравнению со смоллтолком и даже жабкой. Недо-ООП.

Некорректное сравнение. С++ в той же нише, но богаче возможностями. И еще раз повторяю, тебя никто за уши не тянет использовать то, что тебе не нравится. С++ лучше С, даже если ты будешь писать без ООП, шаблонов и исключений. Пространство имен, перегрузка функций, RAII, пользовательские типы неотличимые от встроенных, стандартная библиотека, лямбды. И, опять же, ничего из этого не обязательно к использованию :)

С не может дать ничего, что не сможет дать С++. Какой в нем смысл?

ПРИДЕТСЯ вызывать руками некий unref

Так ведь и в плюсах нет автоматического полноценного сборщика мусора. Именно что там «полу»

Значит, в Си много меньше «полу».

Полу-ОО.

Полусмешно.

Торвальдс фанатик и чмо(как человек). Его мнение меня интересует только с точки зрения ОС. Ну и систем контроля версий. В языках программирования он явно ничего не понимает. С он использует потому, что не осилил С++ в нужное время, сейчас ему это не надо.

И да, ты так и не показал, почему С++ ООП - полное фуфло. Вот давай в сравнении с той же жабкой. Хотя это не имеет к разговору о С никакого отношения и ты видимо решил делать вид, что не понимаешь, что ООП С++ фактически бесплатно для сишников. Более того, оно даже быстрее указателей на функции, особенно с O3 и LTO. Но давай расскажи мне, как в Java, где даже нормального множественного наследования нет(все через убожество в виде интерфейсов, придуманных для обезъянок, не способных осилить множественное наследование). Да, ОО в С++ не идеально. Но мне интересны именно твои доводы, т.к. пока мне кажется, что ты не знаешь ОО в С++. Хотя оно простое(особенно для сишника).

И да. Я не фанат ОО в С++. Но я не вижу крутости в smalltalk и жалею о потраченном на его изучения времени. Для меня практически идеалом ОО языка(кроме синтаксиса) является Eiffel.

Не так быстро, но часто намного приятнее.

не часто, т.к. почти все что есть в С, есть и в С++, и ты сам волен выбирать, что тебе приятнее

Не приходится воевать с жестко заданной ОО моделью, можно придумывать свою.

а зачем с ней воевать - ее можно расширять, как минимум теми же костылями, что и в С, а вот в С никаким боком не прикрутишь RAII, перегрузку операторов, implicit type conversion для классов и пр.

Да, это подход С. В этом его сила

нет в этом силы, это как если у Java убрать стандартную библиотеку и сказать, что Java стала еще проще и лучше

И еще раз повторяю, тебя никто за уши не тянет использовать то, что тебе не нравится

Беда в том, что найдутся программисты, в моем же проекте, которые начнут использовать. С++ - язык, хороший код на котором требует СТРОЖАЙШЕЙ ПАРАНОИДАЛЬНОЙ дисциплины. Причем от всех участников проекта. Или начнется СИЛЬНАЯ беда.

В С проще тем, что дисциплинирует сам язык. Он просто не дает возможностей для злоупотреблений.

С не может дать ничего, что не сможет дать С++. Какой в нем смысл?

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

Значит, в Си много меньше «полу».

В C просто нет ОО. И в этом его сила. ОО ручками. На вкус программиста.

В C просто нет ОО. И в этом его сила.

А ты хорошо читал Оруэлла. Проникся.

С он использует потому, что не осилил С++ в нужное время, сейчас ему это не надо.

Сильно... А может, просто понять - ОСИЛИТЬ С++, чтобы стать реальным гуру - это куча усилий. Которых С++ просто, может, не стоит?

почему С++ ООП - полное фуфло

Значит так. У меня есть некий совершенно неизвестный объект (указатель). Я хочу (в рантайме) вывести название его класса. Список доступных методов с типами аргументов, типом возвращаемого значения и эксепшнами. Далее, я хочу взять какой-то из этих методов и вызвать его с заданным набором параметров.

В жабке это все без проблем делается через рефлексию. В плюсах как? Задачку решить, пожалуйста, два раза - с включенным RTTI (ЕМНИП даже с RTTI она не решается - но могу ошибаться). И с выключенным - я же могу захотеть совместимости с С!

С никаким боком не прикрутишь RAII, перегрузку операторов, implicit type conversion для классов и пр.

КАКОЕ СЧАСТЬЕ, что этого всего нет в С!!!! Даже в жабке нет перегрузки операторов.

Я уверен, что ты не участвовал ни в одном профессиональном С++ проекте. Никакой СТРОЖАЙШЕЙ ПАРАНОИДАЛЬНОЙ дисциплины. Такая дисциплина нужна разве что бывшим обезъянкам... Обычная инженерная присутствует. Если ты выбрал С++ для решения задачи(вот в моей нынешней команды мы используем разные языки), значит знаешь, что тебе нужно. Си же брать просто НЕ ИМЕЕТ СМЫСЛА. Он ничего не дает. Вообще.

Приводи примеры, для чего мне нужна дисциплина.

Обезъянки мне не нужны в проекте на любом языке. Талантливые джуниуры - да. Но для них есть свои задачи.

КАКОЕ СЧАСТЬЕ, что этого всего нет в С!!!! Даже в жабке нет перегрузки операторов.

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

int main()
{
   mpz_class a(4), b("-20"), c(6);
   mpz_class x1 = (-b+sqrt(b*b-4*a*c))/(2*a);
   mpz_class x2 = (-b-sqrt(b*b-4*a*c))/(2*a);
 
   cout << "x1: " << x1 << endl;
   cout << "x2: " << x2 << endl;
 
   return 0;
}

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

Тут где-то был эпичный пример.

Можно ссылку?

размер не известен на этапе компиляции
С этим справляются даже дженерики java

Как справляются?

гарантировать, что векторы будут одной и той же длины

Поставить ассерт религия не позволяет?

У меня есть некий совершенно неизвестный объект
я хочу взять какой-то из этих методов
я же могу захотеть совместимости с С!

у вас весьма специфические задачи, не удивительно, что плюсы вам не подходят

гарантировать, что векторы будут одной и той же длины

Поставить ассерт религия не позволяет?

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

А какое отношение к ООП имеет рефлексия? Еще раз повторяю - это один из видов метапрограммирования. Задачи метапрограммирования(не ООП) в С++ решаются на этапе компиляции. Если тебе нужен подобный рантайм, то С/С++ - плохой выбор. Через рефлексию ты и инкапсуляцию обойти можешь. Какое уж тут ООП. Метапрограммирование чистой воды.

Давай ближе к ООП. Можешь начать с его определения. Ну или просто давай об инкапсуляции, наследовании, полиморфизме, абстракции и т.д.

Я уверен, что ты не участвовал ни в одном профессиональном С++ проекте

Участвовал, в 90х. Наелся. Сам понаваял чайниковского кода, чему-то научился (сейчас, конечно, квалификация в основном потеряна). Видел кучу другого кода самого разного качества. Мощь плюсов направлена против тех, кто его изучает, пока они не станут высококлассными. И высококлассными делает их в т.ч параноидальная дисциплина в НЕИСПОЛЬЗОВАНИИ наворотов, которые можно бесконтрольно использовать во вред проекту.

Обезъянки мне не нужны в проекте на любом языке.

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

Ты точно не писал на С++. Ибо ты даже не понимаешь, что ешь кактус. blub paradox во всей красе.

ваше счастье пропадет, если вам придется написать аналогичный код на С

Я буду использовать ЯВНЫЕ вызовы функций.

https://schneide.wordpress.com/2009/08/03/evil-operator-overloading-of-the-day/

(и куча подобных историй в гугле)

Всегда можно про подобные тексты говорить «не осилил». Так в этом и проблема - по-настоящему ОСИЛИТЬ плюсы, с их ОХРЕНЕННОЙ мощью - это куча усилий, которые достойны лучшего применения.

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

Повторяю - я писал. И наелся.

у вас весьма специфические задачи

Нет, просто ОО, которое ОО только во время компиляции, а не в рантайме - это полуОО. Я бы даже сказал о_О.