Неосилятор ищет язык.

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

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

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

Как это не могу, если я посчитал?

И ты это дерзко преподносишь как фичу.

Фича заключается в том, что шарп не позволяет писать код, который заведомо неверен. Например, sin(x), где х имеет тип T, для которого sin не определен. Те проблемы, о которых ты говоришь - это издержки реализации констрейнтов (нельзя потребовать наличия конкретного конструктора) и к самим генерикам _никакого_ отношения не имеют. почему сделали именно так - вопрос. Видимо, в микрософте решили, что с архитектурной точки зрения так лучше. Почему не сделали для числовых типов интерфейсы навроде IComparable для арифметических операций - тоже вопрос. Но, повторяю, к самим генерикам это не имеет отношения. Однако, на безрыбье - и рак рыба. лучше хреново реализованная ограниченная квантификация, чем никакой, как в плюсах.

На, открывай для себя новые горизонты:

То есть твой корень не соответствует математическому определению корня? Молодец, так держать.

и начал путанно оправдываться, что математические функции ничего кроме double возвратить в принципе не могут.

При чем тут оправдания? Они действительно не могут. Именно потому что не могут - для этих ф-й так сделать и нельзя (это был бы некорректный код, опять же, как можно вернуть int если ф-я умеет возвращать только double?). Сделай свой собственный sqrt<T> с блекджеком и шлюхами, поставь его на место Math.Sqrt и все заработает. Почему, опять-таки, в микрософте решили не делать sqrt<T>? Решили, что это не нужно. И практика подтвердила - действительно, не нужно.

Ты про темплейты? Я много чего на темлейтах показывал как сделать - см. выше по треду.

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

Да, интерфейсы, фабрики и прочая хрень - это все лишний бойлерплейт.

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

>Смысл тестов - сравнить предоставленные программы по ряду характеристик. Качество кода - среди этих характеристик (по крайней мере в тестах на шутауте).

И как ты качество кода меряешь?

Мне-то зачем писать? Это же ты утверждаешь, что на джаве можно решить эту задачу не хуже, чем на шарпе. С тебя и пруфы.

Не надо с больной головы на здоровую. Я тебе предложил на скорость выполнения посмотреть и спросил, отчего шарп так сливает. Ты сказал, потому что «джава - это 10% от шарпа». Я дал ссылку, где видно, что ничего такого инновационного в шарпе не используется. Тут ты съехал на качество кода и у тебя родилась фантазия, что надо на джаве написать такую же тормозную программу, как на шарпе. Зачем вообще это нужно и что это докажет, кроме тебя никто не знает. С тебя и пруфы.

> ничего такого инновационного в шарпе не используется

Тогда почему решение на шарпе вдвое короче? И почему на джаве нельзя решить задачу так же компактно?

надо на джаве написать такую же тормозную программу, как на шарпе.

Это докажет, что ничего такого инновационного в шарпе не используется и джаву можно сравнивать с шарпом (по крайней мере в рамках этой задачи).

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

Как же трудно с тобой, а. Пока ты не знаешь типа, ты не можешь сказать, определена для него функция синус или нет, и, соответственно, не можешь делать выводы о корректности кода (вернее, ты можешь, но мы патологии сейчас не рассматриваем). В шарпе ты обязан указать тип сразу и это всю параметризацию сводит в ноль. Ты не можешь вызвать Method() у объекта T, пока не укажешь, что он принадлежит интерфейсу IInterface. Но если ты уже указал тип, то что мешает T заменить на IInterface? В большинстве случаев дженерики превращаются просто в синтаксический сахар и средство оптимизации для значимых типов. В плюсах параметризация честная, но, как выясняется, не всем доступная. Именно в момент подстановки типа, когда становится известно, определен ли для него синус, компилятор проверяет корректность кода. Компилятор умнее тебя.

Как это не могу, если я посчитал?

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

Фича заключается в том, что шарп не позволяет писать код, который заведомо неверен. Например, sin(x), где х имеет тип T, для которого sin не определен.

Приведенный код на плюсах не является «заведомо неверным». То, что тебе он кажется таковым - это проблемы твоего знания/незнания плюсов.

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

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

Почему не сделали для числовых типов интерфейсы навроде IComparable для арифметических операций - тоже вопрос.

Да. Плохо, плохо, плохо. Но не отчаиваемся, ждем новых версий.

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

