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

>Это было бы все очень убедительно, если бы не джава.

Это говорит лишь о том, что у Java реализация быстрее. Да, я в курсе. Но это не повод называть Mono «тормозным».

>То есть с++ не нормальный язык, раз там об этом не говорят? Какбе что и требовалось доказать, ок.

Похоже, ты C++ не знаешь. Это плохо.

Зачем? Нормальный компилятор делает лучше - он сразу дает ошибку, при написании такой функции, а не при ее инстанцировании. Это расширение системы типов - не просто полиморфизм, а полиморфизм с ограниченной квантификацией. Дело все в том, что в этом контексте (если считать темплейты параметрическим полиморфизмом) с++ НЕ является статически типизуремым языком, т.к. полиморфный тип типизируется динамически...

Постараюсь достучаться до твоего рассудка, пока белый шум его не съел. Ты понимаешь о чем я? Мне нужно параметрически вычислять математическую функцию. Если трансцендентные функции мешают пониманию, то представь, что в приведенный класс Line мне надо свойство Length добавить. На моем костыльном языке это одну строку занимает. Как мне это сделать на твоем замечательном языке? Покажешь или опять скажешь, что мне это на самом деле не нужно, нужен шарп и проспамишь о своем виденьи полимофизма?

Извини, но темплейты в качестве программирование - не хуже. Они именно что _убоги_.

Подкрепи свое мнение чем-нибудь кроме слов. Скучно одно и тоже читать.

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

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

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

Для тебя метапрограммирование = написание dsl'ев?

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

Если ты считаешь, что я сделал что-то нарочно неправильно - покажи как правильно. Только сохрани иммутабельность, параметризуемость и конструктор из 4-ех параметров.

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

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

>Это когда тип аргументов проверяется во время вычисления ф-и, а не во время ее определения.

Уверен, что так в C++ происходит?

>Это говорит лишь о том, что у Java реализация быстрее. Да, я в курсе. Но это не повод называть Mono «тормозным».

А что тогда повод? Если бы он всем вообще проиграл? По-моему, логично сравнивать примерно соответствующие по мощи и реализации языки.

> Дело все в том, что в этом контексте (если считать темплейты

параметрическим полиморфизмом) с++ НЕ является статически

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

Что? Вы уверены в том, что вообще что-либо понимаете в обсуждаемом вопросе?

Похоже, ты C++ не знаешь. Это плохо.

Погоди, это же ты сам привел пример, где с++ никакой ошибки не выдавал и спокойно проглатывал некорректный код?

Как мне это сделать на твоем замечательном языке?

Так же - добавить одну строку.

Подкрепи свое мнение чем-нибудь кроме слов. Скучно одно и тоже читать.

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

Сейчас, значит, он бесполезен для компайл-тайма и абсолютно беспомощен по сравнению с «убогими темплейтами»?

При чем тут вообще компайлтайм? Я для особо одаренных повторю - параметрический параморфизм это НЕ замена темплейтов и с метапрограммированием он не связан. Наоборот - темплейты это попытка смоделировать параметрический полиморфизм при помощи метапрограммирования. Смоделировать получилось не полностью, чтобы не было обидно запилили вместо этого пару незначительных фич.

Для тебя метапрограммирование = написание dsl'ев?

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

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

using System;

namespace ConsoleApplication1
{
    abstract public class Point< T >
    {
        abstract public void Initialize(T x, T y);
        public T X { get; protected set; }
        public T Y { get; protected set; }
    }

    class LinearPoint< T > : Point< T >
    {
        public LinearPoint() { }
        public override void Initialize(T x, T y) 
        {
            X = x;
            Y = y;
        }
    }

    class PolarPoint : Point<double>
    {
        public PolarPoint() { }
        public override void Initialize(double r, double phi) 
        { 
            X = (float)(r * Math.Cos(phi)); 
            Y = (float)(r * Math.Sin(phi));
        }
    }

    public class Line<P, T>
        where P: Point< T >, new()
    {
        public Line(T x1, T y1, T x2, T y2)
        {
            A = new P();
            A.Initialize(x1, y1);
            B = new P();
            B.Initialize(x2, y2);
        }

        public P A { get; private set; }
        public P B { get; private set; }
    }

   class Program
   {
       static void Main(string[] args)
       {
           var line1 = new Line<LinearPoint<double>, double>(0.0, 0.0, 0.0, 0.0);
           Console.WriteLine(line1);
           var line2 = new Line<PolarPoint, double>(0.0, 0.0, 0.0, 0.0);
           Console.WriteLine(line2);
       }
   }
}

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

