Вышел Rust 1.0

Шаблоны цепепе - примитивный механизм из-за их примитивного языка. Что ты можешь сделать во время компиляции на языке шаблонов цепепе? Посмотришь так на факториал с задротством вокруг enum, и аж плакать хочется. А как насчёт сгенерировать строчку в compile time шаблонами? Лучше бы Страуструп макросы сделал как положенно, а не эту гадость.

Ну да, а на их любимом C++ выражение auto x = 2 + 2; может означать что угодно, хоть отправку багрепорта Страуструпу в качестве побочного эффекта. :-)

Scala не совместима с Java на уровне исходников (как C++ с C). Они совместимы на уровне конечного продукта (байткода). Просто байткод в себе содержит все нужные метаданные для линковки, в отличие от объектных файлов, получающихся при компиляции C. Если бы в объектных файлах были метаданные (параметры функции, описания структур), совместимость с C было бы проще делать, отдельного описания не требовалось бы.

Шаблоны цепепе - примитивный механизм из-за их примитивного языка.

Шаблоны - это довольно хороший способ дать обобщенное программирование в языке для «системного» программирования.

Что ты можешь сделать во время компиляции на языке шаблонов цепепе?

Обобщенные контейнеры и алгоритмы, с возможностью специализации.

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

Это побочное использование шаблонов. Когда их вводили об этом вообще не думали.

А как насчёт сгенерировать строчку в compile time шаблонами?

Погугли.

Лучше бы Страуструп макросы сделал как положенно, а не эту гадость.

На макросах обобщенное программирование выглядит коряво.

Вот и «новый C++» должен быть совместим примерно на том же уровне. Т.е. совместимо на уровне линкера + в системе модулей делаем что-то вроде:

import "C" "stdio.h"
import "C++" "vector"

А Scala не думают на рельсы LLVM ставить?

Шаблоны - это довольно хороший способ дать обобщенное программирование в языке для «системного» программирования.

Тебя обманули. :-)

Обобщенные контейнеры и алгоритмы, с возможностью специализации.

Я говорю про время компиляции, а ты так слажался. :-)

Это побочное использование шаблонов. Когда их вводили об этом вообще не думали.

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

Погугли.

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

На макросах обобщенное программирование выглядит коряво.

Типичный обманутый/доверчивый цепепешник Ахаха :-)

Тебя обманули. :-)

Нет, тебя.

Я говорю про время компиляции

А зачем ты об этом говоришь?

а ты так слажался. :-)

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

Знаю. И довольно неплохо. Но практически не использую в реальной работе. Раньше использовал списки типов, но почти все теперь можно заменить variadic'ами.

Типичный обманутый/доверчивый цепепешник Ахаха :-)

Конструктив в твоих постах зашкаливает=)

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

Нет, тебя.

И меня тоже, в своё время :-) Шаблоны примитивны. Ты не можешь сгенерировать произвольный код с их помощью. Не можешь ты во время компиляции заставить работать cin >> input; Всё что тебе доступно - параметризация типом, интегральной константой, и другим шаблоном. Поэтому на выходе получается такой же класс, что и написанный вручную, т.е. единственный механизму абстракции в C++ - это тип, о чём я и говорил, но ты не уловил.

А зачем ты об этом говоришь?

Я развлекаюсь :-)

variadic'и - те же шаблоны, то же уныние.

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

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

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

Парочку реальных примеров из своей практики могли бы привести?

Scala on LLVM нужна была лишь полутора задротам и уже давно не обновляется, равно как и .NET-бекенд, который дропнули ещё раньше — тоже потому что оказался никому не нужным.

Шаблоны примитивны.

Примитивны по сравнению с чем?

Ты не можешь сгенерировать произвольный код с их помощью.

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

Не можешь ты во время компиляции заставить работать cin >> input;

И это плюс, а то кто-то бы воспользовался этим говном и можно было бы с этим столкнулся.

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

Этого достаточно для обобщенного программирования.

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

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

во время компиляции
сгенерировать строчку в compile time