Тебе, наверное, да, а вообще, спасибо - нет, в таком виде квантификация не нужна.

То есть твой корень не соответствует математическому определению корня?

Шарп => Необратимое повреждение сознания => «Все, что существует вне класса Math - еретично и не нужно». Не буду даже объяснять зачем и где нужны вычисления с фиксированной точкой. Воинствующее невежество не следует поощрять.

>При чем тут оправдания? Они действительно не могут. Именно потому что не могут - для этих ф-й так сделать и нельзя (это был бы некорректный код, опять же, как можно вернуть int если ф-я умеет возвращать только double?).

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

Сделай свой собственный sqrt<T> с блекджеком и шлюхами, поставь его на место Math.Sqrt и все заработает.

Ничего не заработает и странно, что ты сам этого не понимаешь. В том-то и дело, что ты не сможешь написать sqrt<T>, который был бы разный для разных типов T (нет в шарпе понятия специализации дженериков). И просто три разные версии sqrt тебя не спасут - ты не сможешь их дернуть из «T Length()» (не хочется расстраивать, но это из-за отсутствия параметрического полиморфизма в шарпе). Или, может быть, ты до сих пор не понял, что нужны разные версии, и надеешься ворохом интерфейсов конвертнуть все в double, а потом обратно.

Почему, опять-таки, в микрософте решили не делать sqrt<T>? Решили, что это не нужно. И практика подтвердила - действительно, не нужно.

Решили, что это невозможно. И практика подтвердила - действительно невозможно.

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

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

я тебя просил написать решение задачи с шутаута на жабе - ты не сделал.

Это безумие, на джаве уже все написано.

Я открою тайну (для паттерноебов вроде тебя это действительно тайна) - у каждого инструмента есть своя область применения.

Правильно. Поэтому надо не просто знать об их существовании, но и уметь применять. Ты пока не умеешь.

>Тогда почему решение на шарпе вдвое короче? И почему на джаве нельзя решить задачу так же компактно?

Наверное, потому что решение на шарпе не в 2 раза короче и лишние 186 байт стоят 2-кратного превосходства по скорости? Видимо, эти джаверы ничего не понимаю в качестве кода.

Это докажет, что ничего такого инновационного в шарпе не используется и джаву можно сравнивать с шарпом (по крайней мере в рамках этой задачи).

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

> Наверное, потому что решение на шарпе не в 2 раза короче

Не в два. Более, чем в два.

186 байт стоят 2-кратного превосходства по скорости?

конечно, стоит. Машинное время вообще всегда стоит дешевле человеческого.

Видимо, эти джаверы ничего не понимаю в качестве кода.

Видимо.

Если хочется и считаешь, что это что-то докажет - пиши.

Мне-то зачем? Это же _ты_ хочешь доказать, что шарп можно сравнивать с жабой. Пока что у нас есть факт - шарп более чем вдвое выразителен, чем жаба.

>Не в два. Более, чем в два.

Более чем в 4.2

конечно, стоит. Машинное время вообще всегда стоит дешевле человеческого.

Вот из-за такого отношения к ресурсам машин пользователя, программы на шарпе из дистрибутивов и выбрасывают. Одна ниша осталась - быстрые гуишные поделки под офтопик. Да и то... (man evernote).

Мне-то зачем? Это же _ты_ хочешь доказать, что шарп можно сравнивать с жабой.

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

Видимо.

Покажешь им, как надо?

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

Гарольд и Кумар уходят в отрыв.

> Пока ты не знаешь типа, ты не можешь сказать, определена для него функция синус или нет, и, соответственно, не можешь делать выводы о корректности кода

Конечно могу - если у нас есть некоторая переменная типа T то попытка применить к ней любую функцию, которая не определена для какого-нибудь типа, сразу некорректна. Ты никак не поймешь - тип в шаблоне/генерике известен (просто этот тип полиморфный) и мы свободно может выносить утверждения о том, определена ли ф-я для этого типа или нет.

Но если ты уже указал тип, то что мешает T заменить на IInterface?

Мешает то, что в темплейте/генерике нигде не указано, что этот тип реализует IInterface. Это произвольный полиморфный тип. А операции IInterface неприменимы для произвольного полиморфного типа - они применимы только для полиморфного типа, реализующего IInterface, что и позволяют указать констрейнты.

