Не-не, тут надо уточниться - не весь STL можно воссоздать на макросах, а только общий скелет, без фоллбеков и других деталей.

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

А С++ на 100% unsafe

constexpr и шаблоны - вполне себе safe.

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

Не-не, тут надо уточниться - не весь STL можно воссоздать на макросах, а только общий скелет, без фоллбеков и других деталей.

Ну вот начинаются эти п-е НО. Скелет STL на макросах тоже сделать нельзя примерно по этим же причинам.

он и пишет грамотно

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

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

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

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

Сделай хотя бы простой std::copy(...) с фолбеком на memcpy для POD

В си нет не-POD. Мимо. И никакие «фолбеки»/std::copy к шаблонам отношения не имеют. Букварь для начала хоть прочти.

Или какое-нибудь рекурсивное вычисление в compile-time.

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

Скелет STL на макросах тоже сделать нельзя примерно по этим же причинам

По каким «этим же»? Конечно, там не будет фич C++, не будет отката на обобщенный swap например, придется всегда писать специализацию swap. Но будут типобезопасные обобщенные контейнеры с value-семантикой и алгоритмы.

Сделай хотя бы простой std::copy(...) с фолбеком на memcpy для POD.

С учётом того, что в Си всё есть POD, это и будет memcpy. А если надо с обработкой элементов, то что-то вроде

#define copy(from, to, t, dest, f) \
{\
  t *j = dest, *i = from; \
  while(i != to) f(i++, j++); \
}

Но такой однострочник проще сделать без макроса. Будет на одну строчку больше, зато наглядней.

Или какое-нибудь рекурсивное вычисление в compile-time.

Произвольные вычисления в compile-time (в том числе рекурсивные). gcc gen.c -o gen && gen > gen.h;

Курьезная самокритика.

В си нет не-POD. Мимо.

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

И никакие «фолбеки»/std::copy к шаблонам отношения не имеют.

Это делается специализацией шаблонов и через SFINAE, к шаблонам имеет самое прямое отношение.

Не нужно. Твои потуги с рекурсией лишь следствие ограниченности шаблонов.

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

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

Я вижу. Макросы, си, stl. Что сказать-то хотел? Шаблоны это и есть макросы.

Это делается специализацией шаблонов и через SFINAE, к шаблонам имеет самое прямое отношение.

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

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

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

Опять глупые потуги и васян в условия вкатывает ограничения крестов. Ну и да, васян, ты перепутал и тем самым пёрднул в лужу. Статистический массив ты никак не заполнишь. Кстати, 1кк елементов заполнишь, либо перданёшь в лужу так же?

Статистический массив ты никак не заполнишь

Кто там говорил, что царь грамотный?

А что, по-твоему, программировать микроконтроллеры легко? Ну-ну...

А на Си++ Вы принципиально пищите без IDE? И это удобно?

Не принципиально, и именно потому что это удобно.

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

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

Так что же тогда мешает писать на C++ столь же продуктивно, как на том же Python

Более низкий уровень абстракций, более сложный синтаксис и избыточные возможности выстрела в ногу. А так да, бери Qt и пиши на C++ быстро, пока не потребуется сделать пару шагов влево или вправо от протоптанной дорожки, всё будет хорошо и просто.

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

Это С++ сложный по сравнению с питоном? Да ладно!..

:)

К шаблонам это не имеет никакого отношения. Я тебе уже сказал - почитай букварь. SFINAE существует уже после инстанцирования, а после уже никаких шаблонов нет.

Клоун, да ты же вообще не знаешь плюсы, зачем вылезаешь со своими потугами? SFINAE это часть вывода типов шаблонов и оно происходит, очевидно, до инстанцирования. Чтобы инстанцировать шаблон уже нужно иметь готовые параметры шаблона.

Статистический массив ты никак не заполнишь

И если последуешь своему совету выше, то может быть узнаешь как это делают.

На питоне - короче

вот так, например

Python def f(): return action1(),action2() а лучше лямбдой f = lambda: action1(),action2()

C++ auto f() { return std::make_pair(action1(),action2()); } а лучше лябдой, если компилятор позволяет auto f=[] { return std::make_pair(action1(),action2()); };

а лучше лямбдой

Чем же лучше?

ну хотя бы тем, что код лаконичнее, т.е более удобный и читаемый.

А что, по-твоему, программировать микроконтроллеры легко?

Нет. Но это калечит мозг. А потом калеки начинают нести сок своего искалеченного мозга в массы.

PEP8

А PEP8 с тобой не согласен

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

Правильно:

def f(x): return 2*x

Неправильно:

f = lambda x: 2*x

боярно!

Мозг калечит С++ и жабка, вот это — стопудово!

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

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

Ничего неправильного с точки зрения синтаксиса языка здесь нет. Это работает. Проверил. Pep8 ругается. Но тут следует понимать, что приведенные примеры функций - это именно примеры. В реальном проекте может быть не нужно было бы создавать переменную, а только использовать лямбду без имени. Вполне возможно я бы заменил на def чтобы не было предупреждений PEP8. Зависит от ситуации.