А зачем их делать? Зачем вообще на языке А писать как на языке В? На А надо писать как на А, на В - как на В. Нормальный человек сделал бы конструктор, который принимает поинты, и не парил бы себе мозг, потому что разницы в использовании не будет никакой. Только цепепе обезьянка бегает и вопит «хачу как в темплейтах». Теперь давай продемонстрируй-ка мне аналог ограничений на полиморфный параметр.

> Уверен, что так в C++ происходит?

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

> Что? Вы уверены в том, что вообще что-либо понимаете в обсуждаемом вопросе?

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

> По-моему, логично сравнивать примерно соответствующие по мощи и реализации языки.

Так с какой стати тогда ты сравниваешь сишарп и джаву? Джава - это 10% от сишарпа. Сделают хотя бы половину - тогда будет сравнивать.

Погоди, это же ты сам привел пример, где с++ никакой ошибки не выдавал и спокойно проглатывал некорректный код?

Что в вычислении синуса некорректно?

Так же - добавить одну строку.

Прошу привести эту строку целиком (вычисление длины отрезка по точкам в параметризованном типе Line)

Я не понял, у тебя какие-то сомнения в том, что найдется задача на метапрограммирование, которая в моем лиспе решается в 10 строк,

Ты не понял, потому что сфокусироваться никак не можешь: мы о C++ и C#. То, что ты все время пытаешься спрятаться, то за Nemerle, то за F#, то за Лисп, язык не красит. Соберись.

При чем тут вообще компайлтайм? Я для особо одаренных повторю - параметрический параморфизм это НЕ замена темплейтов и с метапрограммированием он не связан.

Что ты к полиморфизму-то привязался? Я же спрашивал - есть ли в шарпе средства для метапрограммирования в компайл-тайме? Ответь как есть.

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

Поэтому для введения линка пришлось новую версию языка делать - потому что шарп так здорово для конструирования DSL подходит? Spirit'у бы такой размах.

using System;

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

А зачем их делать?

Если бы ты сделать мог - это бы звучало искренне. А так как-то лицемерно: попробовал - не вышло - и начал рассуждать в стиле «а не очень-то и хотелось».

Зачем вообще на языке А писать как на языке В? На А надо писать как на А, на В - как на В. Нормальный человек сделал бы конструктор, который принимает поинты, и не парил бы себе мозг, потому что разницы в использовании не будет никакой.

А что я такого невыполнимого попросил? Параметризованных типов - вроде нормально, ты говоришь, что только в шарпе и есть нормальная реализация параметрического полиморфизма. Иммутабельности - тоже вроде бы ничего запредельного. Конструктор линии по координатам? Ну как бы и не обязательно, но удобно: если у тебя есть координаты - пусть конструктор сам построит по ним нужные объекты. Зачем, как обезьяна, каждый раз new писать? В С++ можно и конструктор по координатам и по поинтам сделать, не делать мучительный выбор и пользоваться тем, который удобнее. В C# это вырастает в теоретическую проблему и приходится или костыли городить(Initialize) или съезжать на «а зачем вообще это все нужно». Подождем, может ты и про длину отрезка так говорить будешь.

Только цепепе обезьянка бегает и вопит «хачу как в темплейтах».

Ну-ну, не расстраивайся. Не получилось и не получилось. Зато у тебя сборка мусора.

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

Ограничение на тип:

class fail { char _[ 2 ]; };
class success { char _; };
template< typename Derived, typename Base >
class is_base_of
{        
        static fail probe( ... );
        static success probe( Base * );
public:
        static const bool value = ( sizeof( probe( ( Derived * ) 0 ) ) ==
                                      sizeof( success ) );
};

>Так с какой стати тогда ты сравниваешь сишарп и джаву? Джава - это 10% от сишарпа. Сделают хотя бы половину - тогда будет сравнивать.

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

Что в вычислении синуса некорректно?

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

Прошу привести эту строку целиком (вычисление длины отрезка по точкам в параметризованном типе Line)

        public double Length()
        {
            IFormatProvider provider = new NumberFormatInfo();
            return Math.Sqrt(Math.Pow(B.X.ToDouble(provider)-A.X.ToDouble(provider), 2.0) + Math.Pow(B.Y.ToDouble(provider)-A.Y.ToDouble(provider), 2.0));
        }

Ну и добавить IConvertable в ограничения.

Ты не понял, потому что сфокусироваться никак не можешь: мы о C++ и C#.