Именно в момент подстановки типа, когда становится известно, определен ли для него синус, компилятор проверяет корректность кода.

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

В плюсах параметризация честная

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

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

Читать научись - я решил требуемую задачу (посчитать длину). «Невозможно» сделать параметризованное возвращаемое значение - потому что оно _по факту_ не параметризованное. Функция возвращает double и ничего кроме double не может вернуть. Дело не в генериках, а в мат. функции, которая возвращает double. Используй ф-ю, которая возвращает полиморфный тип - и будет как ты хочешь.

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

Ну перед плюсами тут пара преимуществ - во-первых, в шарпе (и в частности в генериках) предусмотрено гораздо больше, чем в плюсах, так что ситуация, когда приходится лепить костыли для work around'a, встречаются гораздо реже (+ обычно в шарпе можно сделать work around для того, что есть в плюсах искаробки, а вот в другую сторону - часто нет, то есть то, что может шарп, в плюсах принципиально нереализуемо). Во-вторых - если какой-то фичи нет, то действительно можно надеяться, что ее включат в спецификацию. Это вполне оправданная надежда. А вот в случае с++ - не включат и ждать смысла нет.

Тебе, наверное, да, а вообще, спасибо - нет

Да не только мне, а всем, кто использует шарп. Так что тебе, может, и нет, а вообще - да.

Шарп => Необратимое повреждение сознания => «Все, что существует вне класса Math - еретично и не нужно».

Математическое определение корня, идиот. Ты в школу ходил? При чем тут класс math? Корень из 5 должен быть либо неопределен либо дробью. Целым он быть не может никак. По крайней мере в этой реальности, что там в реальности плюсоблядков происходит - не знаю.

> В том-то и дело, что ты не сможешь написать sqrt<T>, который был бы разный для разных типов T (нет в шарпе понятия специализации дженериков).

А тут и не нужна специализция. Сделай полиморфный sqrt без специализации.

Решили, что это невозможно.

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

Ложь, все делал

Лолчто? На счет констрейнтов ты ответил «не нада», с передачей аргументов - поменял условия задачи, продемонстрировать одинаковыые результаты компиляции ты не мог по-просту потому, что они разные. Ты совсем уж запизделся.

(или вижуал бейсик - они примерно равномощны)

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

Это безумие, на джаве уже все написано.

Без пруфов ты - нутыпонелда?

Правильно. Поэтому надо не просто знать об их существовании, но и уметь применять.

Вот когда научишься - тогда и будешь советовать фабрики делать. А пока - помолчи да послушай тех людей, которые уже давно научились. Может, умнее станешь.

> Более чем в 4.2

шарп - 564 жаба - 1282. 1282/564 = 2.27... Менее чем в 4.2. но более чем в 2, как я и говорил.

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

Ох, лол, бида-бида.

Например, по ссылке, которую я изначально привел, код по размеру примерно одинаков, а по производительности шарп сливает в 2 раза.

Вот ссылки: http://shootout.alioth.debian.org/u32/benchmark.php?test=fannkuchredux&lang=java http://shootout.alioth.debian.org/u32/benchmark.php?test=fannkuchredux&lang=c... Считать умеешь? или цифр не знаешь?

>Мешает то, что в темплейте/генерике нигде не указано, что этот тип реализует IInterface. Это произвольный полиморфный тип. А операции IInterface неприменимы для произвольного полиморфного типа - они применимы только для полиморфного типа, реализующего IInterface, что и позволяют указать констрейнты.

Блеать, я о констрейнтах и говорил. Без констрейнтов вообще никакой разницы, как ты не понимаешь. А с констрейнтами, если ты указал, что T:IInterface, то что мешает вообще обойтись без T и использовать IInterface? Поэтому, во многих случаях, наличие констрейнтов просто уничтожает параметризацию.

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

Он не может быть заведомо некорректным, потому что до инстанцирования неизвестно, реализует T синус или нет (а если знаем, что T должен принадлежать какому-то типу, как в констрейнтах, то надо этот тип и использовать). А после инстанцирования компилятор никакого некорректного кода не пропускает. Кто-то бессовестно пошутил над тобой.

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

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

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

Целый абзац «непринципиальных дополнительных возможностей», которые в принципе можно было бы запилить в шарп и тогда можно будет длину на нем посчитать. Ты такой смешной (только не пиши упорно, что посчитал, брось ты этот автотренинг).