Я тебе о абстракции. А ты мне о compile time.

Примитивны по сравнению с чем?

Язык шаблонов C++ примитивен по сравнению с самим языков C++.

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

Тебе, видимо, незачем :-)

Этого достаточно для обобщенного программирования.

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

Я тебе о абстракции. А ты мне о compile time.

Скучновато тут становится :-)

В моем идеальном сферическом языке в вакууме было бы и то и другое.

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

Скучновато. Потому что местные аналитики почему-то обсуждают недостатки крестов. Давайте уже сконцентрируемся на недостатках сабжа. Например на отсутствии наследования.

Например на отсутствии наследования.

Вот, кстати, да. Что там в русте с этим вашим ООП? :-)

Ну трейты сойдут за абстрактные классы... А, нет, не сойдут, в них же полей нету.

Вот, кстати, да. Что там в русте с этим вашим ООП? :-)

Если не ошибаюсь, на текущий момент с этим все печально.

Язык шаблонов C++ примитивен по сравнению с самим языков C++.

Некорректное высказывание. Шаблоны являются частью самого языка C++. Но я тебя понял, в принципе. Ты знаешь, «язык шаблонов» и не должен быть таким же, как и «сам язык С++». Это было бы глупо.

Тебе, видимо, незачем :-)

А тебе зачем?

Этого достаточно для обобщенного программирования.

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

Это пропаганда=)

вынесением объявлений методов за пределы определения класса

Мне вот этого, кстати, в Java не хватает. Из-за чего приходится возиться со скрытием/раскрытием блоков. Код на C++ в этом плане чище смотрится, не такие портянки.

Ну если же не намоделишь, тогда зачем C++? :-)

А что вместо него-то брать?

Если не ошибаюсь, на текущий момент с этим все печально.

И менять они, по-моему, ничего не собираются.

И менять они, по-моему, ничего не собираются.

Интересно, на чем основано это ложное мнение.

Мне попадалось что-то на тему «ненужно», т.к. трейты и имплы «лучше». Могу ошибаться, да. Если есть ссылки, то делись.

И менять они, по-моему, ничего не собираются.

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

Не приведет. Адепты метапрограммирования мыслят такими абстрактными категориями, что до сих пор ни одного хоть немного конкретного примера не родили. Одни только факториалы во время компиляции.

Не приведет.

Даже не сомневаюсь. Но вдруг.

Некорректное высказывание. Шаблоны являются частью самого языка C++. Но я тебя понял, в принципе. Ты знаешь, «язык шаблонов» и не должен быть таким же, как и «сам язык С++». Это было бы глупо.

Для тебя, пионэра, это высказывание некорректное. А для меня настоящая глупость - это воспроизводить разного рода взявки, не зная или недопонимая, о чём конкретно идёт речь, при этом, чванствуя, дуть щёки. :-)

Вот у меня есть пример: есть класс с кучей методов.

class Clazz{
  void methodA(){...}
  void methodB(ParamA param){...}
  void methodC(ParamB param1, ParamC param2){...}
}

Я хочу каждый метод выделить в класс. Вот так:

class ClazzmethodA{
  Clazz inner;
  void do(){ inner.methodA();}
}
class ClazzmethodB{
  Clazz inner;
  ParamA param1;
  void do {inner.methodB(param1);}
}

И т.п.

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

Это высказывание некорректно по определению.

// другой анонимус.

Даже если можно, то не нужно. Это вообще задача для IDE и пр. интсрументов, а не языка.

Если методы называются одинаково(т.е. просто перегружены, то можно).

Это высказывание некорректно по определению.

По определению колхозной бурсы с преподами-алкашами, или по определению филиала института мухосранска? Тогда да, некорректно. Это не пиво из бутыля сосать, тут думать надо :-)

Это вообще задача для IDE и пр. интсрументов, а не языка.