Нет, это ты не понял. Мы о метапрограммировании в с++. И система метапрограммирования с++ убога. Не в сравнении с какой-то другой системой - просто сама по себе убога. Так же как brainfuck убог - не в сравнении с чем-то, а в принципе, сам по себе.

есть ли в шарпе средства для метапрограммирования в компайл-тайме?

Нету.

Поэтому для введения линка пришлось новую версию языка делать - потому что шарп так здорово для конструирования DSL подходит?

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

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

Так я сделал, все как ты просил.

А что я такого невыполнимого попросил?

Ты попросил сделать кривой костыль, который можно не делать. В с++ ограничений нет - соответственно там просто лепить кривые костыли, с++ стимулирует использовать стиль с костылями. В с# они есть (система типов мощнее), по-этому костыли лепить сложнее, c# стимулирует использовать другой стиль.

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

Не только в сишарпе, естественно. Но в с++ ее нет. И ты просишь реализовать костыль, который можно реализовать просто именно из-за неполноценной поддержки параметрического полиморфизма темплейтами.

если у тебя есть координаты - пусть конструктор сам построит по ним нужные объекты.

Зачем? Вариант с поинтами вообще со всех сторон лучше. Еще и второй аргумент генерика убрать можно.

В C# это вырастает в теоретическую проблему

В C# нет никакой проблемы, как я уже сказал, только плюсо-обезьянки вопят «хочу как в темплейтах», потому что кроме темплейтов они ничего не знают, и пытаются недостатки реализации выдавать за «фичи».

Не получилось и не получилось.

Что не получилось-то? Все прекрасно получилось и работает.

Ограничение на тип:

Здесь нету ограничения на тип. Повторяю, что требуется сделать. Допустим у нас есть шаблон с параметром T, мы для объекта класса T вызываем некоторый метод f, который принадлежит интерфейсу (ну или просто какому-либо классу) Parent. Надо, чтобы компилятор выдавал ошибку при компиляции _шаблона_ (не его его инстанциации), если не известно что T является наследником Parent. другими словами тебе нужно ввести новую конструкцию (constrained_template назови ее, например), ввести синтаксис для описания ограничений и немного видоизменить компилятор для того, чтобы реализовать соответствующие проверки. Не думаю, что с ТАКОЙ-ТО системой метапрограммирования столь простая задача вызовет какие-то затруднения.

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

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

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

Тебя обманули, в этом нет никакой некорректности. Некорректность была бы, если бы программа компилировалась при неопределенном для типа синусе. Но, слава Страуструпу, это не так.

public double Length()

Отлично, код - это всегда предметней, чем общие слова. Во-первых, вместо того, чтобы просто посчитать и вернуть длину - программист на шарпе вынужден обмазываться ворохом посторонних классов и интерфейсов IFormatProvider, NumberFormatInfo, IConvertible. Во-вторых, ты либо будешь создавать объект в куче при каждом вызове Length, либо придется вынести его в Line (который там ни к чему - просто костыль, чтобы конвертация GC не грузила за зря). В третьих, это вообще не то. Point и Line - зря что ли параметризованы T? Это значит, что я могу использовать Point<float>, Point<int> и т.д. Очевидно, что и длина отрезка должна быть того же типа, что и координаты точки, т.е. сигнатура такая должна быть:

public T Length()

Мы о метапрограммировании в с++.

Нет, сравнивали решение задачи на C# и C++.

Не в сравнении с какой-то другой системой - просто сама по себе убога.

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

Нету.

Жаль. Но ведь это костыль тоже, да, и это не нужно? Куда проще отдельные утилиты писать, считать, что нужно, и вставлять в текст программы.

В с++ ограничений нет - соответственно там просто лепить кривые костыли, с++ стимулирует использовать стиль с костылями. В с# они есть (система типов мощнее), по-этому костыли лепить сложнее, c# стимулирует использовать другой стиль.

Каждый раз писать new Point(),new Point() - это не костыль, а если за тебя конструктор это делает - это костыль? Ясно. Параметризуемый Length - тоже костыль? Прозреваю, что параметризуемая точка в полярных координатах - тоже летит туда же. Ве сходится. Все, что нереализуемо по тем или иным причинам в шарпе - это костыль. И мощная система типов в шарпе, думая о нас, не дает их реализовать. Так ты видишь мир?

Зачем? Вариант с поинтами вообще со всех сторон лучше. Еще и второй аргумент генерика убрать можно

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

Что не получилось-то? Все прекрасно получилось и работает.

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