«Невозможно» сделать параметризованное возвращаемое значение - потому что оно _по факту_ не параметризованное. Функция возвращает double и ничего кроме double не может вернуть.

Да, все характеристики и координаты объектов в целых числах, например, кроме длины. Длина, внезапно, - может быть только double. Ой, дураааак.

Дело не в генериках, а в мат. функции, которая возвращает double. Используй ф-ю, которая возвращает полиморфный тип - и будет как ты хочешь

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

Ну перед плюсами тут пара преимуществ - во-первых, в шарпе (и в частности в генериках) предусмотрено гораздо больше, чем в плюсах, так что ситуация, когда приходится лепить костыли для work around'a, встречаются гораздо реже (+ обычно в шарпе можно сделать work around для того, что есть в плюсах искаробки, а вот в другую сторону - часто нет, то есть то, что может шарп, в плюсах принципиально нереализуемо).

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

Да не только мне, а всем, кто использует шарп.

«Да не только мне, а всем, кто использует мозгового слизня». fixed.

Математическое определение корня, идиот. Ты в школу ходил? При чем тут класс math? Корень из 5 должен быть либо неопределен либо дробью. Целым он быть не может никак. По крайней мере в этой реальности, что там в реальности плюсоблядков происходит - не знаю.

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

>А тут и не нужна специализция. Сделай полиморфный sqrt без специализации.

Возьми и сделай. Попробуй хоть изредка к себе применять свои советы.

Потому что это только в плюсоебской реальности бывает целый корень из пяти.

Зайди на википедию, долбо*б: http://en.wikipedia.org/wiki/Integer_square_root

Хоть оттуда узнавай о жизни, если приходится в песочнице жить.

Лолчто? На счет констрейнтов ты ответил «не нада», с передачей аргументов - поменял условия задачи, продемонстрировать одинаковыые результаты компиляции ты не мог по-просту потому, что они разные. Ты совсем уж запизделся.

