- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
#include <iostream>
#include <map>
std::map<std::string, int> get_map()
{
return {
{ "hello", 1 },
{ "world", 2 },
{ "it's", 3 },
{ "me", 4 },
};
}
int main()
{
for (auto&& [ k, v ] : get_map())
std::cout << "k=" << k << " v=" << v << '\n';
return 0;
}
Follow us!
Переведите на "Java Script"
Именно поэтому я против «JavaScript».
const obj = {'hello': 1,'world': 2,"it's": 3,'me': 4};
Object.keys(obj).forEach((key) => console.log(`k=${key} v=${obj[key]}`));
Туда ли ты зашёл, скриптушок?!
В случае вопроса, обращенного именно ко второму лицу, "t" не нужно.
Именно вопроса
Именно к "ты/вы"
Именно предшествования глагола существительному je.
als je een haan bent, stop je niet met kraaien
stop, не stopt
а это бывает не только в вопросах?:)
я еще туда не дорос
nu ben je een eend
У нидерландцев странновато звучат стечения звуков «sj» и «tj». Складывается впечатление, что они хотят произнести «ш» и «ч». Чем-то напоминает мутацию «си» и «ти» в японском.
P. S. В «als je» тоже наблюдается этот артефакт звучания.
alsjeblieft -- алщеблифт -- пожалста
meisje -- мейше -- девочка
А tj это ч
То есть все как-бы немного свдигается вперед
"je" это еще и уменьшительно-ласкательное, и я часто их слышу
kaart -- карта
kaartje -- карточка (карче).
Собссно, девочка тоже уменьшительное (потому она кстати het, хотя и не среднего рода)
У шведов ещё забавнее: sj читается как «одновременно звучащие [ш] и [х]». Именно так этот звук описан во всех учебниках.
https://forvo.com/search/sju/sv/
по ссылке я слышу мяхкую "х", типа "хю".
Тут таких нет, но звук "сх" они любят, и часто он там, где у англичан "sh" (пишется он как "sch")
schaap (схаап -- овца)
schip (схип -- корабль)
schoen (схун -- башмак)
school (схоол -- школа)
Какой халяль)))
Лыжи у немцев будут «ши». Иногда пишут чисто по-немецки (Schi), а иногда в орфографии того языка, из которого позаимствовали это слово (Ski), но читают всё равно «ши». Вроде больше нигде «sk» у немцев так не читается.
***
Кстати, на конце слов в sch нидерландцы теяют ch, поэтому Иеронима Босха современные нидерландцы зовут Бос.
У немцев противоположная тенденция: они даже заимствованное из греческого Scheme читают как «шемэ». Более того, слово «шизофрения» — это искажённое немцами греческое («схизо» = «расщепляю» в переводе с греческого; у греков нету инфинитива). Вот уж насрали в вечность...
spin -- паук
spelen -- игарть
overstappen -- пересадка
Тут везде и не "c" и не "ш", а нечто среднее, и зависит от того, кто говорит.
Но потому что глухая согласная идет следом.
Если звонкая или гласная, то "s"
snel -- быстрый
sinaasappel -- апельсин
slaapen -- спать
тут везде чистое "c"
>Это хмл который служит для преобразования одного хмл в другой хмл и сам при этом хмл
Ммммм.
Мысль.
На самом деле XSLT, по задумке очень годный. Функциональный, тьюринг-полный.
Минус: он очень громоздкий (ибо xml).
Потому любая композиция примитивов средствами языка выходит более громозкой чем обычная копипаста.
В нём единственная структура данных это массив.
хорошо.
В С++ уже много лет как сделали «сборщик мусора», называется «RAII» и «умный указатель».
Но при этом сами не умеют нормально и детерменированно освобождать ресурсы отличные от памяти.
Отсюда проблемы с незакрытыми коннекшнами, стримами. И всякие конструкты вроде try-with-resources.
Действительно, если есть AutoCloseable.
https://docs.oracle.com/javase/8/docs/api/java/lang/AutoCloseable.html
Причём особый багор, в и тут всё опять сделали через жапу.
try-with-resources (сахарок), конечно прикольно.
Но он не работает с такими вещами как Lock или мьютекс.
Там по-прежнему нужно писать finally и делать release руками, как в старой-доброй сишке.
Ээээ
https://github.com/JetBrains/intellij-community/commits/master/platform/util/src/com/intellij/openapi/Disposable.java
Commits on Aug 28, 2009
В 1.5 был просто Closable.
https://docs.oracle.com/javase/6/docs/api/java/io/Closeable.html
Проблема что он не был прикручен к Connection и другим нужным классам, где были методы close.
Помню как мне это надоело, я написал метод, и тупо вызывал close на объекте рефлексией.
>Джависты, почему всё через жопу?
Жопа. Жапа. Жава.
Счётчик ссылок принято считать особой формой сборщика мусора.
Например в CPython счётчик ссылок это основной сборщик, а tracing (https://en.wikipedia.org/wiki/Tracing_garbage_collection) запускается иногда только для сборки островков циклических ссылок.
Garbage collection is the process of runtime monitoring the life-time of objects and freeing them once they are no longer necessary. There are two main approaches to garbage collection: tracing [28] and reference counting (RC) [17].
Tracing garbage collection maintains a root set of live objects and finds the set of objects reachable from this root set. Objects not reachable from the root set are considered dead and their resources can be freed.
RC garbage collection, on the other hand, maintains a counter for each object, which tracks the number of references currently pointing to the object. This counter is actively updated as references are added and removed. Once the counter reaches zero, the object can be collected.
Это самый простой и широкораспространённый тип.
И лично я выделяю его в отдельный класс.
Этот gc присутствует и в сишке, и алголе.
Он замечательно работает, пока программист не начинает вызывать *alloc.
У царского gc потрясающая скорость (указатель стека обычно двигает процессор), детерминированность, отсутствие задержек и фрагментации.
Уже лет 10 как в x86 есть move elimination, zero idiom elimination и stack engine.
Такие операции как mov; xor eax,eax; push и pop, просто выпиливаются не доходят до портов исполнения, даже не превращаются в МОПы.
Sandy Bridge recognizes instructions such as XOR, PXOR, and XORPS as zeroing idioms when the source and destination operands are the same. Those optimizations are done at the same rate as renaming during renaming (at 4 µOPs per cycle) and the architectural register is simply set to zero (no actual physical register is used).
x86 has dedicated stack machine operations. Instructions such as PUSH, POP, as well as CALL, and RET all operate on the stack pointer (ESP). Without any specialized hardware, such operations would would need to be sent to the back-end for execution using the general purpose ALUs, using up some of the bandwidth and utilizing scheduler and execution units resources. Since Pentium M, Intel has been making use of a Stack Engine. The Stack Engine has a set of three dedicated adders it uses to perform and eliminate the stack-updating µOPs (i.e. capable of handling three additions per cycle). Instruction such as PUSH are translated into a store and a subtraction of 4 from ESP. The subtraction in this case will be done by the Stack Engine. The Stack Engine sits after the decoders and monitors the µOPs stream as it passes by. Incoming stack-modifying operations are caught by the Stack Engine. This operation alleviate the burden of the pipeline from stack pointer-modifying µOPs. In other words, it's cheaper and faster to calculate stack pointer targets at the Stack Engine than it is to send those operations down the pipeline to be done by the execution units (i.e., general purpose ALUs).
Сколько пафоса вокруг очевидной идеи про три сумматора, даже имя дали... Поди ещё и запатентовали, чтобы конкуренты не могли юзать?
Какой некробамп )))
Там прикол в другом: как Штеуд элегантно додумался совместить переименование регистров OoO с mov.
А также неявно завёз концепцию нулевого регистра из RISC.
Ведь по сути все идиомы обнуления просто переименовывают операнд в этот немутабельный, забитый нулями регистр.
Внутри x86-64 стал ещё больше RISC чем быдл до того.
Давай станцуем бамп!!
Это как если бы я всё время забывал ключи, и вскрывал замок спичкой, а потом выпустили бы специальный замок со спичкой вместо ключа, потому что я уже привык
В программировании вообще часто так бывает
https://static.life.ru/posts/2017/12/1072282/f073668938eb7407cb323ce4e3fe4f1c.jpg
Захiдный поток!
1. Пишут слово «ХУЙ».
2. Вокруг него прибивают доски.
Аффиный Давид.
https://en.wikipedia.org/wiki/Affidavit
https://cppinsights.io/s/5d09f938
https://pastebin.com/JyXBFQex
В M() по два ненужных copy, в Ms() по одному, добавление move() не убирает copy, только лишний move даёт. Лишние copy не убираются. (может make_pair, сейчас попробую...) При этом при инициализации пары в p() тоже ненужное copy, но в pm() оно успешно меняется на move (вероятно потому что это не initializer list, а brace initialization).
Для пирфоманса остаётся делать так: https://wandbox.org/permlink/gCLMiBxrOJlepLGN (лишних копирований нет, move-коньструктор для STL-контейнеров — O(1) операция без аллокаций).
И да, делать std::move() в местах, где будет RVO/NRVO, не надо: https://developers.redhat.com/blog/2019/04/12/understanding-when-not-to-stdmove-in-c/.
Удваиваю!
>хипстеры не пишут на «C++»
Это один из самых весомых аргументов в пользу «C++».
Когда нужно использовать какую-то фичу языка, и она не работает, программисту говорят, что виноват в этом он, и надо было читать вон те 300 страниц стандарта. Потом ему как маленькому ребёнку объясняют, в чём он не прав, и почему фича (точнее, баг) языка работает не так, как он ожидал. Рассказывается история языка и его "принципы".
Когда человек говорит, что фича-то новая, и можно было её сделать как надо, ему отвечают, что он ничего не понимает, и вон те, те и те условия вынудили сделать так, и вообще, если бы сделали как надо, эта фича конфликтовала бы с ещё какой-то старой питушнёй.
При попытке сказать, что питушню можно было выбросить или просто исправить, крестухи затыкают программиста и говорят, что кресты поддерживают совместимость. Им отвечают, что её и так всё равно уже сломали в случае вон с тем изменением. Крестухи тупят взор и говорят, что это вообще несравнимые понятия, и там было абсолютно другое дело.
В логике есть понятие следования. Из истины следует истина, а из лжи - всё, что угодно. Обратно, если последовала истина, значит на входе было всё, что угодно, а если последовала ложь, - то на входе была ложь.
Соответственно, если новая фича вышла говнистая, и это следует из принципов языка, значит принципы языка - говно и нуждаются в замене. Но крестухи считают наоборот. Стандарт непогрешим, свят и бесконечно правилен, а противоречия и следование из него говна - лишь надуманное кукареканье неподготовленного питузка, который должен наискорейше изменить свои мышление и систему ценностей, чтобы стандарт выглядел там логичным.
move-семантику (поглощение кишков других объектов) в кресты запилили чисто ради пирфоманса.
Иногда она не срабатывает. И программа работает чуть медленее.
«JS» и «пирфоманс» — оксюморон.
Код на JS выглядит абсолютно не так, как на остальных языках, те же вещи выглядят сложнее.
Для борьбы с асинхронностью создаётся лапша коллбеков, промисы. Разрабатываются новые парадигмы и библиотеки, в язык впиливают генераторы и новые ключевые слова.
Код всё равно не становится таким же понятным, как в других языках, и новые конструкции - лишь сахарок над нагромождениями абстракций, призванных бороться с асинхронностью. То есть если что-то не сработает на уровне "async/await", программисту придётся спуститься на уровень генераторов, потом на уровень промисов, потом на уровень коллбеков. Только знаний async/await не хватит, для написания реального кода потребуется быть коллбековедом.
Аналогично с {}. Фича могла бы работать как надо, но из-за наслоений говна не работает, что выдаётся за правильное поведение.
Крестухи кмк делают важное дело.
И мне очень хотелось бы увидеть подобные питумизации в high-level языках с gc.
Для начала в том же хацкеле с принудительной иммутабельностью. А потом и во всяких jvm, v8 для COW.
Вместо бесконечного копирования при мутациях, ghc мог бы определять что исходное значение не используется, мутировать тот блок памяти и возвращать его.
Экономия на копировании и сборке.
Мув-питушня - дело интересное, но уж лучше бы она была автоматической. А то ты один раз забыл что-то дописать, и потом у тебя вся программа испортилась.
С введением мув-питушни увеличились количество категорий значений. Раньше было логично - питушня, у которой есть интересное для нас значение (rvalue) и питушня, у которой есть интересный для нас адрес (lvalue). Это хорошо мапится на внутреннюю структуру. Каждый, кто писал свой интерпретатор для простого языка с арифмопитушнёй и присваиваниями, автоматически и логично дошёл до темы lvalue и rvalue: некоторые особенные операции требуют помещения в стек адреса, а не значения.
В современных крестах теперь 100500 неочевидных категорий значений и кобенаторно большее число кобенаций эффектов от их взаимодействия. Как трёхмерная таблица типов для арифмушни в JS.
Пачку конструкторов добавили. А это уже в некотором смысле дублирование кода. Если класс поменялся, нужно менять не только все конструкторы (или, хм, в новых версиях разрешили переиспользовать конструкторы, не помню?), но ещё и дополнительный спецконструктор. Забыл это сделать - у тебя объект правильно создастся, правильно скопируется и неправильно переместится. И из-за вороха правил о том, когда какой конструктор выполняется, баг будет вылезать в неочевидных местах.
Как я понял никакого бага не будет. Там везде no leaks.
Просто компилер не сможет сделать RVO и лишний раз кишки скопирует.
Плюс вызовет констуктор для нового и деструктор для старого, уже не нужного.
Описанная мной питушня происходит при модификации класса, у которого уже есть конструктор копирования и конструктор перемещения.
Не укажешь конструктор перемещения - код будет недостаточно царским, иногда будет тормозить.
Укажешь конструктор перемещения - надо его поддерживать, а так как код царский, абстрагироваться не получится (из-за пирфоманса), будет два конструктора, которые почти такие же, но с различиями, которые оба надо будет поддерживать.
Со стороны параши более высокоуровневых языков, в которых про все эти байтики и копирования не думают и текут — возможно. Для какого-нибудь сишника следить за копированием/перемещением/удалением — вполне себе норма.
а) создают кучи говна на куче и гоняют только ссылки
б) при копировании и херинге исходного объекта обычно никогда и ничего не оптимизируют, а тупо плодят новые объекты, а gc потом соберёт старый. По сути те же самые конструктор+деструктор
Плюс там в общем случае констукторы/деструкторы с непонятным содержанием. Они могут закрывать ресурсы и открывать их снова.
Но реально это сверхоптимизация, чтобы не копировать даже пару байтиков.
Следить за копированием/перемещением/удалением - полезно, кто-то это обязательно должен делать. Лично я - за то, чтобы это делал компилятор, т.к. он может посмотреть на программу целиком и понять, где что надо делать, а у программиста будет регулярный код в терминах бизнес-логики, а не в терминах вынужденного байтоёбства.
Но деструктивное конструирование не перестанет от этого быть оксюмороном. Два миллиона евро плюс два миллиона евро - это четыре миллиона евро, не важно, человек зарабатывает миллион, тысячу или сто евро в месяц.
Универсальное решение, когда «программист» просто говорит конпелятору «сделай заебись», а конпелятор делает максимально быстрое, удобное и безопасное «заебись», бывает только в мире розовых пони и сильных ИИ. А наш мир, увы, несовершенен, абстракции текут, поэтому компромисс между скоростью разработки, высотой абстракций и скоростью выполнения будет существовать всегда.
> конпелятор делает максимально быстрое, удобное и безопасное «заебись»
Притом что крестокомпилятор и так изо всех сил оптимизирует.
И программист обычно на это не смотрит, пока профайлером не выяснит что оно мешает.
В наибольшей степени это заслуга закона Мура, чем развитием компиляторов. 30 лет идея программы для обмена сообщениями, занимающей гигабайт оперативы, звучала как несмешной анекдот. Но закон Мура упёрся в физику и более не работает. Так что увы.
Ещё немного осталось потерпеть. Скоро туда structы завезут.
Не бог весть что конечно. Но легковеснее чем обычные объекты.
>типа этакий валуё обжект?
Да. Если структы равны, если все поля их равны. Типа memcmp
https://openjdk.java.net/jeps/169
There are optimizations which can eliminate object allocation in some regions of code. For example, objects can sometimes be "scalarized" into their component fields, if an escape analysis can be successfully carried out. However, such optimizations are limited in scope and applicability. For out-of-line calls, objects must still be boxed into memory, as long as existing Java reference semantics are enforced. Without new rules relaxing reference semantics, local escape analyses cannot be relied on to remove boxing overheads from objects, no matter how similar they are to primitive types.
Раньше у компьютера не было времени, чтобы выполнить царскую программу, и она тормозила как по причине слабого железа, так и по причине недостатка автоматической оптимизации, а теперь у него есть время на эту самую автоматическую оптимизацию. Автомат может потратить время и из некоторого набора анскильных программ сделать царские, которые будут выполняться быстрее и при более долгом времени работы получат меньший оверхед.
Наконец-то анскильные отбросы перестанут писать своё bloatware как попало.
Ибо я думал что процесс раздувания софта уже никак не оставить. Поскольку будут появляться всё более мощные компьютеры, способные его переварить.
В итоге у нас появляется тот же самый по функицоналу софт, но чудовищно обросший свистоперделками.
Нет.
1. Новые тех. процессы уже не делают транзисторы дешевле, т.к. требуют экспоненциального увеличения числа масок.
2. Число производителей осваивающих новые тех. процессы сократилось с десятка до двух (samsung, tsmc).
3. У великого и могучего штеуда дикие проблемы с новыми тех. процессами. Из-за этого фактически пятилетняя стагнация на рынке десктопов.
Если бы не АМД, мы бы до сих пор видели очередной i5-100500 с 4мя ядрами за те же 200$.
>у меня 16 виртуальных цпу
Разве что виртуальных. Типа SMT.
Лет 20 назад компушню десятилетней давности встретили бы обмороком от удивления.
> появляется тот же самый по функицоналу софт, но чудовищно обросший свистоперделками
Иногда - даже хуже по функционалу.
Тебе подкинули гигабайты памяти, гигагерцы, экраны получше, а ты отрисовываешь меньше кнопок, меньше текста, работаешь медленнее и тупее.
ИЧСХ на российском рынке из недорогих будут модели с 6ГБ, за аналог 1000 долларов у половины будет 8ГБ.
Хаха. 11 лет это очень много. Спасибо физическим барьерам и частотному потолку.
Вот в 90х и 00х компы устаревали со скоростью света, буквально за 2-3 года.
А видеокарты и того быстрее. Помню купил середнячка, поиграл немного, а там смотришь, у тебя уже говно старое.
И свежая винда тогда выходила каждые полтора-джва года. 95/98/98 SE/Me/2000/Xp. Просто голова кружилась.
Это 90е и первая половина нулевых, пока интел не упёрлась в 4 ГГц и огромное тепловыделение. А MS не начала пилить висту.
>Третий пень 1999-го года выпуска вполне мог работать в 2005-м.
Да. Третий пень был годнотой, ибо первые P4 были тупым говном, которое P3 сливал в хламину.
И в 2004 у штеуда были трабы с 90м тех. процессом.
Хотя, соглашусь, что универсального подхода не существует.
Доооо.
На 4 гигабайтных кучах задержки бывали по 5 секунд. Это очень неприятно.
Как только в компилятор встроят сильный ИИ — он сразу же и будет смотреть на всю программу целиком. А пока что либо всё в куче и копируется, а-ля жаба, либо всё ручками.
Деструктивное конструирование, оно же конструирование при помоще move-конструктора — вполне себе нормальный термин (хоть и придуманный мной, да). Вот есть у тебя объект X, ты хочешь из него сконструировать объект Y (Y := X). На высоком уровне абстракции тебе действительно похуй, как оно там всё будет, главное, чтобы результат был. А как только эта операция начинает выполняться сотню миллионов раз в секунду — тебе сразу хочется, чтобы во время неё не было никаких лишний копирований или аллокаций. И тут уже приходится задумываться, где там у тебя что копируется, где перемещается и как используется.
Logical error.
О каких миллионах речь?
Обычное для скриптухов дело — сайты с 38ю записями.
[придумайте продолжение]
>> У клинтуха по сравнению с диким сизарём окрас более монотонный, со слабо выраженными полосками на крыльях и без белого пятна на спине. Если снизу посмотреть на взлетающую птицу, то можно увидеть, что испод крыла серый — значительно более тёмный, чем у сизого голубя и вяхиря, и по тону почти не отличается от такого же тёмного брюха. Вяхирь выглядит гораздо массивнее остальных двух видов, и к тому же выделяется белым пятном на боках шеи. На груди клинтуха развит розовато-винный оттенок, более ярко выраженный, чем у сизого голубя, но занимающий меньшую площадь, чем у вяхиря.
Боюсь, что я тоже сходу не отличу. А с учётом того, что у обычного сизого голубя есть куча культурных пород разных окрасок, которые одичали и скрестились с дикими, задача определения вида становится непростой.
Это да. Но вот только в скриптушне он будет смотреть на программу как на говно и оптимизировать направо и налево, а в крестах - программа будет смотреть на него как на говно, и всё, что он сможет выдать - пачку ворнингов вида "программист, это ты серьёзно или ошибся?"
Неа.
Опять ошибка.
В скриптушне у него будут дикие проблемы с неясными типами.
То ли флоат, то ли инт. Гадай, оптимизируй.
См. начало http://lib.ru/FOUNDATION/question.txt.
Только ответ ИИ может быть очень неожиданным.
Мы когда-то с wvxvw это здесь обсуждали.
ИИ может дать ответ, который люди просто не поймут. Типа вореции поехавшего.
PS Концовка рассказа эпична.
Да, рассказ охуенен. Причём в оригинале, ИМХО, даже круче: https://www.multivax.com/last_question.html.
Я, кстати, за «Wolfram Alpha»: https://www.wolframalpha.com/input/?i=Can entropy be reversed%3F.
https://www.youtube.com/watch?v=YCIptc12bmU
И вот прошло много много лет. и доктор стоит перед вратами рая . а на встречу ему выходит бог в синей олимпийке и говорит- Привет Юрий Генадьевичь а ведь тогда не поверил мне....
Если конпелятору докинуть вычислительной мощности и памяти, он увидит весь код целиком. С программистом так поступить нельзя.
Например, стык библиотек. В одной инты, в другой флоаты, программе нужны даблы.
Или всё то же проектирование. Раньше думали, что нужны инты, теперь понадобились даблы. Переписывать целиком долго.
У оптимизатора скриптушни развязаны руки - он может как навредить, так и помочь.
Зависит от мощности анализатора. Если, например, там делается много округлений или печатается целое число, можно догадаться, что нужен целый питух.
> компулятор взял, и сделал везде дабл. При этом в 99% случаев нам нужен int.
А вот так ведь и сама сишка делает, правда только локально. Если в выражении затесался флоат, всё зашкваривается в плавучку.
Если же он пишет шаблон, всё ещё больше усложняется. Приходится работать в области классов типов или концептов, выделять общие операции, думать про perfect forwarding. Если писать фиксированный код, он будет сильно тормозить для неподходящих типов. Если писать шаблонный код, он будет понемногу тормозить для некоторых типов, надо будет специализации писать.
Ну вот я ожидаю, что в C++ при инициализации временными объектами не будет никаких копирований или перемещений. Объекту указывают на шконку поле, на котором он будет вызывать свой конструктор. И всё.
Копирования/деструкции/перемещения вовсе не должно быть, если инициализация - первое и последнее использование переменной, и тем более, если это анонимное выражение.
Так и только так должно быть в языке, где важен перфоманс.
Ну и да, основная проблема initializer_list в том, что его разработка велась одновременно с move semantics, и последнюю не учитывала. А потом стало поздно фиксить, Комитет решил, что это несущественно… Ну, короче, как всегда виноваты люди.
Это означает всего-лишь что вызывается деструктор старого объекта (аналог: собрал gc) и конструктор копии.
В данном случае мы переиспользуем старый объект, о котором известно что его отправят на свалку.
И повторюсь: мне хотелось бы видеть использование такой методу за пределами крестов.
Например оптимизацию немутабельной мутабельности (ещё один оксюморон) в хацкеле.
Именно поэтому я за кресты, где все ресурсы равны.
>https://govnokod.ru/26439#comment528165
В CиПитоне сборщик на счётчиках ссылок, они дескриптор закроют сами, как только он не нужен.
Счётчик ссылок собирает очевидное говно, а круговую поруку собирает уже tracing gc как в жабе.
Если файл открыли прочитали и вышли из метода, то питон его закроет, т.к. не осталось никиаких ссылок.
Проблема в том что такое решение непортируемое в другие реализации питона на яве/шарпе (jython и ironpython). Т.к. там анскильные gc без счётчиков.
Ух, бля.
Я даже боюсь представить, как это всё насилует память и сколько терабайт там выделяется-освобождается каждую секунду.
Проверил
https://www.jython.org/news
Jython 2.7.2 beta (v2.7.2b3 February 2020)
A further beta release is now available for Jython 2.7.2 at Maven Central. It is built and tested with Java 8 and tested against Java 11. This fixes bugs raised in response to v2.7.2b2 and updates certain JARs. Although past predictions of releases have not been very reliable, we predict a release candidate in the week beginning 24 February.
А вообще я почитал про него, кстати. Пишут, что оно нужно для быстрой интеграции с джавакодом; в частности, там вместо питоновских пакетов используются классы «Java».
Но это было 10 лет назад.
Уж лучше взять скакалку или котлин.
Таким должно быть всё.
Язык - это питушня для высказывания мыслей, а не жёсткая реализация. Пусть будет больше возможности высказать свои мысли.
Может быть, я хочу программировать веб страницы на сишке со сборкой мусора, а прошивку писать на питоне с ручным управлением памятью.
Т.е. детерминированности, по факту, никакой.
Питушня. Это уже возня с побочными эффектами. С памятью ладно, там из побочных эффектов только недетерминированность malloc() == NULL, а тут может закрыть слишком поздно, а может - слишком рано.
Может быть, программа хочет, чтобы файл был открыт, пока она жива.
Компилер выдаёт ошибку если код обращается к объекту без кишков.
https://yoric.github.io/post/rust-typestate/
> оптимизацию немутабельной мутабельности (ещё один оксюморон) в хацкеле
Тут вообще из-за прозрачности ссылок у компилятора все карты на руках.
Такая питушня может прийти вместе с оптимизацией хвостовой рекурсии как обновление компилятора, а не как новая конструкция с новой философией, 50 оттенками rvalue, новыми конструкторами, амперсандами, хинтами и багами.
Да. Именно об этмо речь.
Но почему-то они пока не сделали такое. А разгадка проста: Хаскель-отребье, как и всякое другое отребье не может ничего родить. Оно может только воровать, врать и соревноваться с инвалидами. Очевидно, что с реальным си++ они соревноваться не могут.
В хаскелях всегда есть возможность соптимизировать старое говно, которой можно воспользоваться в любой момент. Решение существует, пусть всё продолжает гореть.
Это всё красиво звучит только на бумаге. Почему такой питумазции ещё нет?
А пока такой оптимизации нет на практике — хацкелисты анскильные отбросы.
>У крестушков, если не изменишь язык, у компилятора останутся связаны руки. Надо действовать.
В жабе вот тоже люди чухали голову и пришли к выводу что нужно менять язык.
Хотя казалось бы: уровень абстракции куда выше.
It is difficult to work with vector values from Java because they cannot be directly represented in Java code without creating a temporary object. A mutable object (often an array) can be created to hold the components of such a vector value, but this is merely a workaround, which does not qualify as direct representation of the value, since the same object will (in general) successively hold a series of values. Alternatively, an immutable object can be created, which qualifies as a direct representation, but each new value requires creating a new object. The costs are often high enough to discourage programmers from using the direct representation.
Посоны прямым текстом говорят: немутабельность это дорого.
Ну и вообще, как мне кажется, хаскели - площадка для вкидывания идей. Нормальный язык не должен возводить какую-нибудь питушню в абсолют, иначе он становится неюзабельным. В хаскелях нельзя написать hello, world без спецзнаний в хитрых областях математики. Не говоря уже о дебаге принтфом, для которого нужно одно-два высших образования.
В жс красиво поступили с иммутабельностью строк. В итоге мы наблюдаем эффекты как линеаризации квадратичного кода (str += 'x';), так и хранения старой питушни (a = pituz.substring(10e6, 10e6+1)). И в целом оптимизация неплохо справляется с идеей иммутабельности.
It should be emphasized that place-oriented programming in Java is an anti-pattern, because it blurs the correspondence between Java variables and application values. If a value is implicitly defined by being stored in two or more Java variables, there is no way to work with it directly as as single variable, method argument, or return value. The programmer is required to manage aliasable "places" to store the value components, as well as the values stored in them. Any optimizing compiler is hard-pressed to distinguish the two.
Local escape analysis could be extended (with heroic efforts) to interprocedural escape analysis, allowing methods to pass object fields in registers, delaying object creation perhaps indefinitely. Without new rules for permanently locked objects, the existing rules for field mutability and object identity tracking would require complex, probably unworkable, additional data to be passed between methods along with the object field values.
We could add new explicit tuple types to the JVM, providing a more explicit third option between classes and primitives.
Так можно тоже самое сказать о ECMA-скриптерах.
Для новых фич языка, типа деструктивных присваиваний жскриптухи вводят полностью новый синтаксис.
А в крестах посоны делают новый вызов.
https://godbolt.org/z/RRmruC
В крестах у компилятора всё так же будут связаны руки, в скриптушне - всё так же развязаны.
Вся суть C++. Взять понятные термины и наговнякать поверх них какую-то питушню.
Если был простой и понятный pitux, он станет "std::pitux".
Можно добавить строку кода "using namespace std" и писать "pitux" вместо "std::pitux". Но оказывается, что "std::" сделано для того, чтобы можно было любое говённое именование в будущем объяснять "ну у нас же std:: стоит, что вы так кричите".
Даже если импортировал питуха как "using std::pitux", намучился с "template <Type, Allocator> using std::pitux_vector" (который появился не так и давно по меркам C++) и избавил все символы от богомерзкого std::, оказалось, что после переписывания кода сверху остались лишние using std::pituz и using std::petix, которые никому не нужны, но никто об этом не знает.
Люди читают код и без штудирования всех using не понимают, это просто какой-то отсебяшный pitux или гордый std::pitux.
Чтобы не было лишней мороки, пишешь везде std::pitux. Код увеличился вдвое. Простая формула становится адом. E=mc^2 занимает три строки из-за обилия std::swimming_pituz, static_cast<std::swimming_pituz<32>>(std ::pituz_energy()) и std::pituz_square<std::swimming_pituz<32 >>.
::pitux ?
https://ideone.com/vXNpTg
Я не адепт крестов, но со стороны ваши набросы на С++ выглядят нелепо.
Люди обсуждают move-семантику, и удаление лишнего копирования.
А вы возводите несработавшую оптимизацию в разряд вселенской ошибки.
Кстати, именно поэтому я обычно никогда не лез в С++ срачи. Поскольку я крестов не знаю и меня в них быстро сольют.
И тут оказалось, что std::inipitulizer_pituz вызывает какие-то копирования.
> возводите несработавшую оптимизацию в разряд вселенской ошибки.
В статье из-за этого код не скомпилировался.
> Кстати, именно поэтому я обычно никогда не лез в С++ срачи. Поскольку я крестов не знаю и меня в них быстро сольют.
Иногда полезно взглянуть на проблему со стороны. Один раз сольют, второй раз сольют, а в третий раз осознают, что им говорил человек с незамыленным глазом и выберут другой язык для программирования. Но там будут свои питушни, и свои сектанты.
Кресты, как и другие языки, вызывают привыкание. Иногда стоит представить, как бы пришлось объяснять кресты обычному человеку - скажем, бабушке или психиатру, который ещё не решил, здоров ты или нет. И тут сразу всплывают все эти острые углы и нелогичности, которые ты на автомате обходил и считал нормальными. А то иначе - всё нормально и логично. Святой стандарт и чёткие из него следствия.
Ошибка компиляции — наименьшее из зол, которые могут приключиться с программой.
Я понимаю что в js можно писать как угодно и никто ругаться не будет. А код ёбнет уже потом, при выполнении.
>вызывает какие-то копирования
Эти копирования и деструкторы — пыль, по сравнению с тем какие кучи мусора вычищает gc за скриптушачиьм говном.
Тут люди вообще всё по стеку двигают.
Да. escape analisys в 6ой яве появился экпериментально.
Я тогда его включил, получил просадку пирфоманса.
В 7ой вроде допилили, но я не проверял
https://blog.juma.me.uk/2008/12/17/objects-with-no-allocation-overhead/
https://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#escapeAnalysis
https://minborgsjavapot.blogspot.com/2015/12/do-not-let-your-java-objects-escape.html
>гц (трейсирующий) -- та еще пораша
>В итоге там футпринт на 4гб, потому что кто-то за ссылочку зацепился.
Ага. Или просто gc влом собрать мусор.
> Эти копирования и деструкторы — пыль
Это initializer list. То есть питушня для инициализации объектов.
Питушня для инициализации должна сразу наполнять поля объекта, а не создавать временные объекты ко-ко-копировать что-то.
Если инициализационная питушня в царском языке (где следят за лишними копированиями, т.к. нужен пирфоманс) вместо, грубо говоря, placement new в полях объекта делает какие-то манипуляции и в теории сливает пирфоманс, то она просто дефективная, её надо переделывать.
Расскажите это хацкелистам с немутабельностью и ленивостью.
Когда простейшая программа приводит к out of memory.
>как настоящий крестушок объяснять, что это всё логичное
Есть огромная разница между некорректным поведением программы, и её недооптимизацией.
RVO и copy-elision, например, там есть: https://gcc.godbolt.org/z/mcCLhe.
Потому я за «сишку»
>RVO и copy-elision, например
А если там struct вложенный в struct? Мы возвратили внутренний struct, а внешний вышел за скоуп и похерился. Оно и такое сдюжит?
>А какие именно move-оптимизации ты хочешь в сишке?
Из совсем фантастических вещей: схлопывание malloc, memcpy и free.
https://govnokod.ru/15928#comment231366
Незаметно как это бывает
И уже с чьей-то легкой руки
Сишку "С++"-ом называют
Программисту сказали написать калькулятор. Программист сразу на всякий случай использовал матрицы. А вдруг потом понадобятся?
Попросили добавить корень - переписал под матрицы с комплексными числами. Отказаться от матриц не захотел. А вдруг кто-то ими воспользовался? Действительными числами обойтись не захотел У меня обработка ошибок иначе сломается, я лучше расширю домен.
Попросили добавить экспоненту. Матричную экспоненту реализовать было сложно, поэтому теперь по протоколу везде используются матрицы 1x1, матрицы других размерностей не тестируются, их использование приводит к падению программы.
Код стал тормозить. vector<vector<complex>> оказался медленнее double. Избавиться от матриц нельзя. У нас весь код завязан на матрицы!
В качестве оптимизации было решено отнаследоваться и сделать class MatrixDouble с одним double внутри, виртуальными методами и полным интерфейсом матрицы (который не выполняет протокол матрицы для размерностей 1x1).
В итоге код полностью завязан на матрицы, ничего матричного не считает, и любое изменение должно быть реализовано исходя из работы с матрицами, которые работают как числа.
> «Initializer list» — это не «питушня для инициализации», это просто объект
Но ведь всю эту психозу накидывают для того, чтобы можно было писать быстрый код и сливать скриптушков? А в итоге у скриптушков получаются более быстрые и дешёвые программы, т.к. программист занят бизнес-логикой, а не пердолингом с языком, а у компилятора не связаны руки архаичными правилами, которые программист должен всегда держать в голове.
Более того, уровень просадки пирфоманса от кривой реализации initializer_list настолько мал, что для скриптушков такие временные промежутки просто незаметны — у них ГЦ работает на пару порядков дольше.
Ну и наконец, пропозал с фиксами уже есть: http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0065r0.pdf.
Благодаря ей кресты могут уделывать сишку* при работе на стеке.
Царский пирфоманс и stack based gc (https://govnokod.ru/26439#comment528179) во все поля.
*Поправьте если ошибаюсь. Не знаю, есть ли в сишке какие-то гарантии для компилеров, чтобы они могли выкидывать копирования
Структура C++-подобных языков:
1. Неверные предпосылки и старое говно
2. Хорошие новые идеи
3. Логически корректный вывод говённой реализации 2 из 1
Все хорошие идеи должны пройти логически корректный вывод из неверных предпосылок. По-отдельности всё логично: и идеи хорошие, и логика логичная. Но из-за неверных предпосылок всё скатывается в говно.
Посмотрите любой срач "новичок vs олдфаг". Он имеет следующую структуру: новичок указывает на забагованные следствия и предлагает передалать, олдфаг игнорирует/привык к неверным предпосылкам, указывает новичку на правильные идеи и правильную логику, сам себя убеждает в правильности, ибо логично.