Здесь нету ограничения на тип.

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

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

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

>Эй, подожди, ты же сам сказал, что на тесты надо смотреть в том случае, если языки близки по мощности. Вот будет жаба близка по мощности к с# - будем смотреть на тесты.

Твой пост звучит так: «мы добавили в язык linq и другие замыкания и теперь циклы и операторы ветвления стали работать на 50% медленнее». Ну, можно и так все объяснить, конечно.

Тебя обманули, в этом нет никакой некорректности. Некорректность была бы, если бы программа компилировалась при неопределенном для типа синусе.

Она и компилируется при синусе, который не определен для типа T. Это и есть некорректность, о которой я говорю.

т.е. сигнатура такая должна быть:

Это некорректно.

Можно сделать правильно?

В шарпе - можно, в с++ - нет.

Нет, сравнивали решение задачи на C# и C++.

Не было такого. Речь шла исключительно о метапрограммировании в с++.

Самого по себе ничего в мире нет, все познается в сравнении.

Есть, есть. Абсолютный ноль - он потому и абсолютный.

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

Нет, я который пост пытаюсь тебе объяснить, что такое генерики. Линии, точки и длины были посчитаны еще несколько страниц назад.

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

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

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

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

Каждый раз писать new Point(),new Point() - это не костыль, а если за тебя конструктор это делает - это костыль?

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

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

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

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

А, забыл. Ну это непринципиально, надо только сделать, чтобы Initialize возвращал Point вместо void.

        public override Point< T > Initialize(T x, T y) 
        {
            var tmp = new LinearPoint<T>();
            tmp.X = x;
            tmp.Y = y;
            return tmp;
        }

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

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

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

Так в том и дело, что нет.

template< typename T > T try_repeat_in_powerful_sharp( T value ) { return sin( value ); }

вот это некорректное говно на плюсах скомпилируется, а аналог в шарпе - нет.

Ты предлагаешь вот этот бушующий ад, который мы наблюдаем в шарпе, перенести в C++?

То есть не можешь? К, слив засчитан.

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

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

> Твой пост звучит так: «мы добавили в язык linq и другие замыкания и теперь циклы и операторы ветвления стали работать на 50% медленнее».

К, убираем linq и замыкания - теперь джава это не 10% от шарпа, а 20% шарпа, что хоть и вдвое больше, чем раньше, но никак не дотягивает до 50%.

>Она и компилируется при синусе, который не определен для типа T.

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

Так вот почему тебе C++ не нравится. Ты вообще не понимаешь, как шаблоны работают. Возьми уже компилятор в руки скомпиль и посмотри - скомпилилась функция в файл или нет. А то так и останешься в мире своих фантазий жить.

В шарпе - можно, в с++ - нет.

Покажешь, как в шарпе? Или «знаю, но не скажу»?

Не было такого. Речь шла исключительно о метапрограммировании в с++.

Зачем ты тогда с шарпом влез своим, в котором представить в противовес особо нечего?

Линии, точки и длины были посчитаны еще несколько страниц назад.

Неправильно же были посчитаны. И до сих пор ниасилил длину. Или ты как бы из будущего пишешь?

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

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

А причину, по которой вычисления чисел Фибоначчи во время компиляции не нужны, я уже называл - компилятор и так автоматом вычисляет все, что можно вычислить. В частности, любую ф-ю от константы.

Про Фибоначчи согласен, но хотелось бы пруф на вычисление функций в C# во время компиляции.

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

В пределе, когда в C#-X тебе запретят все, ты станешь всемогущ. При словах «свобода долбиться в жопу» представил такой код: «var tmp = new Point(); A = tmp.Initialize(x, y);» Это из шарпа что ли?

А, забыл. Ну это непринципиально, надо только сделать, чтобы Initialize возвращал Point вместо void. Сеттер, конечно, остается protected - хотя от этого тоже можно избавиться, если сделать Point интерфейсом и поля X Y добавлять руками в реализацию с правитным сеттером (как в твоем оригинальном варианте), но я не вижу смысла, так лучше.

Да, только protected сделать - значит реализацию наследникам открыть, я могу от Point'а унаследовать HackPoint получить доступ к X, Y, передавать этот объект везде вместо Point< T > и покласть на иммутабельность. И IPoint c приватными сеттерами не решат эту проблему. Но в принципе пофиг - я доволен решением. Чтобы сконструировать линию по точкам тебе приходится создавать костыльные объекты из которого создается другие объекты того же класса, но уже нужные. По бестолковости это примерно соответствует использованию активатора и хорошо характеризует возможности языка.

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

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