С констрейнтами я привел код ( http://www.linux.org.ru/jump-message.jsp?msgid=6008391&cid=6026509 ). С передачей аргументов тоже ( http://www.linux.org.ru/jump-message.jsp?msgid=6008391&cid=6032069 ). Все остальное - это твои личные обиды на жизнь и C++, которые должен комментировать твой личный психоаналитик.

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

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

Без пруфов ты - нутыпонелда?

Ты до сих пор не был на шутауте, но все рассуждаешь на тему тестов? Нутыпонялда.

Вот когда научишься - тогда и будешь советовать фабрики делать. А пока - помолчи да послушай тех людей, которые уже давно научились. Может, умнее станешь.

И это говорит человек, который советовал сделать конструктор без параметров у иммутабельного объекта и создавать его дополнительным вызовом Initialize? Это, что ли, умнее? Напиши книгу и консультируй людей, архитектор ты наш.

>Ох, лол, бида-бида.

Не расстраиваешься по поводу линукса, потому что надеешься в офтопике выжить?

Считать умеешь? или цифр не знаешь?

Правильнее было бы сравнить тут: http://shootout.alioth.debian.org/u64q/program.php?test=fannkuchredux&lang=cs... и тут: http://shootout.alioth.debian.org/u64q/program.php?test=fannkuchredux&lang=cs... потому что в джаве изначально масштабируемый код написан.

1096 и 1282 байта соответственно, что дает выигрыш в исходном коде в целых 1.16970802 раза и просад по производительности в 2 раза. Апплодисменты.

Поскольку на шарпе пришлось писать отдельную версию для одного ядра, возникает подозрение, что масштабируемое приложение на нем написать непросто. А может здесь и нет никакого рационального объяснения. Это же шарп.

> Без констрейнтов вообще никакой разницы, как ты не понимаешь.

Есть. Без констрейнтов вообще нет способа для объекта типа Т вызвать какую-либо ф-ю (если только сама эта ф-я по T не полиморфна). С констрейнтами - есть.

то что мешает вообще обойтись без T и использовать IInterface?

Разница вот в чем, есть у тебя некая полиморфная по T ф-я f, которая принимает T и возвращает T (что-то с ним делает). В констрейнте указано что T реализует IInterface. Теперь если у нас есть Х (уже не полиморфный тип, а обычный), который реализует IInteraface и мы к нему применяем f, то результат будет Х. И значит мы сможем к результату применять ф-и, определенные не только для IInterface, но и специфичные для самого Х. Если бы мы воспользовались обычным полиморфизмом, то возвращаемый тип был бы IInterafce а не Х и информация о конкретном типе была бы утеряна.

Он не может быть заведомо некорректным, потому что до инстанцирования неизвестно, реализует T синус или нет

Вот именно, что знаем.

(а если знаем, что T должен принадлежать какому-то типу, как в констрейнтах, то надо этот тип и использовать)

Выше объяснил, почему не можем.

Да, шарп поощряет широкое использование наследования и попытка их скрестить с дженериками приводит к проблемам, для решения которых вводятся новые костыли.

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

В плюсах вместо наследования больше используются шаблоны

Лол. Шаблоны и наследование - ортогональные понятия. Ок, сделай мне, ну например, темплейт для List<T>, но так, чтоб он был ковариантен (то есть если Х подтип Y (например Х наследует Y) то List<X> подтип List<Y>).

Да, все характеристики и координаты объектов в целых числах, например, кроме длины. Длина, внезапно, - может быть только double. Ой, дураааак.

Ты чего тупой-то такой? При чем тут длина и другие характеристики? повторяю - все дело в ф-и Math.Sqrt, которая реализована так, что возвращает только double и ничего кроме double вернуть не в состоянии. Поставь полиморфную Sqrt<> и все будет работать.

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

Выучи определение корня - не буду кипятиться.

> Возьми и сделай.

Зачем? Это же _тебе_ надо. Меня вполне устраивает решенная задача.

Зайди на википедию, долбо*б:

И при чем тут isqrt, если речь шла о корне? Просвещайся, дурашка: http://en.wikipedia.org/wiki/Square_root И, повторяю, учи математику. Хотя бы уж на школьном уровне, если его не знаешь. Пригодится.

С констрейнтами я привел код

И потом когда я тебе объяснил, что он не работает как надо ты ответил «ну да надо переписать компилятор».

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

Я уже посчитал - показывай лямбду.

Это, что ли, умнее?

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

> просад по производительности в 2 раза.

Где там полтора раза-то? Может, ты все-таки считать научишься? Еще, кстати, обратим внимание на то, что шарп сожрал втрое меньше памяти.

>Разница вот в чем, есть у тебя некая полиморфная по T ф-я f, которая принимает T и возвращает T (что-то с ним делает). В констрейнте указано что T реализует IInterface. Теперь если у нас есть Х (уже не полиморфный тип, а обычный), который реализует IInteraface и мы к нему применяем f, то результат будет Х. И значит мы сможем к результату применять ф-и, определенные не только для IInterface, но и специфичные для самого Х. Если бы мы воспользовались обычным полиморфизмом, то возвращаемый тип был бы IInterafce а не Х и информация о конкретном типе была бы утеряна.

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

Шаблоны и наследование - ортогональные понятия. Ок, сделай мне, ну например, темплейт для List<T>, но так, чтоб он был ковариантен (то есть если Х подтип Y (например Х наследует Y) то List<X> подтип List<Y>).

Так зачем это нужно? Потому что в шарпе если ты хочешь, например, вернуть последовательность - используешь IEnumerable. И вот один возвращает IEnumerable<string>, а другому надо вдруг IEnumerable<object> - начинаются проблемы. В плюсах так изначально не делают - см. STL. Причем часть проблем не решается и добавляются новые: во-первых, ты привел смешной пример, который шарп сам осилить не в состоянии - ковариантнасть там ограничена интерфейсами и делегатами - на классы не распространяется; во-вторых - даже одним интерфейсом IList не получится это сделать, придется на 2 разбивать: ковариантную и конравариантную часть. В шарпе сами создаем проблемы, потом сами их героически преодолеваем в следующих версиях, и очень этим гордимся.

При чем тут длина и другие характеристики? повторяю - все дело в ф-и Math.Sqrt, которая реализована так, что возвращает только double и ничего кроме double вернуть не в состоянии. Поставь полиморфную Sqrt<> и все будет работать.

При том, чтобы ты понял, что если я хочу работать в целых цислах, использую Point<int> и Line<int>, то не хочу, чтобы какая-то функция неожиданно мне double вернула. Вообще это самоочевидно, иначе зачем вообще параметризовать - проще сразу в double работать. Но ты уперся, что Length может быть только double, потому что по-другому сделать не можешь, а признаваться в фейлах не умеешь. Если появились какие-то идеи - приведи полный работающий код на шарпе для всех классов, а я приведу на плюсах, и сравним.

>Меня вполне устраивает решенная задача.

«Меня вполне устраивает нерешенная задача». fixed.

И при чем тут isqrt, если речь шла о корне? Просвещайся, дурашка: http://en.wikipedia.org/wiki/Square_root И, повторяю, учи математику. Хотя бы уж на школьном уровне, если его не знаешь. Пригодится.

Я написал, что можно взять корень из целого числа, ты пару дней веселил меня своими знаниями, что «корень из 5 может быть либо дробью, либо его не существует, если только в реальности плюсоблядков». Я тебе дал ссылку, что корень из 5 вполне себе существует и теперь ты делаешь вид, что всегда про это знал, не понимал, о чем шла речь, а думал что речь шла исключительно про совсем другое. Ага-ага. Ты жалок в своей патологической неспособности признать очевидный фейл, хотя он ведь от этого он не становится менее очевидным. Все, что тебе остается - это толсто троллить, делая вид, что это был не фейл, а продуманная стратегия. Это касается и фабрик и результатов тестов, где шарп сливает.

И потом когда я тебе объяснил, что он не работает как надо ты ответил «ну да надо переписать компилятор».

Чего это оно не работает? Очень даже работает. Не так как в шарпе, но это очень хорошо, что не так как в шарпе. Пруф - вот эта вот тягомотная история, в ходе которой, ты так и не можешь представить работающий код. Хорошо, если управишься к концу года.

Я уже посчитал - показывай лямбду.

Посчитал - выложи код. Говно из double и IConvertible не предлагать.

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

Ты сэкономил 186 байт в исходном тексте и увеличил время выполнения с 68 до 107 секунд. Вот о чем тут еще можно говорить. (Память - да, с этого начинать надо было, но ты же троллить предпочел и говорить, что на шарпе во всех отношениях программа лучше, намного короче и машинное время не важно)

> а если в контексте вызова - у тебя уже есть объект типа T

Речь именно о контексте вызова. Объект типа T есть - да не тот. Мне же нужен объект, который вернула ф-я, а не который она приняла - это другой объект. Причем это может быть и не T, а какой-нибудь IEnumerable<T>. Причем может быть ф-я никакого объекта типа T даже и не принимала - я просто указал его тип в полиморфном аргументе. Кроме того это все имеет смысл обсуждать, когда речь идет о полиморфных ф-ях, если речь идет о полиморфных классах тут уже преимущества генериков над виртуальным полиморфизмом совсем явные (ну не то чтобы преимущества - это разные инструменты для решения разных задач, на самом-то деле). Например, тот же List<T> - ну конечно можно реализовать параметризованную коллекцию на виртуальном полиморфизме, но все подобные реализации отличаются значительной кривизной.

Придумать ситуацию, где без дженериков не обойтись можно, конечно, но с констрейнтами их не так много уже.

Констрейнты - это не ограничения, это уточнения. Я же объяснял - если реализовывать «честный» параметрический полиморфизм, а не хак с макросподстановкой, то констрейнты - единственный способ расширить возможности такого полиморфизма. В общем ограничения накладываются самим фактом наличия параметрического полиморфизма (когда полиморфный тип существует именно как тип, а не как некий виртуальный аргумент на место которого потом будет подставлен монотип), а констрейнты - естественный способ убрать часть таких ограничений.

В плюсах так изначально не делают - см. STL.

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

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

Это не существенно, сделай не List<>, а IEnumerable<>.

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

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

то не хочу, чтобы какая-то функция неожиданно мне double вернула.

Тогда напиши ф-ю, которая будет возвращать или дабл или инт.

Но ты уперся, что Length может быть только double

Да при чем тут Length вообще? Length может быть каким угодно, все дело в Math.Sqrt - и оно возаращает только double. Если бы была параметризованная ф-я корня - никаких проблем, был бы тебе и дабл и инт и что угодно.

Если появились какие-то идеи - приведи полный работающий код на шарпе для всех классов, а я приведу на плюсах, и сравним.

А я и не отрицаю, что на плюсах эта частная задача будет короче. на самом деле есть очень простое решение: Line<A,B>(x1,y1,x2,y2) -> Line<B>(delegate, x1, y1, x2, y2) делегат содержит «конструктор» точки. По вызову оверхеда никакого даже не будет, потому что мы просто вместо А будем вписывать нужный делегат. Но это решение не совсем вписывается в ход дискуссии. А проблема в следующем - ну приведу я тебе решение, которое на плюсах будет короче, но это решение хоть будет, а вот ты ни констрейнтов ни ковариантности на плюсах не сделаешь в принципе.

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

Та программа, о которой я говорил, вдвое короче.

> Я тебе дал ссылку, что корень из 5 вполне себе существует

Не существует. Он даже называется по-другому, для особо одаренных.

Не так как в шарпе

То есть не работает.

Говно из double и IConvertible не предлагать.

А в чем проблема с double и IConvertible? В отличии от твоих велосипедных констрейнтов оно, хотя бы, работает ТАК ЖЕ как в плюсах.

>приходится лепить километровые work around.

Не встречал.

Если бы была параметризованная ф-я корня - никаких проблем, был бы тебе и дабл и инт и что угодно.

Ну и как это сделать-то - не томи.

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

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

А я и не отрицаю, что на плюсах эта частная задача будет короче.

Это задача из реального проекта на шарпе, только здесь я ее сократил и утрировал. Как только дженерики встречаются с математикой, все выливается в копипаст. Допускаю, что в задачах «БД<=>WinForms» шарп блистает.

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

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

С ковариантностью вообще nobody cares в C++. Почему? Нет дженериков -> нет констрейнтов -> не надо обвязываться интерфейсами -> не надо конвертировать между интерфейсами. Надо обработать последовательность? Пишешь темплейтный метод - ему пофиг, что прилетит - стринги или объекты (на дженериках, без in/out T такого написать нельзя, сохраняя типобезопасность). Зачем требовать ходить на костылях, если человек не хромает? Если хочется именно решать трудности в стиле C#, можно сделать темплейтный итератор, который будет обходить коллекцию и возвращать нужный тип. Нет в этом ничего сложного или эксклюзивного.

>Та программа, о которой я говорил, вдвое короче.

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

>То есть не работает.

То есть не так как в шарпе.

А в чем проблема с double и IConvertible? В отличии от твоих велосипедных констрейнтов оно, хотя бы, работает ТАК ЖЕ как в плюсах.

Нет, в плюсах не так. В плюсах, компилятор выведет тип в зависимости от типа аргумента, инстанцирует нужным типом length, найдет и подставит нужную версию sqrt (int, float, double, какой-то свой decimal - без разницы). Никаких головной боли, в отличии от.

А родной Tk? Это GUI от TCL, прибитый гвоздями к Питону:) Считается дефолтным GUI.