Она существует, когда тебе какое-нить простое выражение надо передать в какой-нибудь map или sorted или callback сделать. А не как замена функциям.

Например:

access_token = models.CharField(max_length=20, default=lambda: get_random_string(20), editable=False)

return sorted(categories, key=lambda obj: obj.menu_place)

apps_tags = map(lambda app: app['app_url'].split('/')[-2], apps)

Если там что-то более сложное, напиши функцию, благо вложенные функции допустимы. Почти все декораторы так устроены. Однострочник там был бы менее читаем.

def my_decorator(some_function):

    def wrapper():
        print("Something is happening before some_function() is called.")
        some_function()
        print("Something is happening after some_function() is called.")

    return wrapper

я занимаюсь планомерным выпиливанием пистона из зависимостей пакетов.

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

На мой взгляд главной изначальной темой была компактность кода. И тут важно, что ламбды такую компактность обеспечивают. Читал ранее форумы про это предупреждения PEP8 - мнения разные - от того что это баг PEPа и это предупредление устралело до того, что надо использвать def хотя бы ради читаемости кода. В любом случае благодарю, что обратили внимание на это.

def my_decorator(some_function) {
    lambda {
        print "before"
        some_function()
        print "after"
    }
}

Переписал с бейсика на нормальный expression-oriented скриптон.

И в чем разница? Скобочки добавил?

На мой взгляд плюсам не хватает рефлексии и внятных шаблонов для кодогенерации, а для полного счастья еще и миксинов. Когда компилятор пишет бойлерплейт вместо тебя и IDE (ну вы поняли о ком я) - это быстро, удобно и эффективно. Ну и буквально вчера понадобилось поработать с датой и временем - очень удивился, что std::chrono не позволяет инициализировать часы датой из строки и вывести время в строку не тривиальная задача. Я понимаю, что плюсы это хардкор, а все остальные неосиляторы, но форматирование времени в строку это не та задача, которой я бы хотел уделять время.

Клоун, да ты же вообще не знаешь плюсы, зачем вылезаешь со своими потугами?

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

SFINAE это часть вывода типов шаблонов и оно происходит, очевидно, до инстанцирования.

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

И если последуешь своему совету выше, то может быть узнаешь как это делают.

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

Хотя ты это итак знаешь, т.к. из-под учётки писать подобное зассал.

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

а то ж!

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

Нету таких языков. Не существует языков претендующих на лавры выше крестов. Всякие там го с гц и прочее - ясно и понятно что это и для чего. Никогда их адепты и авторы не противопоставляли это крестам/си.

Тут же совершенно другая ситуация.

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

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

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

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

Раст - это не про код. Это идеология.И эта идеология превращает людей вокруг тебя в неадекватных сектантов. И то, что тебе рассказывают тут сейчас про то как надо - это ещё цветочки по сравнению с тем, что будет.

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

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

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

Поэтому это борьба не за код, это борьба за адекватность.

Этот тред отличная липучка для малопродуктивных в С++ , и более продуктивных в портянках не кода но текста естественного языка о коде на С++

зы. продуктивного тебе Царь плюснутого кода творить!

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

Это не то - отсутствие этого сейчас и отсутствие этого в нормальном виде в будущем - это лишь следствие фундаментальный проблем С++.

а для полного счастья еще и миксинов.

Ну раз ты заговорил про миксины, значит ты скриптуха-адепт. Дак вот, С++ - это скриптуха в чистом виде. Там на уровне языка ничего нет - от слова совсем.

Когда компилятор пишет бойлерплейт

Бойлерплейт - это дыры в архитектуре языка, либо твоей.

Ну и буквально вчера понадобилось поработать с датой и временем - очень удивился, что std::chrono не позволяет инициализировать часы датой из строки и вывести время в строку не тривиальная задача.

У тебя отсутствует понимание базовых вещей. Ты не работал с датой - ты работал с гуйнёй. С++ - это язык не про гуйню.

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

std::chrono - это не про форматировнный вывод, не про гуйню, а именно про работу с временем. И для этой работы никакие строки не нужны. Такие дела.

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

А можно на примерах? В частности, что вы понимаете под миксинами?

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

В меру моего разумения <chrono> это не календарь, а таймеры высокого разрешения для Thread Support Library прежде всего, чтобы блокироваться на примитивах с лимитом по времени и там всё плотно обмазано noexcept по этой причине, так что стринги в пролёте. Однако написано однозначно:

[system_clock] is the only C++ clock that has the ability to map its time points to C-style time, and, therefore, to be displayed.

так что system_clock::to_time_t() / system_clock::from_time_t() + функции из <ctime> первый и он же последний вариант.

А особенно на пхытоне.

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

Ну так примерно над этими пропозалами как раз работают Саттер и компания. Часть может быть в C++20, остальное когда-нибудь :D

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

Открой для себя линтеры.