То есть не можешь? К, слив засчитан.

Не надо предлагать говном вымазаться на слабо. Это не пройдет.

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

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

>К, убираем linq и замыкания - теперь джава это не 10% от шарпа, а 20% шарпа, что хоть и вдвое больше, чем раньше, но никак не дотягивает до 50%.

Запости сразу список фич, которые мешают циклам в полную силу развернуться. Не томи. Наверное, надо компилить с профилем C# 1.0. Вот где скорость будет.

> Ты вообще не понимаешь, как шаблоны работают. Возьми уже компилятор в руки скомпиль и посмотри - скомпилилась функция в файл или нет. А то так и останешься в мире своих фантазий жить.

Скомпилировалась. Что дальше?

Покажешь, как в шарпе?

Я же уже показал.

Зачем ты тогда с шарпом влез своим, в котором представить в противовес особо нечего?

А я и не влезал с шарпом, это ты начал с шарпом сравнивать.

Неправильно же были посчитаны.

Чем же неправильно? Все вполне правильно, результат идентичен требуемому.

И до сих пор ниасилил длину.

как это не осилил если пример в предыдущем (или позапредыдущем?) посте.

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

Ну так омжет пруф? То есть сделаешь реализацию на шаблонах аналога, в котором можно передавать только 1 аргумент?

Про Фибоначчи согласен, но хотелось бы пруф на вычисление функций в C# во время компиляции.

Кто говорил о вычислении в с# ф-й во время компиляции?

В пределе, когда в C#-X тебе запретят все, ты станешь всемогущ. При словах «свобода долбиться в жопу» представил такой код: «var tmp = new Point(); A = tmp.Initialize(x, y);» Это из шарпа что ли?

Обычное кукареканье неосилятора статической типизации.

Да, только protected сделать

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

И IPoint c приватными сеттерами не решат эту проблему.

Решит.

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

Нет, поверь, написание некорректного кода (как в с++ или с активаторами) заведомо бестолковее. Хотя бестолкова вообще попытка велосипедить зачем-то йоба-конструкторы, когда можно просто передавать точки.

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

Ты чего тугой-то такой? Я же тебе объясняю - результат будет _разный_. Код на с++ (некорректный) скомпилируется, а на шарпе будет ошибка. Возьми уже и проверь. Лороиксперты такие иксперты, все время горазды пиздеть о том, в чем ни бельмеса не смыслят.

Не надо предлагать говном вымазаться на слабо. Это не пройдет.

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

Ну возникли у тебя затруднения

Какие? У меня никаких затруднений не возникало, я как писал new Line(new Point(...), new Point(...)) так и пишу безо всяких затруднений.

> Запости сразу список фич, которые мешают циклам в полную силу развернуться.

А при чем тут циклы-то? Покажи мне хоть один тест на шутауте который зависит от производительности реализации циклов.

Скомпилировалась. Что дальше?

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

Я же уже показал.

Ты для double показал, а у нас Point и Line параметризованы T, T - не обязательно double, неужели это понять так сложно. Напиши «public T Length()». Который день прошу.

как это не осилил если пример в предыдущем (или позапредыдущем?) посте.

Я сразу написал, почему не осилил. Ты либо не читаешь и сразу отвечаешь, либо не в состоянии смысл выделить, либо в глухой троллинг ударился от безысходности.

Ну так омжет пруф? То есть сделаешь реализацию на шаблонах аналога, в котором можно передавать только 1 аргумент?

Всю простыню писать не буду, покажу только, как с одним аргументом сделать:

template< typename T > struct point { typedef T coord; };
template< typename P > struct line {
	typedef typename P::coord coord;
	line( coord a1, coord a2, coord b1, coord b2 );
	coord length() const;
};

Кто говорил о вычислении в с# ф-й во время компиляции?

Здесь ты мне объяснял, почему вычисления в компайл-тайме на шаблонах не нужны: «А причину, по которой вычисления чисел Фибоначчи во время компиляции не нужны, я уже называл - компилятор и так автоматом вычисляет все, что можно вычислить. В частности, любую ф-ю от константы.» Теперь спрашиваешь, кто мне это говорил. Из этого 2 вывода можно сделать: 1) в шарпе, как обычно, на эту тему ничего нет и темплейты по-прежнему нужны; 2) возможно, у тебя раздвоение личности.

Обычное кукареканье неосилятора статической типизации.

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

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