Для вас вамым подходящим вариантом был бы Lazarus. И простота, и визуальный редактор форм как в Дельфях. Это идеальная среда для новичков. Как вариант - Gambas, но только для Unix-like. И ещё неплох Python с PyGTK или PyQt, но с получением исполняемого файла будет геморой. Есть Vala, всем хорош язык, и бинарники можно компилить и под Windows(есть Win32-порт), и язык сам очень высокоуровневый, но с документацией и примерами там очень плохо пока. Поэтому Lazarus - это лучший выбор.

> Это GUI от TCL

И каких только сказок не расскажут на ночь на лоре!..

> И каких только сказок не расскажут на ночь на лоре!..

заткнем за пояс Ганса Христиана и прочих!

> Не встречал.

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

Ну и как это сделать-то - не томи.

Ну как-как? double меняешь на T а математически ф-и на полиморфные аналоги - все.

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

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

В шарпе усилия для его реализации таковы, что проще просто забить на него.

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

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

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

тогда этот шаблон вообще никого не интересует

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

Нет дженериков -> нет констрейнтов -> не надо обвязываться интерфейсами -> не надо конвертировать между интерфейсами.

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

Надо обработать последовательность? Пишешь темплейтный метод - ему пофиг, что прилетит

Я не понял, при чем тут вообще темплейтный код. Вот я пишу ф-ю void f(IEnumerable<X> x), я в нее благодаря ковариантности могу засунуть любой IEnumerable<Y>, где Y - подтип X. Никаких темплейтов, f - обычная ф-я. Ты, как я понял, пытаешься заменить ее темплейтной ф-ей с параметром X? Ну во-первых сама идея заменять нормальные ф-и темплейтными не кажется слишком удачной (особенно в плюсах, где темплейты не компилятся), во-вторых - как ты собрался контролировать ту самую типобезопасность? Вообще аналогичным образом можно и на шарпе ф-ю заменить генериком, так что вообще не ясно чем тут плюсы могут быть лучше.