Решение с помощью Т4 для Шарпа очевидно. Но там есть свои неудобства, к примеру мне надо то же самое сделать не для классов в одном файле, а для реализаций определённого интерфейса(параметризованного), и в методе do вместо дерганья inner, дернуть fabrique.getExecuter<T>(). В таком случае либо намертво привязывать код к одному плагину для ms vs, либо выносить все классы в отдельную сборку и пользоваться каким-то фичастым builder'ом. Ну вот и почему темплейты/макросы не вариант?

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

class C1 { //... };

class C2 : public C1 { // ... };

//...

class C20 : public C19 { //... };

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

auto C1::method1(...) const -> T1 { ... }

// и т.д для большой иерархии из 20 классов

Это и есть та самая рутина, которая на ура автоматизируется макрами. Скажи вот мне, на кой хрен я должен утомлять себя этими идиотскими выносами методов из определений классов? А теперь давай представим ситуацию, когда объектная модель оказалась ахинеей версии 1.0 и встаёт задача рефакторинга этого говнокода в ахинею версии 2.0. И всё делается опять вручную. Взвяк про то, что это задача IDE, сам по себе уже доказывает ущербность языка программирования, его неспособность к расширению.

Даже если можно, то не нужно. Это вообще задача для IDE и пр. интсрументов, а не языка.

Смотри какой потешный пионэр :-)

Нельзя, потому что информация о классах недоступна во время компиляции. :-)

Давай лучше приведу пример не только из моей, но и из твоей практики цепепешника.

Давайте лучше из своей практики. Про мою вы ничего не знаете от слова совсем.

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

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

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

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

Сначала бы не мешало узнать, что такое «реальное программирование»? :-)

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

Не зная что такое «реальное программирование»? Так что же это? :-)

Сначала бы не мешало узнать, что такое «реальное программирование»? :-)

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

Абстрактные примеры вроде class C19 идут лесом вместе претензиями, что язык убог, потому что в нем есть hpp и cpp файлы.

А Scala не думают на рельсы LLVM ставить?

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

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

Кстати, в расте примерно так и есть.

Ну трейты сойдут за абстрактные классы... А, нет, не сойдут, в них же полей нету.

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

Для наследования что-то хотят сделать, кстати.

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

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

Чтобы быть продуктивнее, я стараюсь свою работу автоматизировать. Так кто из нас профессией ошибся? :-)

Абстрактные примеры вроде class C19 идут лесом вместе претензиями, что язык убог, потому что в нем есть hpp и cpp файлы.

Ну не буду же я копипастить свои корябки на цепепе сюда. Это ничего не поменяет в принципе. :-)

И менять они, по-моему, ничего не собираются.

Да ладно? Есть целая куча предложений на эту тему.

Ну вот я привёл пример решения реальной задачи - автоматизация рутинного определения методов иерархии классов.

Т.е. претензия к C++ сводится к тому, что в нем в ряде случаев сначала в заголовочном файле нужно сделать декларацию метода, а затем в файле реализации — определение метода?

И это пример той самой рутины, которую вам нужно побороть?

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

Название у этого языка есть? Или подразумевается одна из вариаций Lisp-а?

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

Что за задачами вы занимаетесь, в которых ваша продуктивность определяется скоростью дублирования заголовков методов из hpp в cpp файле?

Так кто из нас профессией ошибся? :-)

Вы вряд ли сможете быть настолько откровенны сами с собой.

Т.е. претензия к C++ сводится к тому, что в нем

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

И это пример той самой рутины, которую вам нужно побороть?

В качестве ещё одного примера дерутинизации, приведу auto и for (auto& e : v), которые ввели в c++11. Ты же понимаешь, что эти две конструкции ввели для удобства и краткости. Только всем цепепешникам пришлось ждать 28 лет до этого момента. В языке, где есть полноценные макры ждать бы не пришлось. В этом и есть главная претензия не только к цепепе, да и любому языку без средств метапрограммирования. :-)

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

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

Только всем цепепешникам пришлось ждать 28 лет до этого момента.

Нет, только ленивым и/или глупым, которые не могли найти (например) бустовый foreach. Почему-то я не удивлён, что ты в их рядах.