И так уже все поняли, что нет в шарпе нормального способа создать immutable объект в дженерике. Можно только передать готовый. Хватит оправдывать бессилие и заострять на этом внимание. Замни.

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

Какая ирония, что ты мне это пишешь. Учи шаблоны. «template< typename T >» не означает «для любого типа», а означает «для любого типа, соответствующего неявному интерфейсу». Соответствующие типы компилятор пропустит, несоответствующие - завернет.

Не можешь - так и скажи, будь мужиком, блеать.

Без модификации компилятора - это невозможно. Если бы ты, или кто-то еще, быстро сбацал этот пример, и сказал бы: «видишь как все просто, намного проще, короче и безопаснее, чем в плюсах», то я бы об этом сожалел. А что вместо этого? Многодневные обсуждения, костыль на костыле, «да это все не надо» и до сих пор проблемы не решены. Я смотрю на это и радуюсь, что в C++ не так, и я не на твоем месте сейчас.

Какие? У меня никаких затруднений не возникало, я как писал new Line(new Point(...), new Point(...)) так и пишу безо всяких затруднений.

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

>А при чем тут циклы-то? Покажи мне хоть один тест на шутауте который зависит от производительности реализации циклов.

Ты вообще заходил на шутаут, признайся? Расскажи, какие крутые фичи шарпа заставляют его эпично сливать джаве здесь: http://shootout.alioth.debian.org/u32/program.php?test=fannkuchredux&lang=csh...

Заодно и другие посмотри. Сколько еще постов пройдет, пока твой фанатизм перестанет отрицать реальность?

> Расскажи, какие крутые фичи шарпа заставляют его эпично сливать джаве здесь:

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

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

Не присутствует. Что дальше?

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

Вот именно. Мы имеем некоторую программу, на шарпе выдается ошибка компиляции, на с++ все компилируется без проблем. Ну и где тут «одинаковое поведение»?

Ты для double показал

Нет, я показал для любого T. Вытри сперму с глаз.

Я сразу написал, почему не осилил.

Еще раз - вытри сперму с глаз. Все требования осилены.

Всю простыню писать не буду, покажу только, как с одним аргументом сделать:

typedef T coord;

То есть в каждый класс точек надо будет засунуть эту строку, или ничего работать не будет, я верно понял? Ваистену SCALABLE ROBUST ENTERPRIZE SOLUTION.

Здесь ты мне объяснял

И где тамх оть слово про сишарп?

1) в шарпе, как обычно, на эту тему ничего нет и темплейты по-прежнему нужны;

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

Твое глубоко личное определение и понимание типизации малоинтересно.

мое то тут при чем? Я про общепринятое.

какая типизация в C++.

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

И так уже все поняли, что нет в шарпе нормального способа создать immutable объект в дженерике.

то, что я такой способ продемонстрировал, плюсообезьянка предпочла незаметить.

«template< typename T >» не означает «для любого типа», а означает «для любого типа, соответствующего неявному интерфейсу»

Какому интерфейсу? Где указан этот интерфейс?

Без модификации компилятора - это невозможно.

Ч.Т.Д. мощная система метапрограммирования такая мощная. Зато Фибоначчи и факториалы можно в компайлтайме считать.

быстро сбацал этот пример, и сказал бы: «видишь как все просто, намного проще, короче и безопаснее, чем в плюсах»

Ну так я так и сделал...

Но тебя не только с конструктором затруднения возникли

повторяю - не возникало у меня никаких затруднений.

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

Какие именно? Ты-то втирал, что все тормоза в шарпе из-за фич каких-то мега крутых, которых в джаве нет. И там и там - циклы, ветвления, вызов функций. Если считаешь, что все из-за «короткоты» исходного текста - напиши, как в джаве и запости - кто мешает-то.

> Какие именно?

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

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

Давай наоборот? Напиши на джаве как на шарпе и запости.

>Не присутствует. Что дальше?

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

Нет, я показал для любого T. Вытри сперму с глаз.

Нет, твой Length возвращает double, и я не нанимался тебе глаза протирать. Как ты вообще кодишь, если тебе 10 раз одно и тоже объясняешь, а ты все равно понять не можешь.

То есть в каждый класс точек надо будет засунуть эту строку, или ничего работать не будет, я верно понял?

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

И где тамх оть слово про сишарп?

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

проще и удобнее вычислить и потом подставить руками

Зачем тебе вообще писать программы. Есть калькулятор - вычисли и подставь. Даже проще, чем шарп.

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

Ага, расскажи мне про темплейты, ты такой эксперт.

