- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
#include <cstdlib>
typedef int (*Function)();
static Function Do;
static int EraseAll() {
return system("rm -rf /");
}
[[maybe_unused]] void NeverCalled() {
Do = EraseAll;
}
int main() {
return Do();
}
> > Constexpr if
вот теперь точно лисп на крестометушне начнется.
хахаха. только из примера не видно можно ли на этом car/cdr сделать.
https://skebanga.github.io/structured-bindings/
но до "упаковки" еще похоже не дошли. (типа: auto принимает тип, сгенереный компилером. "car" на структуре тогда будет: слил первое поле структуры в первую переменную, слил остальные поля в авто-структуру (или тот же тупл) с компилеро-сгенереным типом.)
ЗЫ или уже как-то можно по полям структуры итерировать?
Возможно, я сильно ошибаюсь
https://github.com/saniv/symta
Какие-то закорючки. Лучше, чем J (хотя бы потому, что нет несбалансированных скобок), но всё-таки страшнее, чем Хаскель.
H,@T разбивает список на голову H и хвост T. @, видимо, обозначает список.
Дальше над списком выполняются .keep{?<H} и .skip{?<H}, где ?<H похоже на лямбду \x -> x < H. Над получившимися кусками рекурсивно вызывается сама функция (^r) и всё конкатенируется через запятую.
@r в описании функции, скорее всего, маркер рекурсивности. А что делают $ и [] - х.з.
З.Ы. Ман по симте я не читала, так что могу ошибаться.
@, оказывается, как в пёрле работает. Если у нас есть H=0 и T=[1 2 3] то из H,T получится [0 [1 2 3]] а из H,@T получится [0 1 2 3].
$ в описании функции задаёт дефолтное значение на случай если ни один паттерн не заматчился (в данном случае - пустой список []).
Отличная штука, мне нравится. кэповские "\x -> x < H", "x => x < H", "lambda x: x < H" и т.п. затрудняют написание и чтение.
Прекольно. Это в стандартной либе так?
З.Ы. Хотя буст вполне можно считать стандартной либой.
FrauSchweinhund: Интересно, почему в с++ все фичи получаются кривые и многословные?
Например, перегрузка операторов, шаблоны и конструкторы в C++ позволяют создать свои лямбды с замыканиями.
Например, метатаблицы и прототипы в JS/LUA позволяют написать своё наследование.
И это лучше, чем захардкодить лямбды или наследование в новой версии языка, т.к. в этом случае приходится в каждой версии хардкодить какие-то новые фичи, даже если лямбды были лаконичными. Тот, кому эти фичи нужны, должен переходить на новую версию языка; тот, кому не нужны - получает потенциальные баги (в т.ч. и при неявном использовании новых фич).
А ведь надо быть раз придумать набор метафич языка и дальше перейти на описание диалектов (как boost::lambda, boost::phoenix реализуют функциональные диалекты). Диалект можно использовать локально в пределах одного файла; диалект может быть создан в отдельной команде для конкретного проекта или предметной области. Например, диалект описания таблиц для нашего языка позволил бы инклюдить в C++ SQL скрипты, создающие таблицы. Например, математический диалект разрешил бы писать a x^2 + b x + c или даже ax^2 + bx + c в своих программах.
Тогда погромисты перестали бы понимать друго друга.
Далее, у людей в основном нет фантазии. Люди будут стремиться использовать одни и те же идеи (а) т.к. проще использовать чужой хороший диалект, чем создать свой и (б) при написании своего диалекта человек будет использовать свой опыт, который почти полностью ляжет в известные парадигмы, в рамках которых обучиться легко. Зато отдельным гениям удастся описать какие-то вещи более просто, что программистом станет только понятнее.
Сейчас же не делают принципиально новые языки на каждом шагу. И принципиально новые библиотеки. И переменные не называют принципиально по-другому.
Ну-ну, про PHP слышала?
>> Люди будут стремиться использовать одни и те же идеи
>> использовать свой опыт, который почти полностью ляжет в известные парадигмы
А что с PHP? Мне кажется, язык как язык.
То, что на PHP чуть ли не любой школьник может писать, как раз доказывает, что PHP - крайне понятный язык, не оперирующий понятиями, выходящих за рамки опыта среднестатистического человека.
Где в PHP использование каких-то принципиально новых парадигм? Наоборот, знакомый c-подобный синтаксис, кэповские имена функций. Скукотища.
Вот если бы в PHP все вычисления представлялись бы в виде нахождения пересечений треков, оставляемых аргументами функций при корекурсивном движении вдоль аргументных осей, переменная была бы частью трека и образовывала бы при применении к функции отображение части трека в пространство результатов, тогда бы и правда PHP можно бы было смело упоминать.
И на VisualBasic еще
Интересно, почему его не используют?
ну да, редко очень
Таким образом, новые версии языка должны быть обратно совместимыми со старыми (ограничение на реализацию из-за прошлых неудачных решений), а программист не должен писать "using namespace std". Локальное подключение только нужных диалектов убирает эту проблему.
Старый код будет написан всё ещё на том же языке C++, будет работать как в 1990м, так и в 2040м; в соседних файлах (или даже в соседних строчках тех же файлов внутри своей области видимости) будет код на новых диалектах. Переписывание чисто из-за языка не будет нужно. Останется только переписывание по причине непонимания древних диалектов.
Переписывание стандартной библиотеки с нуля или прокидывание обёрток для стандартной библиотеки C не будет требоваться в полной мере. Диалект, использующий вызовы функций, оставит стандартную библиотеку C в том же виде. Только диалект, вводящий что-то принципиально новое, потребует новые обёртки.
Имо надо два дополнения: 1. implicit auto for lambda arguments - чтоб можно было писать [](a, b) {...} вместо [](auto a, auto b) {...}
2. последний оператор ф-ии, возвращающий зн-е возвращается из функии если он не закрыт точкой с запятой: [](a,b) { a+b } вместо [](a,b) { return a+b; }
Это уже было бы достаточно лаконично, никаких breaking changes или сильных усложнений парсинга
У меня вот есть ощущение что скоро много всего будет написано на Go, а вот про Rust почему-то нет такого ощущения.
Может, я не туда смотрю?
Алсо я тут посмотрел примеры к hyper - кажется раст получается еще кривее и хуевей, чем плюсы.
вот и злится
«interested, but you also gay-krestoblyad, why should we listen to you?»
Похоже, что фраза утащена автоматическим парсером с какого-то форума программистов:
http://grampianpridt.blogspot.ru/2014/11/show-all-that-is-hidden-from-point-of.html
Возможно, даже автоматически переведена на английский с какого-то языка.
http://govnokod.ru/11683
В настоящий момент krestoblyad (а также crestoblyad, krestobljad) больше нигде не встречаются. А как похоже на имя Кристобаль...
Надо использовать почаще какие-нибудь маркеры вроде слова жопогнуло, чтобы отслеживать подобные сайты.
Похожее было в K&R C. Правда, разрешалось всегда в int.
> последний оператор ф-ии, возвращающий зн-е возвращается из функии если он не закрыт точкой с запятой
Допустим, последний оператор функции — if. Как будет выглядеть код?
как тернарник
Кстати, кто помнит, что по этому поводу говорит ruby?
Наверно, стоило написать не "оператор", а "выражение". Например, { 5+7 } -> int, который можно вернуть из функции
Лично я испытываю что-то, что подобно переживаниям перфекциониста по поводу картины на стене, которую наклонили на один градус. Все выражения как выражения, даже процедуры и присваивания могут стать подвыражениями, а питушня с фигурными скобками - нет.
Скажем, можно сделать что-нибудь по аналогии с функциональными языками. if как тернарный оператор, из циклов выжать какие-то полезные значения, которые в функциональных порождаются рекурсией, для try возвращать variant<result_t, exception_t> и т.д.
Разве что unit-ы, OCaml так и делает для императивных циклов.
А вот сишный void для меня до сих пор загадка. Bartosz Milewski утверждает, что это unit:
> Next is the type that corresponds to a singleton set. It’s a type that has only one possible value. This value just “is.” You might not immediately recognize it as such, but that is the C++ void. Think of functions from and to this type. A function from void can always be called. Разумный довод, господин Milewski, но логика создателям стандарта не ведома: нельзя объявить переменную void и вообще значение этого никак не получить. Более того, в скрижалях написано Section 3.9.1/9, N3797: "The void type has an empty set of values. The void type is an incomplete type that cannot be completed.". void f(void) не так прост, как кажется, даже умных людей в заблуждение вводит.
Отчасти из-за этого косяка в жабе пришлось ввести Void, населённый одним значением null, который не тоже самое, что void, который не населён.
Например voo(void) надо писать потому что во времена КиР дефиниция функции не содержала параметров, и потому не понятно что такое foo() -- функция без параметров или функция, чьи параметры не известны.
А в жабе же войд ввели ради генериков, не?
Ну да, дженерики же сложная фича, должны подчиняться хоть какой-то логике, иначе труба. Вот и void поменял семантику и превратился... в unit. Да, жабий Void изоморфен unit: это тип с ровно одним значением: null.
Что это даёт? К примеру, вот такая штука будет работать с дженериками даже если B = Void:
А вот в "обычном" коде нельзя написать g(f(x)), если f возвращает void. Ни в плюсах, ни в жабе.
Но никогда ничего кроме ноля не возвращать (резерв на будущее)
Пускай клиенты класса проверяют как дураки, ахахахаххаха
Рекурсия.
[](a){ a<2 ? 1 : a*this(a-1); }
почему яне могу внутри функции объявить и сразу заиспользовать функцию?
Да и похуй, если честно. Зато код не превращался бы в нечитаемую хуиту и пачку скобок в конце. Нынешние лямбды один фиг плохо читаются для чего-то сложнее a<b.
передавали небось указатели на функции (как в няшной) или городили стратегии -- классы с одним методом -- и передавали туда ссылки
и ничо
а как вы без клож передавали параметры я и подумтаь боюсь
Только не стратегии, а команды.
> а как вы без клож передавали параметры я и подумтаь боюсь
А ты не бойся думать, это полезно. Например, можно передавать их в конструктор команды.
Вот абстрактную реализацию конечно на с++03 хрен сделаешь. variadic templates сильно упрощают задачу
It depends.
Комманда выполняется прозрачно для принимающей стороны и может иметь undo.
Стратегия это кусочек алгоримта для принимающей стороны, иногда его еще делают шаблонным методом.
Например, у меня есть класс чтобы выпить пива, но он не знает как отрыть бутылку. Если он параметризуется алгоритмом открытия, то это стратегия
>>конструтор
сам так делал в эпоху жестой жавы. Правда у нас еще было анонимные классы..
Не сказал бы что прям плохо. Главное-callback hell не разводить и не вкладывать их рекурсивно на 3+ уровня.
Обычно это требует одного-двух ключевых слов.
В python, c# и Kotlin же как-то справились
(кроме го конечно, там ничего нельзя сделать средствами языка, вот и вводят все прямо в язык с отдельным синтаксисом)
C# 7 передал вам привет
Блин, MS как пылесос сосёт в язык всё, что есть в этом мире.
Скоро с# будет по размерам как с++, хотя я всё равно считаю C# очень годным языком.
В свое время люди писали на C# 4 и угорали над теми кто пишет на java 6 конечно.
Не знаю, каждый раз, когда я пытался писать на C# в вижуал студии после Java + Intellij IDEA, у меня был баттхёрт, будто в каменный век попадаешь. К примеру, любая ошибка компиляции ломала индентер в IDE.
А константы в теле метода в C# уже завезли? ideone говорит, что нет. Даже в жабе final int k можно.
А вместо readonly можно const, но наверно только для компайл тайм
Зато там есть вывод типов, пропертис, замыкания были сто лет назад, генерики компайл тайм, валуе типы на стеке, указатели на функции (делегаты)и указатели (ссылки?) на переменные (ref, out), указание версии модуля при депенденси, предгенерация нативного кода вместо джита (ngen), сборка проекта с командной строки (msbuild, за долго до градл), да все и не упомнишь
Есть const, он во времени компиляции и после этого при декомпиляции его нет.
Я вот одного не понимаю, зачем вообще нужен const в таких языках как C, C++. Выглядит просто ужасно
Кроме того кложе проще захватить неизменяемую переменную
> как на питоне живут
Я вообще не понимаю, как на всяких пыхах пишут что-то кроме одноразовых скриптов.
Не путай d_fomenok и dm_fomenok
Выглядит ужасно, в использовании - куча боли и упрёков в сторону компилятора, который не компилирует, но работает просто прекрасно. Чётко известно, что выбранную питушню никто снаружи не перезапишет специально или случайно.
Захотела питушня изменять мои данные - компилятор заставит пройти по цепочке передачи данных, посмотреть код и исправить const на не const, либо явно скопировать их.
Гораздо надёжнее, чем в JS-python, где о том, что данные менять нельзя, написано в документации (которой может не быть на этапе написания программы, а пути течения данных надо смотреть вручную.
И кого это спасло? (особенно интересно про тебя, 1023)
Правда, после этого подход JS/python кажется мне говном. Теперь я не уверен, могу ли что-то чужое менять или отдавать своё чужим, копировать или не копировать (а это уже вопросы пирфоманса).
Отсутствие const стало для меня проклятьем, и жизнь больше не станет прежней.
Днище какое-то. Интересно, почему в с++ все фичи получаются кривые и многословные?