- 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;
}
phpBidlokoder2 15.02.2020 21:56 # −1
Переведите на "Java Script"
gost 15.02.2020 22:08 # 0
Именно поэтому я против «JavaScript».
phpBidlokoder2 15.02.2020 23:07 # 0
const obj = {'hello': 1,'world': 2,"it's": 3,'me': 4};
Object.keys(obj).forEach((key) => console.log(`k=${key} v=${obj[key]}`));
gost 15.02.2020 23:57 # +1
KpunoBblu_nemyx 16.02.2020 04:05 # +1
phpBidlokoder2 16.02.2020 20:49 # −1
3.14159265 19.02.2020 04:29 # +2
Туда ли ты зашёл, скриптушок?!
3.14159265 19.02.2020 04:26 # +1
gost 19.02.2020 13:19 # +1
eukaryote 20.02.2020 03:15 # 0
guest8 20.02.2020 03:25 # −999
guest8 20.02.2020 03:26 # −999
guest8 20.02.2020 03:29 # −999
guest8 20.02.2020 03:34 # −999
neTyx_npoTKHyTbIu 20.02.2020 03:39 # −1
KOPOBA 06.08.2022 01:23 # 0
guest6 06.08.2022 01:26 # +1
В случае вопроса, обращенного именно ко второму лицу, "t" не нужно.
Именно вопроса
Именно к "ты/вы"
Fike 06.08.2022 01:35 # +1
Именно предшествования глагола существительному je.
als je een haan bent, stop je niet met kraaien
stop, не stopt
guest6 06.08.2022 01:36 # 0
а это бывает не только в вопросах?:)
я еще туда не дорос
Fike 06.08.2022 01:39 # 0
nu ben je een eend
guest6 08.08.2022 00:43 # 0
KOPOBA 06.08.2022 01:41 # 0
У нидерландцев странновато звучат стечения звуков «sj» и «tj». Складывается впечатление, что они хотят произнести «ш» и «ч». Чем-то напоминает мутацию «си» и «ти» в японском.
P. S. В «als je» тоже наблюдается этот артефакт звучания.
hormand 06.08.2022 01:49 # 0
guest6 06.08.2022 01:53 # 0
alsjeblieft -- алщеблифт -- пожалста
meisje -- мейше -- девочка
А tj это ч
То есть все как-бы немного свдигается вперед
"je" это еще и уменьшительно-ласкательное, и я часто их слышу
kaart -- карта
kaartje -- карточка (карче).
Собссно, девочка тоже уменьшительное (потому она кстати het, хотя и не среднего рода)
hormand 06.08.2022 01:54 # 0
KOPOBA 06.08.2022 02:04 # 0
У шведов ещё забавнее: sj читается как «одновременно звучащие [ш] и [х]». Именно так этот звук описан во всех учебниках.
https://forvo.com/search/sju/sv/
guest6 06.08.2022 02:10 # 0
по ссылке я слышу мяхкую "х", типа "хю".
Тут таких нет, но звук "сх" они любят, и часто он там, где у англичан "sh" (пишется он как "sch")
schaap (схаап -- овца)
schip (схип -- корабль)
schoen (схун -- башмак)
school (схоол -- школа)
nyTuH_nugop 06.08.2022 02:17 # +1
Какой халяль)))
KOPOBA 06.08.2022 02:21 # 0
Лыжи у немцев будут «ши». Иногда пишут чисто по-немецки (Schi), а иногда в орфографии того языка, из которого позаимствовали это слово (Ski), но читают всё равно «ши». Вроде больше нигде «sk» у немцев так не читается.
***
Кстати, на конце слов в sch нидерландцы теяют ch, поэтому Иеронима Босха современные нидерландцы зовут Бос.
KOPOBA 07.08.2022 22:03 # 0
У немцев противоположная тенденция: они даже заимствованное из греческого Scheme читают как «шемэ». Более того, слово «шизофрения» — это искажённое немцами греческое («схизо» = «расщепляю» в переводе с греческого; у греков нету инфинитива). Вот уж насрали в вечность...
KOPOBA 07.08.2022 22:07 # +1
nOJlKOBHuK_CAHDEPC 07.08.2022 22:21 # 0
guest6 08.08.2022 00:34 # 0
spin -- паук
spelen -- игарть
overstappen -- пересадка
Тут везде и не "c" и не "ш", а нечто среднее, и зависит от того, кто говорит.
Но потому что глухая согласная идет следом.
Если звонкая или гласная, то "s"
snel -- быстрый
sinaasappel -- апельсин
slaapen -- спать
тут везде чистое "c"
guest6 08.08.2022 00:42 # 0
guest8 20.02.2020 03:42 # −999
Web_Monkey 20.02.2020 06:52 # 0
Web_Monkey 20.02.2020 07:01 # 0
3.14159265 21.02.2020 15:53 # 0
guest8 21.02.2020 16:47 # −999
HoBorogHuu_nemyx 21.02.2020 19:50 # 0
3.14159265 21.02.2020 19:56 # 0
guest8 23.02.2020 19:11 # −999
HoBorogHuu_nemyx 23.02.2020 19:59 # 0
3.14159265 24.02.2020 19:48 # 0
>Это хмл который служит для преобразования одного хмл в другой хмл и сам при этом хмл
Ммммм.
Мысль.
На самом деле XSLT, по задумке очень годный. Функциональный, тьюринг-полный.
Минус: он очень громоздкий (ибо xml).
Потому любая композиция примитивов средствами языка выходит более громозкой чем обычная копипаста.
guest8 24.02.2020 19:58 # −999
Web_Monkey 20.02.2020 07:04 # +1
В нём единственная структура данных это массив.
bootcamp_dropout 20.02.2020 11:05 # 0
guest8 20.02.2020 14:33 # −999
1024-- 20.02.2020 18:36 # 0
guest8 20.02.2020 18:38 # −999
Stallman 20.02.2020 18:39 # +1
3.14159265 21.02.2020 15:54 # 0
hormand 06.08.2022 01:55 # 0
Fike 16.02.2020 00:12 # 0
gost 16.02.2020 00:19 # 0
Fike 16.02.2020 01:44 # 0
хорошо.
KpunoBblu_nemyx 16.02.2020 04:03 # +1
phpBidlokoder2 16.02.2020 20:48 # −1
3.14159265 21.02.2020 16:07 # 0
В С++ уже много лет как сделали «сборщик мусора», называется «RAII» и «умный указатель».
guest8 21.02.2020 17:44 # −999
gost 21.02.2020 17:51 # +1
guest8 21.02.2020 17:58 # −999
gost 21.02.2020 18:00 # +1
guest8 21.02.2020 18:02 # −999
Stallman 21.02.2020 18:03 # 0
guest8 21.02.2020 18:05 # −999
Stallman 21.02.2020 18:33 # 0
guest8 21.02.2020 18:35 # −999
3.14159265 21.02.2020 18:07 # +2
Но при этом сами не умеют нормально и детерменированно освобождать ресурсы отличные от памяти.
Отсюда проблемы с незакрытыми коннекшнами, стримами. И всякие конструкты вроде try-with-resources.
guest8 21.02.2020 18:10 # −999
3.14159265 21.02.2020 18:14 # 0
Действительно, если есть AutoCloseable.
https://docs.oracle.com/javase/8/docs/api/java/lang/AutoCloseable.html
Причём особый багор, в и тут всё опять сделали через жапу.
try-with-resources (сахарок), конечно прикольно.
Но он не работает с такими вещами как Lock или мьютекс.
Там по-прежнему нужно писать finally и делать release руками, как в старой-доброй сишке.
guest8 21.02.2020 18:15 # −999
3.14159265 21.02.2020 18:17 # 0
Ээээ
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 на объекте рефлексией.
>Джависты, почему всё через жопу?
Жопа. Жапа. Жава.
guest8 21.02.2020 18:18 # −999
3.14159265 21.02.2020 18:03 # +2
Счётчик ссылок принято считать особой формой сборщика мусора.
Например в CPython счётчик ссылок это основной сборщик, а tracing (https://en.wikipedia.org/wiki/Tracing_garbage_collection) запускается иногда только для сборки островков циклических ссылок.
guest8 21.02.2020 18:05 # −999
3.14159265 21.02.2020 18:10 # 0
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.
guest8 21.02.2020 18:14 # −999
3.14159265 21.02.2020 18:44 # +1
Это самый простой и широкораспространённый тип.
И лично я выделяю его в отдельный класс.
Этот gc присутствует и в сишке, и алголе.
Он замечательно работает, пока программист не начинает вызывать *alloc.
У царского gc потрясающая скорость (указатель стека обычно двигает процессор), детерминированность, отсутствие задержек и фрагментации.
3.14159265 21.02.2020 19:00 # +3
Уже лет 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).
bormand 06.08.2022 09:31 # 0
Сколько пафоса вокруг очевидной идеи про три сумматора, даже имя дали... Поди ещё и запатентовали, чтобы конкуренты не могли юзать?
3.14159265 10.08.2022 01:31 # +1
Какой некробамп )))
Там прикол в другом: как Штеуд элегантно додумался совместить переименование регистров OoO с mov.
А также неявно завёз концепцию нулевого регистра из RISC.
Ведь по сути все идиомы обнуления просто переименовывают операнд в этот немутабельный, забитый нулями регистр.
Внутри x86-64 стал ещё больше RISC чем быдл до того.
hormand 11.08.2022 00:27 # 0
Давай станцуем бамп!!
guest6 06.08.2022 10:17 # 0
bormand 06.08.2022 10:30 # 0
guest6 06.08.2022 16:42 # +2
Это как если бы я всё время забывал ключи, и вскрывал замок спичкой, а потом выпустили бы специальный замок со спичкой вместо ключа, потому что я уже привык
В программировании вообще часто так бывает
bormand 06.08.2022 16:51 # +1
HoBorogHuu_nemyx 19.02.2020 13:32 # 0
guest8 20.02.2020 14:34 # −999
bormand 20.02.2020 16:52 # 0
guest8 20.02.2020 16:56 # −999
HoBorogHuu_nemyx 20.02.2020 16:53 # 0
KpunoBblu_nemyx 20.02.2020 16:58 # 0
HoBorogHuu_nemyx 20.02.2020 17:17 # 0
https://static.life.ru/posts/2017/12/1072282/f073668938eb7407cb323ce4e3fe4f1c.jpg
kak 20.02.2020 18:27 # 0
Захiдный поток!
guest8 20.02.2020 18:31 # −999
bormand 20.02.2020 17:02 # +1
HoBorogHuu_nemyx 20.02.2020 17:12 # +2
1. Пишут слово «ХУЙ».
2. Вокруг него прибивают доски.
bormanb 06.08.2022 21:34 # 0
kak 20.02.2020 18:43 # +1
3.14159265 21.02.2020 16:04 # 0
Аффиный Давид.
https://en.wikipedia.org/wiki/Affidavit
dim0 23.02.2020 18:16 # 0
HoBorogHuu_nemyx 23.02.2020 18:33 # 0
https://cppinsights.io/s/5d09f938
gost 23.02.2020 18:39 # +2
dim0 24.02.2020 12:35 # 0
https://pastebin.com/JyXBFQex
В M() по два ненужных copy, в Ms() по одному, добавление move() не убирает copy, только лишний move даёт. Лишние copy не убираются. (может make_pair, сейчас попробую...) При этом при инициализации пары в p() тоже ненужное copy, но в pm() оно успешно меняется на move (вероятно потому что это не initializer list, а brace initialization).
dim0 24.02.2020 14:41 # 0
dim0 24.02.2020 14:51 # 0
gost 24.02.2020 16:20 # +1
Для пирфоманса остаётся делать так: 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/.
gostinho 24.02.2020 16:29 # 0
gost 24.02.2020 16:35 # +1
3.14159265 24.02.2020 19:39 # 0
Удваиваю!
>хипстеры не пишут на «C++»
Это один из самых весомых аргументов в пользу «C++».
kcalbCube 13.08.2022 14:26 # 0
1024-- 24.02.2020 19:32 # 0
Когда нужно использовать какую-то фичу языка, и она не работает, программисту говорят, что виноват в этом он, и надо было читать вон те 300 страниц стандарта. Потом ему как маленькому ребёнку объясняют, в чём он не прав, и почему фича (точнее, баг) языка работает не так, как он ожидал. Рассказывается история языка и его "принципы".
Когда человек говорит, что фича-то новая, и можно было её сделать как надо, ему отвечают, что он ничего не понимает, и вон те, те и те условия вынудили сделать так, и вообще, если бы сделали как надо, эта фича конфликтовала бы с ещё какой-то старой питушнёй.
При попытке сказать, что питушню можно было выбросить или просто исправить, крестухи затыкают программиста и говорят, что кресты поддерживают совместимость. Им отвечают, что её и так всё равно уже сломали в случае вон с тем изменением. Крестухи тупят взор и говорят, что это вообще несравнимые понятия, и там было абсолютно другое дело.
В логике есть понятие следования. Из истины следует истина, а из лжи - всё, что угодно. Обратно, если последовала истина, значит на входе было всё, что угодно, а если последовала ложь, - то на входе была ложь.
Соответственно, если новая фича вышла говнистая, и это следует из принципов языка, значит принципы языка - говно и нуждаются в замене. Но крестухи считают наоборот. Стандарт непогрешим, свят и бесконечно правилен, а противоречия и следование из него говна - лишь надуманное кукареканье неподготовленного питузка, который должен наискорейше изменить свои мышление и систему ценностей, чтобы стандарт выглядел там логичным.
3.14159265 24.02.2020 19:37 # 0
move-семантику (поглощение кишков других объектов) в кресты запилили чисто ради пирфоманса.
Иногда она не срабатывает. И программа работает чуть медленее.
«JS» и «пирфоманс» — оксюморон.
1024-- 24.02.2020 19:56 # 0
Код на JS выглядит абсолютно не так, как на остальных языках, те же вещи выглядят сложнее.
Для борьбы с асинхронностью создаётся лапша коллбеков, промисы. Разрабатываются новые парадигмы и библиотеки, в язык впиливают генераторы и новые ключевые слова.
Код всё равно не становится таким же понятным, как в других языках, и новые конструкции - лишь сахарок над нагромождениями абстракций, призванных бороться с асинхронностью. То есть если что-то не сработает на уровне "async/await", программисту придётся спуститься на уровень генераторов, потом на уровень промисов, потом на уровень коллбеков. Только знаний async/await не хватит, для написания реального кода потребуется быть коллбековедом.
Аналогично с {}. Фича могла бы работать как надо, но из-за наслоений говна не работает, что выдаётся за правильное поведение.
3.14159265 24.02.2020 19:59 # 0
Крестухи кмк делают важное дело.
И мне очень хотелось бы увидеть подобные питумизации в high-level языках с gc.
Для начала в том же хацкеле с принудительной иммутабельностью. А потом и во всяких jvm, v8 для COW.
Вместо бесконечного копирования при мутациях, ghc мог бы определять что исходное значение не используется, мутировать тот блок памяти и возвращать его.
Экономия на копировании и сборке.
1024-- 24.02.2020 20:16 # 0
Мув-питушня - дело интересное, но уж лучше бы она была автоматической. А то ты один раз забыл что-то дописать, и потом у тебя вся программа испортилась.
С введением мув-питушни увеличились количество категорий значений. Раньше было логично - питушня, у которой есть интересное для нас значение (rvalue) и питушня, у которой есть интересный для нас адрес (lvalue). Это хорошо мапится на внутреннюю структуру. Каждый, кто писал свой интерпретатор для простого языка с арифмопитушнёй и присваиваниями, автоматически и логично дошёл до темы lvalue и rvalue: некоторые особенные операции требуют помещения в стек адреса, а не значения.
В современных крестах теперь 100500 неочевидных категорий значений и кобенаторно большее число кобенаций эффектов от их взаимодействия. Как трёхмерная таблица типов для арифмушни в JS.
Пачку конструкторов добавили. А это уже в некотором смысле дублирование кода. Если класс поменялся, нужно менять не только все конструкторы (или, хм, в новых версиях разрешили переиспользовать конструкторы, не помню?), но ещё и дополнительный спецконструктор. Забыл это сделать - у тебя объект правильно создастся, правильно скопируется и неправильно переместится. И из-за вороха правил о том, когда какой конструктор выполняется, баг будет вылезать в неочевидных местах.
3.14159265 24.02.2020 20:26 # +1
Как я понял никакого бага не будет. Там везде no leaks.
Просто компилер не сможет сделать RVO и лишний раз кишки скопирует.
Плюс вызовет констуктор для нового и деструктор для старого, уже не нужного.
1024-- 24.02.2020 20:32 # 0
Описанная мной питушня происходит при модификации класса, у которого уже есть конструктор копирования и конструктор перемещения.
Не укажешь конструктор перемещения - код будет недостаточно царским, иногда будет тормозить.
Укажешь конструктор перемещения - надо его поддерживать, а так как код царский, абстрагироваться не получится (из-за пирфоманса), будет два конструктора, которые почти такие же, но с различиями, которые оба надо будет поддерживать.
gost 24.02.2020 20:37 # 0
gost 24.02.2020 20:29 # +1
Со стороны параши более высокоуровневых языков, в которых про все эти байтики и копирования не думают и текут — возможно. Для какого-нибудь сишника следить за копированием/перемещением/удалением — вполне себе норма.
3.14159265 24.02.2020 20:33 # 0
а) создают кучи говна на куче и гоняют только ссылки
б) при копировании и херинге исходного объекта обычно никогда и ничего не оптимизируют, а тупо плодят новые объекты, а gc потом соберёт старый. По сути те же самые конструктор+деструктор
guest8 24.02.2020 20:35 # −999
3.14159265 24.02.2020 20:37 # 0
Плюс там в общем случае констукторы/деструкторы с непонятным содержанием. Они могут закрывать ресурсы и открывать их снова.
Но реально это сверхоптимизация, чтобы не копировать даже пару байтиков.
guest8 24.02.2020 20:47 # −999
1024-- 24.02.2020 20:47 # 0
Следить за копированием/перемещением/удалением - полезно, кто-то это обязательно должен делать. Лично я - за то, чтобы это делал компилятор, т.к. он может посмотреть на программу целиком и понять, где что надо делать, а у программиста будет регулярный код в терминах бизнес-логики, а не в терминах вынужденного байтоёбства.
Но деструктивное конструирование не перестанет от этого быть оксюмороном. Два миллиона евро плюс два миллиона евро - это четыре миллиона евро, не важно, человек зарабатывает миллион, тысячу или сто евро в месяц.
guest8 24.02.2020 20:53 # −999
gost 24.02.2020 21:03 # 0
Универсальное решение, когда «программист» просто говорит конпелятору «сделай заебись», а конпелятор делает максимально быстрое, удобное и безопасное «заебись», бывает только в мире розовых пони и сильных ИИ. А наш мир, увы, несовершенен, абстракции текут, поэтому компромисс между скоростью разработки, высотой абстракций и скоростью выполнения будет существовать всегда.
3.14159265 24.02.2020 21:08 # 0
> конпелятор делает максимально быстрое, удобное и безопасное «заебись»
Притом что крестокомпилятор и так изо всех сил оптимизирует.
И программист обычно на это не смотрит, пока профайлером не выяснит что оно мешает.
guest8 24.02.2020 21:19 # −999
gost 24.02.2020 21:22 # 0
В наибольшей степени это заслуга закона Мура, чем развитием компиляторов. 30 лет идея программы для обмена сообщениями, занимающей гигабайт оперативы, звучала как несмешной анекдот. Но закон Мура упёрся в физику и более не работает. Так что увы.
guest8 24.02.2020 21:27 # −999
3.14159265 24.02.2020 21:37 # 0
Ещё немного осталось потерпеть. Скоро туда structы завезут.
Не бог весть что конечно. Но легковеснее чем обычные объекты.
guest8 24.02.2020 22:04 # −999
3.14159265 24.02.2020 22:10 # 0
>типа этакий валуё обжект?
Да. Если структы равны, если все поля их равны. Типа 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.
guest8 24.02.2020 22:14 # −999
1024-- 24.02.2020 21:40 # 0
Раньше у компьютера не было времени, чтобы выполнить царскую программу, и она тормозила как по причине слабого железа, так и по причине недостатка автоматической оптимизации, а теперь у него есть время на эту самую автоматическую оптимизацию. Автомат может потратить время и из некоторого набора анскильных программ сделать царские, которые будут выполняться быстрее и при более долгом времени работы получат меньший оверхед.
3.14159265 24.02.2020 21:59 # 0
Наконец-то анскильные отбросы перестанут писать своё bloatware как попало.
Ибо я думал что процесс раздувания софта уже никак не оставить. Поскольку будут появляться всё более мощные компьютеры, способные его переварить.
В итоге у нас появляется тот же самый по функицоналу софт, но чудовищно обросший свистоперделками.
guest8 24.02.2020 22:02 # −999
3.14159265 24.02.2020 22:05 # +2
Нет.
1. Новые тех. процессы уже не делают транзисторы дешевле, т.к. требуют экспоненциального увеличения числа масок.
2. Число производителей осваивающих новые тех. процессы сократилось с десятка до двух (samsung, tsmc).
3. У великого и могучего штеуда дикие проблемы с новыми тех. процессами. Из-за этого фактически пятилетняя стагнация на рынке десктопов.
Если бы не АМД, мы бы до сих пор видели очередной i5-100500 с 4мя ядрами за те же 200$.
>у меня 16 виртуальных цпу
Разве что виртуальных. Типа SMT.
guest8 24.02.2020 22:09 # −999
gost 24.02.2020 22:12 # 0
guest8 24.02.2020 22:20 # −999
1024-- 24.02.2020 22:12 # 0
Лет 20 назад компушню десятилетней давности встретили бы обмороком от удивления.
> появляется тот же самый по функицоналу софт, но чудовищно обросший свистоперделками
Иногда - даже хуже по функционалу.
Тебе подкинули гигабайты памяти, гигагерцы, экраны получше, а ты отрисовываешь меньше кнопок, меньше текста, работаешь медленнее и тупее.
1024-- 24.02.2020 22:21 # 0
ИЧСХ на российском рынке из недорогих будут модели с 6ГБ, за аналог 1000 долларов у половины будет 8ГБ.
3.14159265 24.02.2020 22:23 # 0
Хаха. 11 лет это очень много. Спасибо физическим барьерам и частотному потолку.
Вот в 90х и 00х компы устаревали со скоростью света, буквально за 2-3 года.
А видеокарты и того быстрее. Помню купил середнячка, поиграл немного, а там смотришь, у тебя уже говно старое.
guest8 24.02.2020 22:29 # −999
3.14159265 24.02.2020 22:34 # 0
И свежая винда тогда выходила каждые полтора-джва года. 95/98/98 SE/Me/2000/Xp. Просто голова кружилась.
Это 90е и первая половина нулевых, пока интел не упёрлась в 4 ГГц и огромное тепловыделение. А MS не начала пилить висту.
>Третий пень 1999-го года выпуска вполне мог работать в 2005-м.
Да. Третий пень был годнотой, ибо первые P4 были тупым говном, которое P3 сливал в хламину.
И в 2004 у штеуда были трабы с 90м тех. процессом.
guest8 24.02.2020 22:38 # −999
1024-- 24.02.2020 21:08 # 0
Хотя, соглашусь, что универсального подхода не существует.
3.14159265 24.02.2020 21:11 # 0
Доооо.
На 4 гигабайтных кучах задержки бывали по 5 секунд. Это очень неприятно.
gost 24.02.2020 21:13 # +1
3.14159265 25.02.2020 01:06 # 0
guest8 24.02.2020 21:14 # −999
gost 24.02.2020 20:58 # +1
Как только в компилятор встроят сильный ИИ — он сразу же и будет смотреть на всю программу целиком. А пока что либо всё в куче и копируется, а-ля жаба, либо всё ручками.
Деструктивное конструирование, оно же конструирование при помоще move-конструктора — вполне себе нормальный термин (хоть и придуманный мной, да). Вот есть у тебя объект X, ты хочешь из него сконструировать объект Y (Y := X). На высоком уровне абстракции тебе действительно похуй, как оно там всё будет, главное, чтобы результат был. А как только эта операция начинает выполняться сотню миллионов раз в секунду — тебе сразу хочется, чтобы во время неё не было никаких лишний копирований или аллокаций. И тут уже приходится задумываться, где там у тебя что копируется, где перемещается и как используется.
3.14159265 24.02.2020 21:05 # 0
Logical error.
О каких миллионах речь?
Обычное для скриптухов дело — сайты с 38ю записями.
gostinho 24.02.2020 21:09 # 0
[придумайте продолжение]
HoBorogHuu_nemyx 25.02.2020 01:26 # 0
guest8 25.02.2020 01:33 # −999
HoBorogHuu_nemyx 25.02.2020 13:31 # 0
>> У клинтуха по сравнению с диким сизарём окрас более монотонный, со слабо выраженными полосками на крыльях и без белого пятна на спине. Если снизу посмотреть на взлетающую птицу, то можно увидеть, что испод крыла серый — значительно более тёмный, чем у сизого голубя и вяхиря, и по тону почти не отличается от такого же тёмного брюха. Вяхирь выглядит гораздо массивнее остальных двух видов, и к тому же выделяется белым пятном на боках шеи. На груди клинтуха развит розовато-винный оттенок, более ярко выраженный, чем у сизого голубя, но занимающий меньшую площадь, чем у вяхиря.
Боюсь, что я тоже сходу не отличу. А с учётом того, что у обычного сизого голубя есть куча культурных пород разных окрасок, которые одичали и скрестились с дикими, задача определения вида становится непростой.
gostinho 25.02.2020 08:53 # 0
guest8 25.02.2020 12:10 # −999
1024-- 24.02.2020 21:12 # 0
Это да. Но вот только в скриптушне он будет смотреть на программу как на говно и оптимизировать направо и налево, а в крестах - программа будет смотреть на него как на говно, и всё, что он сможет выдать - пачку ворнингов вида "программист, это ты серьёзно или ошибся?"
3.14159265 24.02.2020 21:13 # 0
Неа.
Опять ошибка.
В скриптушне у него будут дикие проблемы с неясными типами.
То ли флоат, то ли инт. Гадай, оптимизируй.
gost 24.02.2020 21:20 # +1
См. начало http://lib.ru/FOUNDATION/question.txt.
3.14159265 24.02.2020 21:24 # 0
Только ответ ИИ может быть очень неожиданным.
Мы когда-то с wvxvw это здесь обсуждали.
ИИ может дать ответ, который люди просто не поймут. Типа вореции поехавшего.
PS Концовка рассказа эпична.
gost 24.02.2020 21:28 # 0
Да, рассказ охуенен. Причём в оригинале, ИМХО, даже круче: https://www.multivax.com/last_question.html.
Я, кстати, за «Wolfram Alpha»: https://www.wolframalpha.com/input/?i=Can entropy be reversed%3F.
3.14159265 24.02.2020 21:31 # 0
https://www.youtube.com/watch?v=YCIptc12bmU
И вот прошло много много лет. и доктор стоит перед вратами рая . а на встречу ему выходит бог в синей олимпийке и говорит- Привет Юрий Генадьевичь а ведь тогда не поверил мне....
1024-- 24.02.2020 21:25 # 0
guest8 24.02.2020 21:29 # −999
1024-- 24.02.2020 21:35 # +1
Если конпелятору докинуть вычислительной мощности и памяти, он увидит весь код целиком. С программистом так поступить нельзя.
Например, стык библиотек. В одной инты, в другой флоаты, программе нужны даблы.
Или всё то же проектирование. Раньше думали, что нужны инты, теперь понадобились даблы. Переписывать целиком долго.
guest8 24.02.2020 21:37 # −999
1024-- 24.02.2020 21:46 # 0
У оптимизатора скриптушни развязаны руки - он может как навредить, так и помочь.
Зависит от мощности анализатора. Если, например, там делается много округлений или печатается целое число, можно догадаться, что нужен целый питух.
> компулятор взял, и сделал везде дабл. При этом в 99% случаев нам нужен int.
А вот так ведь и сама сишка делает, правда только локально. Если в выражении затесался флоат, всё зашкваривается в плавучку.
gost 24.02.2020 21:38 # 0
1024-- 24.02.2020 22:02 # 0
Если же он пишет шаблон, всё ещё больше усложняется. Приходится работать в области классов типов или концептов, выделять общие операции, думать про perfect forwarding. Если писать фиксированный код, он будет сильно тормозить для неподходящих типов. Если писать шаблонный код, он будет понемногу тормозить для некоторых типов, надо будет специализации писать.
gost 24.02.2020 21:14 # 0
1024-- 24.02.2020 21:18 # 0
Ну вот я ожидаю, что в C++ при инициализации временными объектами не будет никаких копирований или перемещений. Объекту указывают на шконку поле, на котором он будет вызывать свой конструктор. И всё.
Копирования/деструкции/перемещения вовсе не должно быть, если инициализация - первое и последнее использование переменной, и тем более, если это анонимное выражение.
Так и только так должно быть в языке, где важен перфоманс.
gost 24.02.2020 21:32 # 0
Ну и да, основная проблема initializer_list в том, что его разработка велась одновременно с move semantics, и последнюю не учитывала. А потом стало поздно фиксить, Комитет решил, что это несущественно… Ну, короче, как всегда виноваты люди.
1024-- 24.02.2020 21:53 # 0
3.14159265 24.02.2020 20:59 # 0
Это означает всего-лишь что вызывается деструктор старого объекта (аналог: собрал gc) и конструктор копии.
В данном случае мы переиспользуем старый объект, о котором известно что его отправят на свалку.
И повторюсь: мне хотелось бы видеть использование такой методу за пределами крестов.
Например оптимизацию немутабельной мутабельности (ещё один оксюморон) в хацкеле.
bormand 25.02.2020 00:48 # 0
Именно поэтому я за кресты, где все ресурсы равны.
3.14159265 25.02.2020 00:55 # +1
>https://govnokod.ru/26439#comment528165
В CиПитоне сборщик на счётчиках ссылок, они дескриптор закроют сами, как только он не нужен.
bormand 25.02.2020 00:58 # 0
3.14159265 25.02.2020 02:24 # 0
Счётчик ссылок собирает очевидное говно, а круговую поруку собирает уже tracing gc как в жабе.
Если файл открыли прочитали и вышли из метода, то питон его закроет, т.к. не осталось никиаких ссылок.
Проблема в том что такое решение непортируемое в другие реализации питона на яве/шарпе (jython и ironpython). Т.к. там анскильные gc без счётчиков.
gost 25.02.2020 02:26 # 0
Ух, бля.
3.14159265 25.02.2020 02:28 # 0
gost 25.02.2020 02:31 # 0
Я даже боюсь представить, как это всё насилует память и сколько терабайт там выделяется-освобождается каждую секунду.
guest8 25.02.2020 02:43 # −999
guest8 25.02.2020 02:43 # −999
guest8 25.02.2020 03:27 # −999
3.14159265 25.02.2020 02:51 # +1
Проверил
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.
guest8 25.02.2020 03:23 # −999
gost 25.02.2020 03:28 # 0
А вообще я почитал про него, кстати. Пишут, что оно нужно для быстрой интеграции с джавакодом; в частности, там вместо питоновских пакетов используются классы «Java».
guest8 25.02.2020 03:37 # −999
gost 25.02.2020 04:39 # 0
guest8 25.02.2020 04:47 # −999
HoBorogHuu_nemyx 25.02.2020 06:00 # 0
3.14159265 25.02.2020 15:22 # 0
Но это было 10 лет назад.
Уж лучше взять скакалку или котлин.
guest8 25.02.2020 16:35 # −999
1024-- 25.02.2020 19:11 # 0
Таким должно быть всё.
Язык - это питушня для высказывания мыслей, а не жёсткая реализация. Пусть будет больше возможности высказать свои мысли.
Может быть, я хочу программировать веб страницы на сишке со сборкой мусора, а прошивку писать на питоне с ручным управлением памятью.
1024-- 25.02.2020 19:15 # 0
1024-- 25.02.2020 19:13 # 0
bormand 25.02.2020 19:20 # 0
Т.е. детерминированности, по факту, никакой.
1024-- 25.02.2020 19:05 # 0
Питушня. Это уже возня с побочными эффектами. С памятью ладно, там из побочных эффектов только недетерминированность malloc() == NULL, а тут может закрыть слишком поздно, а может - слишком рано.
Может быть, программа хочет, чтобы файл был открыт, пока она жива.
gost 25.02.2020 19:12 # +2
guest8 25.02.2020 19:18 # −999
1024-- 25.02.2020 19:48 # 0
HoBorogHuu_nemyx 26.02.2020 01:15 # 0
guest8 25.02.2020 01:37 # −999
1024-- 25.02.2020 19:17 # 0
3.14159265 25.02.2020 13:48 # +1
Компилер выдаёт ошибку если код обращается к объекту без кишков.
https://yoric.github.io/post/rust-typestate/
1024-- 24.02.2020 21:30 # 0
> оптимизацию немутабельной мутабельности (ещё один оксюморон) в хацкеле
Тут вообще из-за прозрачности ссылок у компилятора все карты на руках.
Такая питушня может прийти вместе с оптимизацией хвостовой рекурсии как обновление компилятора, а не как новая конструкция с новой философией, 50 оттенками rvalue, новыми конструкторами, амперсандами, хинтами и багами.
3.14159265 24.02.2020 21:35 # 0
Да. Именно об этмо речь.
Но почему-то они пока не сделали такое. А разгадка проста: Хаскель-отребье, как и всякое другое отребье не может ничего родить. Оно может только воровать, врать и соревноваться с инвалидами. Очевидно, что с реальным си++ они соревноваться не могут.
1024-- 24.02.2020 21:56 # 0
В хаскелях всегда есть возможность соптимизировать старое говно, которой можно воспользоваться в любой момент. Решение существует, пусть всё продолжает гореть.
3.14159265 24.02.2020 22:15 # 0
Это всё красиво звучит только на бумаге. Почему такой питумазции ещё нет?
А пока такой оптимизации нет на практике — хацкелисты анскильные отбросы.
>У крестушков, если не изменишь язык, у компилятора останутся связаны руки. Надо действовать.
В жабе вот тоже люди чухали голову и пришли к выводу что нужно менять язык.
Хотя казалось бы: уровень абстракции куда выше.
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.
Посоны прямым текстом говорят: немутабельность это дорого.
1024-- 24.02.2020 22:32 # 0
Ну и вообще, как мне кажется, хаскели - площадка для вкидывания идей. Нормальный язык не должен возводить какую-нибудь питушню в абсолют, иначе он становится неюзабельным. В хаскелях нельзя написать hello, world без спецзнаний в хитрых областях математики. Не говоря уже о дебаге принтфом, для которого нужно одно-два высших образования.
В жс красиво поступили с иммутабельностью строк. В итоге мы наблюдаем эффекты как линеаризации квадратичного кода (str += 'x';), так и хранения старой питушни (a = pituz.substring(10e6, 10e6+1)). И в целом оптимизация неплохо справляется с идеей иммутабельности.
3.14159265 24.02.2020 22:20 # 0
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.
guest8 24.02.2020 22:47 # −999
3.14159265 25.02.2020 15:32 # 0
Так можно тоже самое сказать о ECMA-скриптерах.
Для новых фич языка, типа деструктивных присваиваний жскриптухи вводят полностью новый синтаксис.
А в крестах посоны делают новый вызов.
https://godbolt.org/z/RRmruC
bormand 25.02.2020 15:57 # 0
1024-- 25.02.2020 19:19 # 0
В крестах у компилятора всё так же будут связаны руки, в скриптушне - всё так же развязаны.
1024-- 24.02.2020 19:46 # 0
Вся суть 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 >>.
3.14159265 24.02.2020 19:49 # +1
::pitux ?
https://ideone.com/vXNpTg
Я не адепт крестов, но со стороны ваши набросы на С++ выглядят нелепо.
Люди обсуждают move-семантику, и удаление лишнего копирования.
А вы возводите несработавшую оптимизацию в разряд вселенской ошибки.
Кстати, именно поэтому я обычно никогда не лез в С++ срачи. Поскольку я крестов не знаю и меня в них быстро сольют.
1024-- 24.02.2020 20:03 # 0
И тут оказалось, что std::inipitulizer_pituz вызывает какие-то копирования.
> возводите несработавшую оптимизацию в разряд вселенской ошибки.
В статье из-за этого код не скомпилировался.
> Кстати, именно поэтому я обычно никогда не лез в С++ срачи. Поскольку я крестов не знаю и меня в них быстро сольют.
Иногда полезно взглянуть на проблему со стороны. Один раз сольют, второй раз сольют, а в третий раз осознают, что им говорил человек с незамыленным глазом и выберут другой язык для программирования. Но там будут свои питушни, и свои сектанты.
Кресты, как и другие языки, вызывают привыкание. Иногда стоит представить, как бы пришлось объяснять кресты обычному человеку - скажем, бабушке или психиатру, который ещё не решил, здоров ты или нет. И тут сразу всплывают все эти острые углы и нелогичности, которые ты на автомате обходил и считал нормальными. А то иначе - всё нормально и логично. Святой стандарт и чёткие из него следствия.
3.14159265 24.02.2020 20:08 # 0
Ошибка компиляции — наименьшее из зол, которые могут приключиться с программой.
Я понимаю что в js можно писать как угодно и никто ругаться не будет. А код ёбнет уже потом, при выполнении.
>вызывает какие-то копирования
Эти копирования и деструкторы — пыль, по сравнению с тем какие кучи мусора вычищает gc за скриптушачиьм говном.
Тут люди вообще всё по стеку двигают.
guest8 24.02.2020 20:16 # −999
3.14159265 24.02.2020 20:22 # 0
Да. 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 влом собрать мусор.
guest8 24.02.2020 20:24 # −999
gost 24.02.2020 20:26 # 0
guest8 24.02.2020 20:29 # −999
1024-- 24.02.2020 20:28 # 0
> Эти копирования и деструкторы — пыль
Это initializer list. То есть питушня для инициализации объектов.
Питушня для инициализации должна сразу наполнять поля объекта, а не создавать временные объекты ко-ко-копировать что-то.
Если инициализационная питушня в царском языке (где следят за лишними копированиями, т.к. нужен пирфоманс) вместо, грубо говоря, placement new в полях объекта делает какие-то манипуляции и в теории сливает пирфоманс, то она просто дефективная, её надо переделывать.
3.14159265 24.02.2020 20:29 # 0
Расскажите это хацкелистам с немутабельностью и ленивостью.
Когда простейшая программа приводит к out of memory.
>как настоящий крестушок объяснять, что это всё логичное
Есть огромная разница между некорректным поведением программы, и её недооптимизацией.
gost 24.02.2020 20:33 # 0
3.14159265 24.02.2020 20:34 # 0
gost 24.02.2020 20:42 # +1
RVO и copy-elision, например, там есть: https://gcc.godbolt.org/z/mcCLhe.
3.14159265 25.02.2020 01:02 # +1
Потому я за «сишку»
>RVO и copy-elision, например
А если там struct вложенный в struct? Мы возвратили внутренний struct, а внешний вышел за скоуп и похерился. Оно и такое сдюжит?
>А какие именно move-оптимизации ты хочешь в сишке?
Из совсем фантастических вещей: схлопывание malloc, memcpy и free.
https://govnokod.ru/15928#comment231366
gostinho 24.02.2020 20:48 # +1
Незаметно как это бывает
И уже с чьей-то легкой руки
Сишку "С++"-ом называют
guest8 24.02.2020 20:55 # −999
gostinho 24.02.2020 20:56 # 0
1024-- 24.02.2020 20:59 # 0
Программисту сказали написать калькулятор. Программист сразу на всякий случай использовал матрицы. А вдруг потом понадобятся?
Попросили добавить корень - переписал под матрицы с комплексными числами. Отказаться от матриц не захотел. А вдруг кто-то ими воспользовался? Действительными числами обойтись не захотел У меня обработка ошибок иначе сломается, я лучше расширю домен.
Попросили добавить экспоненту. Матричную экспоненту реализовать было сложно, поэтому теперь по протоколу везде используются матрицы 1x1, матрицы других размерностей не тестируются, их использование приводит к падению программы.
Код стал тормозить. vector<vector<complex>> оказался медленнее double. Избавиться от матриц нельзя. У нас весь код завязан на матрицы!
В качестве оптимизации было решено отнаследоваться и сделать class MatrixDouble с одним double внутри, виртуальными методами и полным интерфейсом матрицы (который не выполняет протокол матрицы для размерностей 1x1).
В итоге код полностью завязан на матрицы, ничего матричного не считает, и любое изменение должно быть реализовано исходя из работы с матрицами, которые работают как числа.
1024-- 24.02.2020 21:03 # 0
> «Initializer list» — это не «питушня для инициализации», это просто объект
Но ведь всю эту психозу накидывают для того, чтобы можно было писать быстрый код и сливать скриптушков? А в итоге у скриптушков получаются более быстрые и дешёвые программы, т.к. программист занят бизнес-логикой, а не пердолингом с языком, а у компилятора не связаны руки архаичными правилами, которые программист должен всегда держать в голове.
gost 24.02.2020 21:10 # +3
Более того, уровень просадки пирфоманса от кривой реализации initializer_list настолько мал, что для скриптушков такие временные промежутки просто незаметны — у них ГЦ работает на пару порядков дольше.
Ну и наконец, пропозал с фиксами уже есть: http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0065r0.pdf.
3.14159265 24.02.2020 20:20 # 0
Благодаря ей кресты могут уделывать сишку* при работе на стеке.
Царский пирфоманс и stack based gc (https://govnokod.ru/26439#comment528179) во все поля.
*Поправьте если ошибаюсь. Не знаю, есть ли в сишке какие-то гарантии для компилеров, чтобы они могли выкидывать копирования
1024-- 24.02.2020 20:39 # 0
Структура C++-подобных языков:
1. Неверные предпосылки и старое говно
2. Хорошие новые идеи
3. Логически корректный вывод говённой реализации 2 из 1
Все хорошие идеи должны пройти логически корректный вывод из неверных предпосылок. По-отдельности всё логично: и идеи хорошие, и логика логичная. Но из-за неверных предпосылок всё скатывается в говно.
Посмотрите любой срач "новичок vs олдфаг". Он имеет следующую структуру: новичок указывает на забагованные следствия и предлагает передалать, олдфаг игнорирует/привык к неверным предпосылкам, указывает новичку на правильные идеи и правильную логику, сам себя убеждает в правильности, ибо логично.