Конкретно - от неосиляторства нормальный макросистем и нормальных систем типов.

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

то, что я такой способ продемонстрировал, плюсообезьянка предпочла незаметить.

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

Ну так я так и сделал...

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

повторяю - не возникало у меня никаких затруднений.

Повторяю - ты в параллельной реальности существуешь.

>Не знаю, не смотрел. Вижу только, что код вдвое короче.

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

Давай наоборот? Напиши на джаве как на шарпе и запости.

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

> что в моно просто тормозная реализация шарпа.

Ну если все дело в моно, то при чем тут шарп?

На джаве программа и так быстро работает, зачем ее переделывать?

То есть не можешь?

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

Сливает? Ты смеешься? C # Mono Code B - 564 Java 6 -server Code B - 1282

И в какой же реальности шарп «сливает»? Как видно, на джаве так компактно такую задачу вообще решить нельзя. Ни за какое время. Как язык, на котором задача решается за конечное время, может слить языку, на котором задача не решается вообще?

> Дальше осознай, что функции не существует до ее инстанцирования

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

Нет, твой Length возвращает double

Естественно, он возвращает double, потому что он семантически не может вернуть ничего иного - математические ф-и возвращают double. Ты опять просишь меня писать заведомо некорректный код? Нет, спасибо - компилятор шарпа позаботится и скажет мне, что код ошибочен, в отличии от темплейтоговна, которое все проглотит и не икнет.

Можно и не в каждый

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

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

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

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

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

Зачем тебе вообще писать программы. Есть калькулятор - вычисли и подставь. Даже проще, чем шарп.

Ты совсем идиот? Я объясняю тебе популярно - вот нам надо предрасчитать что-то на этапе компиляции, мы можем написать нормальный код (100 строк) который быстро отработает и все подсчитает, можем написать темплейтоговно (которое будет занимать 10000 строк в силу того, что язык темплейтов примитивен и кроме факториалодрочерства ни для чего не приспособен, будешь спорить?). Зачем выбирать второй вариант?

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

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

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

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

Ну, может в 6-ой версии шарпа добавят такую возможность...

Возможность писать говнокод? Не добавят.

Повторяю - ты в параллельной реальности существуешь.

конечно нет.

>Ну если все дело в моно, то при чем тут шарп?

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

И в какой же реальности шарп «сливает»? Как видно, на джаве так компактно такую задачу вообще решить нельзя. Ни за какое время. Как язык, на котором задача решается за конечное время, может слить языку, на котором задача не решается вообще?

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

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

Шарп фатально повредил тебе мозг. Печально. Читай заново все посты до достижения сатори. Темплейтные функции не компилируются до инстанцирования.

Естественно, он возвращает double, потому что он семантически не может вернуть ничего иного - математические ф-и возвращают double.

В говношарпе - да. А в других языках математика успешно существует и помимо double. Бывают целочисленные вычисления, бывают вычисления с фиксированной точкой, бывают и процессоры без x87. Но тебе о таких вещах знать рано. Правда и с плавающей точкой шарп сливает. Каждый желающий может в этом убедиться, если попробует сотворить PolarPoint<double> и PolarPoint<float>. Мощнейший параметрический полиморфизм выльется в копипаст, а фанатики сорвут голос и обрастут зеленой шерстью, крича, что это все не нужно и «семантически» не верно.

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

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

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

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

Возможность писать говнокод? Не добавят.

Как убедительно доказывает твой пример, констрейнты говнокоду не помеха. Они только подстегивают врожденный талант. Надо было не Initialize вхреначивать в иммутабельный объект, а фабрики использовать. Разорись уже на книжку по паттернам, а то пойдешь работать и вы**ут за такие вещи.

Basic?

> При том, что другой реализации шарпа в линуксе нет и не предвидится.

А зачем линукс?

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

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

> Хотелось бы что то вроде html+css/javascript только с возможностью затолкать все в .exe/.bin (или вызывать из исполняемого файла).

VS2008/2010 + XAML in WPF\Silverlight + C#\VB тебя спасут...

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

Правильно сказали - в биореактор тебя, пока не поймёшь.

п.с. весь тред не читал.

> Темплейтные функции не компилируются до инстанцирования.

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

Бывают целочисленные вычисления

Ну покажи же мне волшебную ф-ю sqrt из плюсов, которая возвращает целое число.

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

То есть пруфа не будет? Вполне ожидаемо от такого пиздабола, как ты.

Решить не сможешь никогда.

