- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
void *govno[300] = {NULL};
size_t govnopoindex = 0;
void chisti_govno(void)
{
do
{
free(govno[--govnopoindex]);
} while (govnopoindex != 0);
}
char *concat(char *a, char *b)
{
char *ptr = malloc(strlen(a)+strlen(b)+4);
if (ptr == NULL)
{
fprintf(stderr, "Huli ty obosralsya, mudak blyad? Ves' heap zasral\n");
chisti_govno(); // иди под струю мойся
exit(-1);
}
sprintf(ptr, "(%s*%s)", a, b);
govno[govnopoindex++] = ptr;
return ptr;
}
char *pow_gen(size_t n, char *a, char *p)
{
if (n == 0)
{
return a;
}
if (n & 1)
{
return pow_gen(n >> 1, concat(a, p), concat(p, p));
}
else
{
return pow_gen(n >> 1, a, concat(p, p));
}
}
char* pow_b2(size_t n) {
return pow_gen(n, "1", "a");
}
void printfshit(const size_t pow)
{
printf("double pow_%zu(double a) {return %s;}\n\n", pow, pow_b2(pow));
}
int main(void)
{
printfshit(255);
chisti_govno();
return 0;
}
j123123 10.08.2017 14:22 # 0
Портировалось довольно легко.
Скажите, а в плюсовых шаблонах только через хвостовую рекурсию можно долбиться, циклов не завезли?
Antervis 10.08.2017 16:59 # 0
j123123 14.08.2017 11:48 # 0
Antervis 14.08.2017 13:21 # 0
bormand 10.08.2017 19:06 # +2
А если добавить к шаблону параметр T вместо double, то и портировать ничего не надо. Достаточно подсунуть структуру с operator* который делает concat.
roman-kashitsyn 10.08.2017 19:17 # +2
Это потому что быстрое возведение в степень работает для любого моноида.
j123123 11.08.2017 09:59 # 0
Кстати, да. Говно с шаблонами еще и в том, что в качестве шаблонного параметра нельзя передавать плавучего питуха.
bormand 12.08.2017 18:41 # 0
Побоялись специализации шаблонов по плавучке, походу.
inkanus-gray 13.08.2017 11:36 # +3
j123123 11.08.2017 17:07 # +1
И вообще, в кодогенератор надо бы запилить мемоизацию какую-нибудь, и стековый аллокатор поверх одного malloc и потом дергать realloc() и расширять, и чтоб потом одним free() его чистить, но мне пофиг.
А в плюсовых компилтайм-шаблонах кстати есть GC? В компилятор встроили сборщик мусора для шаблонной метушни?
bormand 11.08.2017 19:40 # +1
Там следуют заветам PHP: "вот конпеляция закончится - освобожу всю память за раз".
inkanus-gray 11.08.2017 23:53 # 0
http://php.net/manual/ru/function.gc-enable.php
Только никто не проверял, работает ли она реально. Всё равно же процесс сдохнет после завершения обработки запроса (PHP в режиме демона почти никто не использует).
sos 12.08.2017 00:08 # 0
inkanus-gray 12.08.2017 00:48 # 0
j123123 12.08.2017 08:00 # 0
Если надо каким-то образом явно отмечать более не используемые переменные, то зачем тогда GC? Можно с тем же успехом руками мусор собирать через что-то вроде free()
bormand 12.08.2017 15:35 # +1
inkanus-gray 13.08.2017 11:31 # 0
Правильно будет так: если объект больше не нужен, то переменной, которая его держит, нужно присвоить новое значение, например, null (или вызвать unset).
Хотя это не всегда требуется: если объект держит локальная переменная функции, то она исчезнет после выхода из функции. Обнулять переменную есть смысл только в том случае, если хочется собрать мусор чуть пораньше, чем функция завершится.
j123123 15.08.2017 11:00 # +1
Но ведь по своей сути это является тем же говном, что и говноплюсовый std::shared_ptr
http://ru.cppreference.com/w/cpp/memory/shared_ptr :
> std::shared_ptr – умный указатель, с разделяемым владением объектом через его указатель. Несколько указателей shared_ptr могут владеть одним и тем же объектом; объект будет уничтожен, когда последний shared_ptr, указывающий на него, будет уничтожен или сброшен.
И, как вы понимаете, само по себе это не является GC. Та же Java при сборке мусора поступает значительно умнее, там есть механизмы обнаружения циклических ссылок
Хотя вот в PHP такое тоже есть http://php.net/manual/ru/features.gc.collecting-cycles.php
Но, как представитель старой школы, я считаю что все это является полным говном, замедляющим выполнение вашей компьютерной программы, к тому же это мешает реалтаймовости (для пхп очень актуально).
j123123 15.08.2017 11:07 # 0
Вот представьте, вы там выделили где-то память и создаете на нее некоторое количество особых указателей, и когда все указатели будут сброшены в ноль, то тогда эта память освободится. Вроде бы отличная идея, не правда ли? Ан нет, идея-то говно! Это может иметь какой-то смысл только лишь в том редком случае, когда вы не знаете(и не можете никак отследить) на этапе компиляции, какие указатели указывает на этот самый выделенный кусок памяти в конкретный момент времени, и когда(при каких обстоятельствах) этот кусок памяти будет попросту не нужен, и указатели более не используются. Если вы можете точно выделить момент времени в своей компьютерной программе, когда гарантированно ни один указатель не будет указывать на некоторый регион памяти, так тогда вот втулите туда этот самый free(). А это смрад-поинтерное говно под названием std::shared_ptr создано явно для каких-то заедушных анскиллябр, не могущих точно определить время жизни объекта, не втуливая в рантайм какие-то говнокостыли с говноподсчетом ссылкок
sos 15.08.2017 11:26 # 0
roman-kashitsyn 15.08.2017 11:31 # +3
Оторвись уже от своего восьмибитного говна и осознай, что есть процессоры с более чем одним ядром.
shared_ptr нужен редко, но без него было бы грустно. К примеру, он очень кошерен, когда нужно заспаунить N тредов, которые читают один read-only кусок данных, причём у них есть таймаут, в течение которого мы ждём от них ответа, и последний должен за всеми почистить.
Или когда пишешь асинхронную лапшу на бустасио.
Если тебе приятно самому с рефкаунтами пердолиться, иди пиши сишные модули на питоне, там люди, похоже, только тем и занимаются, что утечки устраняют, рассыпая инкрефы и декрефы в нужных местах. Вот прям любой changelog открой, там в каждом релизе где-нибудь лик починен.
> И, как вы понимаете, само по себе это не является GC.
Никто и не говорит, что это GC, откуда ты это взял? GC полезен не столько для сбора циклов (эту проблему можно самому решить, если продумать жизненный цикл), сколько для компактификации кучи.
sos 15.08.2017 11:52 # 0
roman-kashitsyn 15.08.2017 12:21 # +1
"основная" фича или "не основная" — это дело вкуса.
Висячие ссылки — это по сути баги, если их нет, то и ГЦ становится "не нужен". Конечно, в асинхронной лапше довольно сложно всё аккуратно сделать, но вполне реализуемо (хоть ГЦ и немного удобнее).
А вот компактификацию самому сложно сделать. Фрагментация может быть высокой даже в "корректных" программах. Можно, конечно, писать царские слаб-аллокаторы или жонглировать аренами, но если можно позволить себе жить с ГЦ, то почему бы и нет.
sos 15.08.2017 12:23 # 0
roman-kashitsyn 15.08.2017 12:44 # +1
Почти у всех рядовых пользователей GC она и так есть.
Если пишешь нагруженный сервер на плюсцах, то одно неверное движение (какой-нибудь lexical_cast<int> в цикле [1]) может заставить его подтекать на гигабайт в день, в итоге он будет временами крэшиться, жрать цпу и мешать спокойно спать по ночам.
Поэтому люди, которые пишут нагруженные программы с кучей аллокаций (редисы, файрфоксы, фейсбуки, гуглы), так любят jemalloc — там довольно много усилий приложили, чтобы избегать фрагментации.
[1] https://www.facebook.com/notes/facebook-engineering/chat-stability-and-scalability/51412338919/
defecate-plusplus 15.08.2017 12:34 # 0
Причем, любое, даже старое сраное приложение не одноразового однозадачного запуска - это ивент луп в бесконечном цикле. Практически любая ембедщина - это сука 100% ивент луп, т.к. ему надо работать 24/7.
Асио и есть ивент луп, только в правильной, современной форме (господи, ему уже за 10 лет, пиздец какой современный). Где не имеется ровно 1 основной тред на обработку всех сраных событий, хранящихся в глобальных переменных (держу пари, я прямо в точку попал, да, j123123?), и когда все прочие задачи виснут к хуям, пока текущая подпрограмма не закончит свою работу и не попустит поток исполнения.
Я знаю почему пригорает у неосилятора.
Просто есть вычислительные платформы, где есть инструменты и возможности (компиляторы и ядра), а есть дерьмо 20 летней давности, где только на сишке, работающей в одно щячло, и можно писать.
sos 15.08.2017 12:47 # 0
Почти никогда не использую ио_сервис в многопоточном режиме (только если вместо тредпула). И все примеры, что видел - забагованная лапша из страндов. Наблюдал несколько случаев, как люди переходят к модели один ио_сервис - один поток.
defecate-plusplus 15.08.2017 13:05 # 0
Ибо мне нечего возразить, кроме "наверное, попробуйте ещё раз".
Стоит начать с квадратиков, из которых стрелочки идут в другие квадратики, инфа 100%.
Ладно, это было невежливо.
Странды - грубо, точки скрещивания нескольких потоков. Если у вас там лапша, то не странды виноваты. Если от многопоточной модели ушли в однопоточную, то либо многопоточная оказалась не нужна (ну так бывает, бесспорно), либо не смогли в (что совсем не означает, что многопоточная не будет работать, а как раз означает, что пришлось прибегнуть к пессимизации в угоду подпирания получившегося уродца). Иногда в последнем случае помогает больше практики в решении стандартных ситуаций (сужу по личному опыту обучения падаванов асио, у всех всё получается рано или поздно).
sos 15.08.2017 13:28 # 0
> Странды - грубо, точки скрещивания нескольких потоков.
Странд - это асиошный способ сделать поток выполнения. Самый хуевый из возможных, т.к. допускает миллион способов отстрелить себе ногу. Неудачный костыль, не более.
defecate-plusplus 15.08.2017 13:53 # 0
Но классические примеры не мешают делать нормальные универсальные приложения на тех же принципах - единый иосервис, единый пул тредов (например, 10), все порождаемые задачи (разные по сути) работают в указанном пуле. Вообще крайне здраво проектировать и писать софт так, чтобы он не рожал кучу потоков, не занимающихся ничем, а исполняющейся задаче было поебать работает она в пуле из 1 треда или из 100. Это, как сказать, хорошо влияет на масштабируемость и ресурсопотребление.
Странд - очередь задач исполнения, есть быть точным. Ты можешь пользоваться этой вещью только тогда, когда ты действительно хочешь получить гарантию непараллельного выполнения двух порождённых тобой подзадач, и не пользоваться всё остальное время. Вместо этого "неудачного костыля" ты мог бы писать царские блокировки, заставляя параллельный поток простаивать, или пессимизировать в однопоточный ио-сервис (потому что так проще и не надо включать голову).
subaru 15.08.2017 14:22 # 0
Как раз в этом случае нет никаких причин городить общую очередь задач на несколько потоков, а можно раскидывать задачи по нескольким иосервисам.
> 100 потоков для 10к в самый раз.
Ну а у меня демон с 50 потоками держит полмиллиона соединений. Иосервис на поток - пирфомансней.
> делать нормальные универсальные приложения на тех же принципах - единый иосервис, единый пул тредов
И ебаться с датарейсами из-за забытого странд.врап.
> Ты можешь пользоваться этой вещью только тогда, когда ты действительно хочешь получить гарантию непараллельного выполнения двух порождённых тобой подзадач, и не пользоваться всё остальное время
Нет. В асио единственный тредсейфный класс - иосервис. Все остальное можно трогать только из странда.
defecate-plusplus 15.08.2017 15:10 # 0
энивей, мы уклонились от темы shared_ptr для питухов
j123123 15.08.2017 13:00 # 0
Нахреначь примитивную недоос с недопланировщиком через прерывания от таймера, и будет тебе счастье.
defecate-plusplus 15.08.2017 13:15 # +2
Я где-то недавно оставлял камент, чем я занимался в юности.
Там тоже была "недоос" с подобной вытесняющей многозадачностью, весила килобайт 100 наверное.
Бывает ещё кооперативная, где задача должна сказать sleep() или ещё какую-то хуйню (ладно, "wait for some activity" обычно), чтобы недоОС могла её переключить на другую.
Похоже на детские трёхколёсные велосипеды. Пока мимо пролетают технологичные машины с автопилотом.
Antervis 15.08.2017 13:49 # 0
j123123 15.08.2017 13:57 # 0
Видишь ли. Я не "не могу" осилить плюсы. Я просто не хочу их осиливать, т.к. чем больше я узнаю плюсов, тем больше я вижу в них говна и хренового дизайна. Это было очень плохой идеей, делать из языка Си подобие высокоуровневого языка. Нужно делать другой нормальный высокоуровневый язык, или ждать его появления
https://i.imgur.com/jBoAChW.png
subaru 15.08.2017 14:25 # 0
j123123 15.08.2017 15:05 # 0
Язык C++ же позиционируется, насколько я понял, как некий мультипарадигменнный высокоуровневый язык общего назначения, который к тому же и не запрещает низкоуровневую байтоеблю. Но высокоуровневые фичи плюсов по сравнению с нормальными языками высокого уровня (вроде LISP или какого-нибудь хаскеля, ерланга) являются просто таки абсолютнейшим говном и отстоем.
См. также: http://govnokod.ru/20947#comment348009
j123123 15.08.2017 15:12 # 0
Я не ненавижу ни то, ни другое, но мне это не мешает считать эти языки говном.
Проблема C в убогом препроцессоре с убогими макросами, негомоиконности, отсутствии механизмов метапрограммирования, обобщенного программирования. Язык слишком низкоуровневый, на нем не очень-то удобно писать что-то большое. Низкий уровень абстракции.
Проблема C++ в том, что C++ это убогая и кривая говнонадстройка над C которая задумывалась для того, чтобы добавить всякую высокоуровневую питушню. Притом если взять тот же прием метапрограммирования на шаблонах, то плюсовые шаблоны изначально не задумывались для того, чтобы на них занимались метапрограммированием, считали в компилтайме числа Фибоначчи и прочей ебанистикой. У Мейерса именно так и написано, что метапрограммирование шаблонов (template metaprogramming – TMP) было именно открыто, никто изначально в языке это не задумывал:
> C++ не предназначался для метапрограммирования шаблонов, но с тех пор, как технология TMP была открыта в начале 90-х годов, она оказалась настолько полезной, что, вероятно, и в сам язык, и в стандартную библиотеку будут включены расширения, облегчающие работу с TMP. Да, TMP было именно открыто, а не придумано. Средства, лежащие в основе TMP, появились в C++ вместе с шаблонами. Нужно было только, чтобы кто-то заметил, как они могут быть использованы изобретательным и неожиданным образом.
Ну т.е. тупо взяли заменитель препроцессора, и начали им считать всякие Фибоначчи и прочую срань.
Ах да, потом еще придумали всякую херню, типа constexpr-ов, которые типа считаются на этапе компиляции, но это такое говно, что мне даже лень повторяться, в этих constexpr-ах всю херню надо возвращать через return, нельзя юзать malloc, memcpy и прочую хрень, которая не вписывается в этот навязываемый языком говнофункциональный стиль. http://govnokod.ru/19105#comment307730
j123123 15.08.2017 15:13 # 0
defecate-plusplus 15.08.2017 15:17 # 0
И да, как будто если начал писать на крестах, то сразу надо обмазаться параметрическим полиморфизмом и компайл-тайм оптимизациями, вместо того, чтобы хотя бы воспользоваться пользой RAII, которой нет в сраной сишке?
j123123 15.08.2017 15:31 # 0
Как если бы у меня было бы две точки входа, и одна точка входа выполнялась бы "во время компиляции". И malloc-нутая из той точки входа память может быть передана особой зарезервированной функции, и тогда эта память будет использована для инициализации некоего статического массива, который уже будет внедрен в исходный код на следующей стадии компилирования(когда компилтайм-кодо/данно-генерация закончится), и использоваться нормально-скомпилированной программой как обычный проинициализированный массив.
defecate-plusplus 15.08.2017 15:38 # 0
мы ведь снова обсуждаем таблицу косинусов?
j123123 15.08.2017 15:46 # 0
defecate-plusplus 15.08.2017 18:41 # +1
https://godbolt.org/g/TVZg28
j123123 15.08.2017 19:46 # 0
j123123 17.08.2017 17:10 # 0
И вообще, на кой хер в таблице синусов хранить синус где-то дальше чем от 0 до pi/2 ? Ведь дальше можно все это говно отзеркаливать
defecate-plusplus 17.08.2017 17:40 # 0
j123123 17.08.2017 18:53 # 0
Antervis 17.08.2017 19:33 # +1
j123123 17.08.2017 22:39 # 0
Нужно построить таблицу синусов, но построить ее надо очень оптимально. В областях, где график синуса хорошо приближается прямой линией(т.е. мы должны задавать, какие нам допустимы погрешности), не будут непрерывно тыкаться точки в таблицу поиска. Фактически, таблицы поиска в привычном смысле не будет, будет if, который проверяет интервал, и по линейной формуле считает это говно.
Вот когда тупо делаем таблицу поиска, например синусов от 0 до pi/2 с шагом pi/128 то там тупо будут равномерно идти все это говно, ну типа в таблице будет значение синуса sin(0), sin(pi/128), sin(2pi/128) ну и таким вот макаром эта хуита шагает одинаковыми шагами вплоть до sin(pi/2). Но на деле-то такая хуйня нахуй не нужна, можно эти злоебучие точки расставить таким образом, чтоб между ними была практически прямая, ну типа считаем для заданных допусков(погрешностей) что между sin(0) и sin(30pi/128) график функции меняется настолько линейно, что можно не хреначить кучу точек sin(1pi/128) sin(2pi/128) sin(3pi/128) sin(4pi/128) а тупо хуйнуть интервал через if(плавучка < 30pi/128) {вот_тебе_уравнение_прямой_считай_по_ней ();} и вот так всю эту парашу можно разбить на такие сраные фрагменты, это блядь называется кусочно-линейная интерполяция/аппроксимация http://eelib.narod.ru/toe/Novg_2.01/29/Image353.gif https://files3.vunivere.ru/workbase/00/04/01/95/images/image001.gif или адаптивная дискретизация http://peredacha-informacii.ru/images/adaptivnaja-diskretizacija02.gif
в общем суть этого говна чтобы приблизить кусок синуса кучей прямых на разных, еби его в рот, интервалах, и чтобы при этом выполнялось условие того, чтоб погрешность этой еботни не превышала определеного значения. Кто-нибудь в здравом уме будет подобную поеботу писать на говношаблонах?
j123123 17.08.2017 22:48 # 0
sos 17.08.2017 23:19 # 0
Antervis 18.08.2017 14:33 # 0
Погоди, ты вот что скажи. Линейная аппроксимация синуса уместна в рантайме, если есть подготовленная табличка синусов недостаточной точности. Зачем на шаблонах делать таблицу через линейную аппроксимацию если можно загонять туда точные значения? А если хочешь аппроксимировать в рантайме, то таблица генерируется шаблонами очень и очень легко
j123123 18.08.2017 15:45 # 0
Очевидно же, что линейная аппроскимация между двумя точками должна делаться уже в рантайме, а задача шаблонов-констэкспров заключается в том, чтобы создать множество опорных значений, между которыми будет эта самая линейная аппроксимация работать, и эти опорные значения вшить в некий нагенеренный код, который будет работать как двоичный поиск
Короче, вот тут в говноинтерпретаторе питона наанроллен двоичный поиск через ифы
похожую хрень через проверки диапазонов флоатов сделать, и чтоб оптимально, за O(log n) проверок чтоб было
j123123 18.08.2017 15:47 # 0
И анролл из цепочек if-ов тоже легко делается?
Antervis 18.08.2017 19:19 # 0
bormand 18.08.2017 19:21 # 0
Он хочет неравномерный шаг, чтобы и точность набрать и слишком много опорных точек не юзать.
Antervis 18.08.2017 19:35 # 0
j123123 18.08.2017 07:33 # 0
j123123 18.08.2017 09:06 # 0
j123123 18.08.2017 09:12 # 0
defecate-plusplus 18.08.2017 10:50 # +2
Ты не поверишь, но 99.9999% программистов в жизни нахер не сдалось рассчитывать таблицу косинусов переменного размера.
А если и сдастся - врядли они это будут делать на крестошаблонах и констэкспрах только лишь потому, что могут, они же не коты.
И всё вышеописанное не означает то, что отныне крестошаблоны не нужны никому, ведь с ними было неудобно (хоть и возможно!) решить задачу генерации в компайл-тайме твоей специфичной задачи.
И да, при различных переменных алгоритмах, которые ты тут рассказывал (деление круга на неравномерные части для получения лучшей/худшей точности на некоторых участках) как раз шаблоны выиграют тем, что у тебя непосредственно знания о способе деления круга будут лежать в одном месте, а не будут размазаны по нескольким модулям (одним на питоне, который дёрнется во время компиляции, а другим - в приложении, когда настанет необходимость обращаться к этой посчитанной вундервафле).
j123123 18.08.2017 12:35 # +1
Бред. С тем же успехом я могу куски кодогенератора каким-то хитрым образом вкорячивать в сишные комментарии, и потом особой херней препроцессировать подобный бред, и чтоб на месте комментов выплевывался нужный код.
И подобная херь уже есть, например https://nedbatchelder.com/code/cog/ http://re2c.org/examples/example_01.html
roman-kashitsyn 18.08.2017 12:40 # +2
Вот радость-то будет отлаживать сишные комментарии по выхлопу кодогенератора. Сложно придумать что-то хуже отладки плюсовых шаблонов, но ты смог.
j123123 18.08.2017 12:46 # +2
defecate-plusplus 18.08.2017 20:00 # 0
Например, устраивать ошибку компиляции на N шаге.
Можно даже троллейбус.
Иногда (такое случается крайне нечасто, конечно, это скорее признак крайне застарелых парадигм, неуместных для беседы благородных донов) программист пишет крестошаблон, потому что ему нужен полиморфизм, а не число фибоначчи.
Не умеешь использовать астролябию - не используй.
> каким-то хитрым образом вкорячивать в сишные комментарии
ЛЯМБДЫ В ЖАБЕ НЕНУЖНЫ, НО КОГДА НУЖНЫ, Я ВКОРЯЧИВАЮ КОДОГЕНЕРАТОР
j123123 19.08.2017 14:03 # +1
Да как такое вообще кому-то могла прийти в голову столь крамольная мысль? Ведь настоящие программисты на C++ едят котлеты ложкой, суп вилкой, рубят пилой, пилят топором, микроскопом забивают гвозди, а молотком... молотком себя херачат по голове, уничтожая остатки мозгов
inkanus-gray 19.08.2017 21:49 # 0
roman-kashitsyn 19.08.2017 21:54 # 0
Ну хз, я бы написал «ЗАБОР»
roman-kashitsyn 22.08.2017 13:11 # +2
Хотя, «МЕЛ» тоже вполне подходит, если инвертировать картинку, т.е.
inkanus-gray 22.08.2017 16:55 # +1
Да, через сквозные дырки проступал мусор.
roman-kashitsyn 22.08.2017 16:56 # +2
Хм, тоже логично, ведь именно это можно увидеть сквозь получившиеся дыры.
123123123 18.08.2017 12:53 # +1
j123123 15.08.2017 12:55 # 0
И как ты предлагаешь из кода, утыканного этими shared_ptr выкинуть их все к херам, если я этот код хочу запускать на процессоре с одним ядром и без гипертрединга, но не хочу получать совершенно нахер не нужный оверхед от shared_ptr?
>shared_ptr нужен редко, но без него было бы грустно...
Мне вот почему-то кажется, что его чаще используют как недоGC (пусть там вот само находит, когда этот кусок можно освобождать) а не как какой-то вспомогательный механизм для многопоточности. К тому же нормальных контейнеров, которые были бы thread-safe не только на чтение, в плюсовой стандартной библиотеке попросту нет. Как и асинхронщины. Это все надо тащить из буста или другого внешнего говна
>Никто и не говорит, что это GC, откуда ты это взял?
Но сходные черты есть. Это не GC, это огрызок от GC.
Antervis 15.08.2017 14:07 # 0
Кажется ему... Когда работаешь в однопоточной среде, для отслеживания времени жизни объекта хватит и unique_ptr, и то больше для корректности исключений и early return.
> И как ты предлагаешь из кода, утыканного этими shared_ptr выкинуть их все к херам
в однопоточном приложении - то? автозамена shared_ptr -> unique_ptr и в местах где "не могу скопировать unique_ptr" организуем move или передачу по ссылке (смотря что надо).
> Но сходные черты есть. Это не GC, это огрызок от GC.
ты не понимаешь как работает shared_ptr или ты не понимаешь как работает GC?
j123123 15.08.2017 14:26 # 0
unique_ptr это довольно примитивная по своей сути ерунда, которая мне попросту не нужна. Мне вполне достаточно моих мозгов и обычных malloc()/free() для такого, т.е. не нужно вообще вводить понятие "владение", "область видимости" и тому подобной хуйни, а просто достаточно пересылать сырой указатель и освобождать его, когда настанет нужный момент.
>в однопоточном приложении - то? автозамена shared_ptr -> unique_ptr и в местах где "не могу скопировать unique_ptr" организуем move или передачу по ссылке (смотря что надо).
Т.е. это мне все руками надо делать, да? Ну отлично!
>ты не понимаешь как работает shared_ptr или ты не понимаешь как работает GC?
shared_ptr это хрень для подсчета ссылок. Когда что-то там не ссылается на объект, мы декрементируем некую хрень. В GC тоже реализован механизм подсчета ссылок, и работает там эта хрень таким же образом.
Antervis 16.08.2017 07:20 # 0
с обычными malloc/free надо освобождать ресурсы ручками в каждой точке выхода из функции. Поэтому сишники городят всякие goto и седьмой уровень вложенности if'ов на ровном месте
bormand 16.08.2017 07:58 # 0
З.Ы. Причем каждый сищник искренне верит, что он то точно знает, когда настанет "нужный момент".
Antervis 16.08.2017 08:34 # +1
Antervis 15.08.2017 14:09 # +1
оптимизации для GC придумали уже потом. Основная задумка была чтобы у анскиллябр код не тек и не вылетал после попыток эти течки исправить.
CHayT 15.08.2017 14:33 # +1
- В драйверах/бутлоадерах
- В имбеддщине
- В uber-highload-hard-realtime-zero-latency питушне
Но это весьма редкие задачи. Среднестатистический гцхейтер ничего подобного не пишет, что превращает гцхейтерство в фарс.
subaru 15.08.2017 14:39 # 0
roman-kashitsyn 15.08.2017 14:53 # 0
Можно же финализаторы аттачить
subaru 15.08.2017 14:57 # 0
roman-kashitsyn 15.08.2017 15:00 # +1
Не факт — сначала должно кончиться место. А если все в дедлоке, то оно может и не кончиться...
К тому же, мутекс обычно можно отпускать только из того же треда, который этот мутекс захватил.
CHayT 15.08.2017 15:01 # 0
roman-kashitsyn 15.08.2017 15:04 # 0
CHayT 15.08.2017 18:44 # 0
roman-kashitsyn 15.08.2017 18:51 # 0
Примитивно, но эффективно. Не увеличивает уровень вложенности кода, и случайно забыть освободить ресурсы сложно.
CHayT 15.08.2017 18:56 # 0
Не спорю.
roman-kashitsyn 15.08.2017 18:59 # 0
Опять же, примитивно, если есть замыкания. В сраных сишках обычно такого нет.
subaru 15.08.2017 19:29 # 0
roman-kashitsyn 16.08.2017 10:44 # +2
Честно говоря, до того, как в языке появились rvalue-ref и мув-семантика, в плюсах это тоже не очень весело было делать.
roman-kashitsyn 15.08.2017 14:34 # 0
Основная задумка была чтобы можно было написать
и не думать, где размещать промежуточные результаты
j123123 17.08.2017 16:22 # 0
Компактификация кучи (дефрагментация хипа) может быть реализована и без GC, см. http://govnokod.ru/18748#comment369745
Т.е. сырые указатели на куски выделенногй в хипе памяти, когда они есть, должны блочить дефрагментацию (чтоб не сломать все нахрен) или просто не позволять дефрагментить (двигать) конкретно тот кусок, на который есть сырые указатели. Надо отследить моменты, когда никаких сырых указателей на маллокнутую память нет, и тогда дефрагментировать.
roman-kashitsyn 17.08.2017 16:26 # 0
> можно запускать особую хрень, которая ... переутрамбовывает(дефрагментирует) это все плотным куском
Тот же троллейбус, только из буханки.
j123123 17.08.2017 16:27 # 0
roman-kashitsyn 17.08.2017 16:59 # 0
К примеру, веб-сервер может аллоцировать единый кусок памяти (2-4 МБ, к примеру, но царь лучше знает, сколько памяти нужно его программам) для обработки каждого запроса, и использовать этот кусок для аллокаций всех объектов в рамках запроса. А когда запрос обработан, можно дропать всю арену целиком.
cykablyad 13.08.2017 15:22 # +2
Почему залогиненный гк работает хуевее, чем разлогиненный?
inkanus-gray 13.08.2017 15:41 # +2
bormand 13.08.2017 15:44 # 0
inkanus-gray 13.08.2017 15:50 # 0
cykablyad 13.08.2017 15:54 # 0
inkanus-gray 13.08.2017 19:59 # +2
Хорошо, что у меня пароль 456.
CHayT 13.08.2017 21:39 # 0
cykablyad 13.08.2017 15:44 # +1