- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
// почему это гавно не будет работать?
auto size = buffer.size() - 1;
auto *ptr = new byte[size];
for (auto i = size; i >= 0; i--)
{
ptr[i] = 0;
}
// a это гавно будет работать :)
auto size = buffer.size() - 1;
auto *ptr = new byte[size];
for (int i = size; i >= 0; i--)
{
ptr[i] = 0;
}
Follow us!
А так да, камешек в огород любителей беззнаковых значений.
Весело будет, если size() вернёт когда-нибудь 0
вроде, туда ходить можно, а разыменовывать нельзя, не?
или это тока для указателей
впрочем, лунь туда один хуй пишет
Массив маловат.
< size = -1
> new byte[ -1];
< говно
вообще, ауты нужны, чтобы параметризованные итераторы не выписывать. А для простых типов я бы его не
template<typename T> example(T t) { T::value_type x = t[i]; } → example(T t) { auto x = t[i]; }
auto example(auto t) { decltype(t[i]) x = t[i]; }
unsigned int i = 0;
i--;
равен ли он теперь MAX_INT?
тогда он прав
So the minimum maximum value that size_t must be able to hold is 65535, which is 16 bits of precision, and size_t is only defined to be an unknown unsigned integer type.
Какой анскилл )))
З.Ы. Вроде ещё что-то типа такого можно, но я не уверен:
Борманд: да хуй знает, не юзал ни разу
--А разве не RC, как в ObjC?
-- нет, это у вас в джаве ручное управление ресурсами
https://stackoverflow.com/a/8191493
-- У вас вообще его нет
самое печальное с жабой и другими мейнстримовыми языками без управления памятью - что сервисы для перемалывания больших данных, запросов, etc. пишут именно на них, а вот ограничить сверху расход памяти конкретным запросом/джобой невозможно, и потому какие circuit breaker'ы не ставь, всё равно рано или поздно не успеешь отловить OOM,
Именно поэтому у меня есть очередная NIH-мечта - выкинуть нахуй Lucene и написать всё по-человечески на сишке.
По-царски.
Хм, а CLucene это не то?
Тут конечно можно сказать: зачем форкаться, если можно создать новый процесс? А новый процесс это инициализировать новую вм ахаххаха опять весь пирформанс в пизду.
Ну если хорошенько прогреть, чтобы всё проджитилось, gc несколько раз отработал и убрал всю статику в олдфажное поколение, вроде должно норм получиться.
Форк насрёт в быстрое поколение и сдохнет, а жирный общий контекст останется расшаренным.
Кстати, как ты это сделаешь в винде?
хз, я просто не знаю достаточно про винду, только про то что ты имеешь в виду что там вместо fork-exec StartProcess, который ничего не шарит
В никсах ты делаешь fork, получая копию себя (благодаря корове очень дешевую), а потом ты делаешь exec поверх если хочешь.
В пинде ты явно запускаешь новый процесс.
Конечно, если ты перезапускаешь то, что уже есть в памяти, то винда может постараться переиспользовать странички c кодом, но я не ебу что там с джитом будет.
А вместо fork там потоки.
зы: Борманд наверняка знает
Заново джитить всё будет.
Цыгвин как-то пытается "форкнуть" процесс на венде (через явное шаред мемори?) но там куча проблем с этим, это вообще не продакшен-реди.
https://github.com/elastic/elasticsearch/issues/70522
нафоркай себе сколько-то долгоживущих процессов, создай direct buferы в обычной памяти заранее заданного размера, и не вылазть за них
placement new в жову не завезли, так что придется тебе вместо объектов массивами оперировать, как Царь
и не будет никакова GC
не пробовал его?
Зачем бороться с тем, что тебе не подходит?
Выкини, да возьми другое.
Управляемая куча говна не лучший инструмент для высокоперформансного хайлоада бигдаты
Именно поэтому я за кресты. Там говно на любой вкус есть. Даже gc и jit при желании.
Комплайт-тайм рефлексию и кодогенерецию вот дождаться осталось...
> Выкини, да возьми другое.
тут мы возвращаемся к исходному сообщению
> самое печальное с жабой и другими мейнстримовыми языками без управления памятью - что сервисы для перемалывания больших данных, запросов, etc. пишут именно на них
нету другого эластика и другого люсина
> Partitioning is done manually.
дальше уже и читать смысла особо нет
на крестах
CLucene протух, получается? Какая-то уж больно древняя версия у него по сравнению с настоящим.
Он сам: https://govnokod.ru/27121#comment596876
Т.е. "PHP" всё-таки не говно, раз его основной принцип перенесли в жабу?
https://www.codejava.net/java-ee/jstl/jstl-sql-tag-query
Не нужен, да.
warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
for (size_t i = 0; i < pidor_v.size()-1; ++i) { // итерируемся до предпоследнего
Хотя со знаковым числом этой фигни бы не было, конечно.
со знаковым я бы получил -1, а 0 не меньше -1, и все кончилось бы хорошо, не?
Кампутир сайенс положил семантику на лопатки
for (size_t i = 2; i < pidor_v.size(); ++i) {
. . . . auto j = i - 2;
Ладно, побежал дальше писать работающие программы на unsigned вычислениях, а вы продолжайте хуесосить ЛУЧШЕЕ, что когда либо было создано в программировании ;)
if (size - 1 > 0)..
нужно было делать как с указателями: чтоб вылазить за пределы ( в отрицательные значения ) было можно, а обращаться по ним нельзя
Кстати тут даже ворнинга не будет.
Вдруг мои вкусы специфичны, и я именно это и хотел написать?
а если бы я сказал size = -1, то что бы случилось? unsigned превратился бы в signed?
Наоборот же. Будет 0xFFFFFFFFu - 4u > 0u.
помню тока, что операторы любят, чтобы операнды были одинакового типа)
вообще имплиситный каст есть говно, и лучше бы его не было
Сначала мелочь меньше инта кастится в int. Затем, если получились типы разного размера, то кастится в больший из них. А если одного -- то в беззнаковый.
думаю, питухи расширятся до обычного инта, до знакового.. но нужно смотреть стандарт
блядь
там же создасца временная переменная и будет наоборот: вызовеца unsgined, а мог бы и вообще какой-нить float?
Перегружать можно только то, что друг а друга не расширяется неявно
https://i.kym-cdn.com/entries/icons/original/000/000/063/Rage.jpg
Ну и отсутствие явно неправильного значения -1, которое можно использовать как пустой результат (например, при поиске) - скорее, недостаток.
И однажды он написал написал код
а потом код стал тормозить, и он решил переписать его кресты. Угдай, что случилось?
С другой стороны, а вдруг нам действительно нужен массив ровно в 64к. Язык должен это поддерживать, чай не скриптушня. Для каких-нибудь std::vector можно было и ограничить размер: хотите странных размеров, создавайте массив ручками, обойдетесь без классов. В Qt, например, так и сделали, для прикладнухи этого достаточно. Но sizeof(char[64*1024]) же должен что-то возвращать. А, значит, конструкция типа int i = 16; if (i < sizeof(SKurochka) {...} уже будет потенциально опасной, даже если у меня в программе больших структур вообще нет, чего ругаесся, насяльника. В общем, сложно сказать.
Ну вот жабаеб может состнуть (и шарпей наверное тоже) даже на x64 системе.
Однако будем честны: всем хватит 2^32 байт. Если не хватит, то нужно делать анонимный ммапинг файла, а не пхать массив.
Нихватает. Всего 4 ГБ.
> Если не хватит, то нужно делать анонимный ммапинг файла, а не пхать массив.
Тут проблема не в массиве, а в адресации.
Но я не припомню ос, которая разрешила бы замапить кусок памяти размером в 2^64.
для пустого массива будет бугурт
А всё потому что это был чистый концентрированный на сто процентов свободный интернет.
Нынче такой интернет не делают, всё разбавлено цензурой, вот и продают за бесценок.
В моем детстве Интернет по карточкам в метро продавался. Бывало купишь свежую карточку, и пока домой со школы бежишь -- всю и съешь...