Я ее _уже_ решил и привел решение те самые несколько дней назад. А вот ты еще ни одного пруфа в подтверждение своего пиздежа не привел.

а фабрики использовать.

А, понятно все, паттерноебство головного мозга. Да еще и помноженное на плюсоебство. Убойный коктейль. То, что фабрика от предоставленного решения будет отличаться только наличием лишнего бойлерплейта, пациенту и невдомек.

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

>А зачем линукс?

А зачем ты?

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

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

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

>Джава - это 10% от сишарпа.
ололо, да ты упоротый как я погляжу.

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

а что за задача то? (тред не читал). 99% задач на джаве решаются красивее и элегантнее и быстрее чем на говношарпе.

>Повторяю - именно этот факт я и пытаюсь до тебя донести, но ты никак не поймешь, почему-то.

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

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

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

Ну покажи же мне волшебную ф-ю sqrt из плюсов, которая возвращает целое число.

На, открывай для себя новые горизонты: [code=cpp] int sqrt( int x ) { assert( x >= 0 );

int rem = 0, root = 0;

for( int i = 0; i < 16; ++i ) { root <<= 1; rem = ( ( rem << 2 ) + ( x >> 30 ) ); x <<= 2; ++root; if( root <= rem ) { rem -= root; ++root; } else --root; } return( root >> 1 ); } [/code] (но не забывай, что все, чего нельзя сделать в шарпе - не нужно и душевредно, от хороших вещей нас дженерики бы не стали отгораживать)

Я ее _уже_ решил и привел решение те самые несколько дней назад.

Ты же в предыдущем посте вроде понял, что сделал не то, и начал путанно оправдываться, что математические функции ничего кроме double возвратить в принципе не могут. Я порадовался, ну ладно сделать не может, но хоть понял, наконец, что вообще надо было сделать и мысль пойдет дальше. А теперь опять «я ее уже решил». Ненадолго стало легче, и опять погрузился в беспамятство, доктор Джекил?

А вот ты еще ни одного пруфа в подтверждение своего пиздежа не привел.

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

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

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

>а что за задача то? (тред не читал). 99% задач на джаве решаются красивее и элегантнее и быстрее чем на говношарпе.

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

Не работает.

#include <assert.h>
#include <stdio.h>

int sqrt( int x ) {
    assert( x >= 0 );

    int rem = 0, root = 0;

    for( int i = 0; i < 16; ++i ) {
        root <<= 1;
        rem = ( ( rem << 2 ) + ( x >> 30 ) );
        x <<= 2;
        ++root;
        if( root <= rem ) {
            rem -= root;
            ++root;
        } else --root;
    }
    return( root >> 1 );
}

int main(void){
	int ok=0,fail=0;
	for( int i=0; i<100; i++ )	if( sqrt(i * i) == i ) ++ok; else ++fail;
	printf( "%i Ok\n", ok );
	printf( "%i fail\n", fail );
	return fail;
}

$ g++ -o sqrt sqrt.cpp
$ ./sqrt
14 Ok
86 fail

Не работает.

#include <assert.h>
#include <stdio.h>

int sqrt( int x ) {
    assert( x >= 0 );

    int rem = 0, root = 0;

    for( int i = 0; i < 16; ++i ) {
        root <<= 1;
        rem = ( ( rem << 2 ) + ( x >> 30 ) );
        x <<= 2;
        ++root;
        if( root <= rem ) {
            rem -= root;
            ++root;
        } else --root;
    }
    return( root >> 1 );
}

int main(void){
	int ok=0,fail=0;
	for( int i=0; i<100; i++ )	if( sqrt(i * i) == i ) ++ok; else ++fail;
	printf( "%i Ok\n", ok );
	printf( "%i fail\n", fail );
	return fail;
}

$ g++ -o sqrt sqrt.cpp
$ ./sqrt
14 Ok
86 fail

>Не работает.

Да, это из-за знакового бита. Поправь на unsigned. У тебя, кстати, тест не работает.

> Имхо пространства имен/наследования/классы придумали те у кого мало фантазии на имена переменных или функций

Ты, наверное, просто не видел ДЕЙСТВИТЕЛЬНО больших проектов. Где всю эту кучу глобальных объектов замучаешься отслеживать.

А если программа не очень большая и любовь к процедурной логики - классический Си и xlib тебе в руки.

> Возможно в этом как раз причина и моно не при чем. Просто никто не объяснил программистам на шарпе в чем смысл тестов.

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

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

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

> 99% задач на джаве решаются красивее и элегантнее и быстрее чем на говношарпе.

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

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

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