Вообще для решения задачи автора нужен соотв. инструмент типа GNUPlot и Tioga(что-то там), ведь ему же график cos'инуса изобразить надо. Регулировать «скролл-барами» по-моему даже из BASH скриптов с использованием yad'а можно.
А так вообще Gambas - простой и понятный язык с крутейшей IDE (вроде ничего особо навороченного, но какая удобная!), хоть и притравленный объектно-ориентированностью. Так что люто плюсую за Gambas.

Да, аналог GNUPlot - это Ctioga. Ни за что бы не вспомнил, но у меня карборуль и алюмовынос руля на велосипеде как раз Tioga.

Во вещь: http://ctioga2.rubyforge.org/galleries.html
Кажется, оно на ruby написано...

Tk - это GUI, реализованный как расширение для замечательного языка Tcl. И это неоспоримый факт. Его прикрутили к Python просто потому, что это лёгкая и очень практичная библиотека. Но большинству она не очень по душе, неказистая очень.

Строго говоря, Tk - кросплатформенная библиотека виджетов на Си, сделанная, таки да, для работы в первую очередь с tcl.

Видали мы эти «строки» в 600 символов на Математике...

> Хотелось бы что то нечто html/css только под «исполняемые файлы».

php-gtk, только там не прямо html, а некое подобие

>Ну как-как? double меняешь на T а математически ф-и на полиморфные аналоги - все.

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

Просто в первом случае мы передаем тип, а во втором - конструктор этого типа, разницы тут никакой.

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

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

В плюсах сплошное ФП и лямбды. Даже раздражает иногда.

Если ты пишешь какую-то числодробилку - то зря выбрал шарп, если эе ты пишешь что-то другое - то не выливается. Просто на шарпе надо писать как на шарпе, а не как на с++.

Числодробилка - лишь некоторые плагины. Остальное - гуй, отчеты и пр. Как написать на шарпе, как на шарпе, но чтобы это тонны бойлерплейта не порождало?

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

В примере с синусом ошибка будет очень внятная, компилятор скажет, что не нашел определение этой функции для данного типа. В более сложных случаях static_assert в связке с is_base_of, has_method и прочим.

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

Как в примере с синусом - не получится использовать темплейтную функцию с некорректным типом.

Вообще аналогичным образом можно и на шарпе ф-ю заменить генериком, так что вообще не ясно чем тут плюсы могут быть лучше.

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

Питон, к тому же он умеет гтк и Qt.

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

Но при чем тут шарп? Это проблема стандартной библиотеки, в которой нету полиморфных аналогов для соответствующих ф-й, но никак не самого шарпа.

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

Ну да, шарп типы не выводит. Только дело тут уже не в генериках.

В плюсах сплошное ФП и лямбды.

Это ты про буст чтоли? Чересчур толсто.

Остальное - гуй, отчеты и пр. Как написать на шарпе, как на шарпе, но чтобы это тонны бойлерплейта не порождало?

Написать числодробилку на чистом си, а гуй, отчеты и пр. - на шарпе.

В примере с синусом ошибка будет очень внятная, компилятор скажет, что не нашел определение этой функции для данного типа.

Ну то есть компилятор указывает неверное место ошибки (ошибка-то в попытке инстанцировать шаблон, функция sin тут вообще не при делах). Просто отлично.

Как в примере с синусом - не получится использовать темплейтную функцию с некорректным типом.

То есть никак.

Ты сам выше написал, что не видишь смысла делать ее дженериком.

Я не «не вижу смысла делать генериком», я вижу, что делать генериком - это очень плохое решение.

Вот никто так и не делает в шарпе.

Правильно - зачем использовать плохое решение, если есть хорошее с вариантностью? Ты вот попробуй эту темплейтную функцию потом передать параметром куда-нибудь, например.

Нет, чтобы сразу дженериком сделать.

Ну раньше - делали, а сейчас зачем?

А в плюсах издавна принято шаблон итератора передавать.

Ну альтернативы-то нет - приходится жрать что дают.

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

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

Дадада
Оч. приятный язык.
Только, вряд ли автор темы осилит.