Сломал мозг

Киллер, а че ты пишешь-то вообще? Расскажи, я тоже буду писать. А то каникулах делать нефиг.

А теперь скажи мне почему результат мало не магическое значение?

Маллок после определённого значения тупо начинает юзать ммап, дак вот ммап отвалится не может.

Он может отвалится с номем по нескольким причинам - моё значени не адекватно, а оно уменя всегда адекватно. Я напоролся на лиммиты по паппингу. Если я буду буду одновременно ммапить тысячи раз - я это учту.

Адресы, которые даёт ммап никак не связаны с оперативной памятью и следить по нулу за окончанием оперативы не можешь. Слить 48бит адресов ты тоже не можешь.

Если ты хочешь жрать память и не быть убитым оомкиллером - тебе надо один фиг писать обёртку над ммапом, но это не нужно, ибо проще быть убитым ООМкиллером.

В системе может не быть оверкоммита, дубинушка.

Такое поведение маллок одинаково верно для всех версий линукс и для всех поддеживаемых линукс архитектур?

Ты не осилил принтф, но осмелился обвинять меня? В этом ваша бида.

Я то осилил printf, а вот ты - нет.

Если его нет - я рад. Если кто-то поставил двойку - его проблемы и клал на него, ибо нехрен менять то, о чем ты не шаришь.

И да, мне проще чекнуть систему на наличие плодов анскильных ущербанов, чем юзать какие-то ненужны хрепоймичего проверки.

Маллок после определённого значения тупо начинает юзать ммап

Который маллок? А то их много. В каждой системе - свой велосипед. У них только интерфейс общий, который в манах описан (но ты их не читал, да).

Да, а на исключениях твой код работать не будет, ибо он тормазное говно.

Ну а теперь, гореосилятор мой, объясни мне как свазана строка форматирования и аргументы?

Правильно - никак, архументо управляет конпелятор и засунь ты туда хоть что - оно будет работать.

Строка форматирования отвечает за форматирования, если я напишу %u на uint64_t значения которого больше 32бит - оно просто не нарисует циферки из битов выше 32-го.

Без разницы в какой системе, но строка форматирования никак не влияет на аргументы, так же как аргументы не влияют на форматирование.

И не забывай про 3-хкратный оверхед.

Аргументы передаются по значению. Вы очень сильно ошибаетесь. В С++ эту проблему решает boost:format.

#include <stdio.h>
#include <stdint.h>

int main()
{
	uint64_t a = 256;
	uint32_t b = 512;
	printf("%i %i\n", a, b);
	return 0;
}

numas@gnunix ~ $ gcc -Wno-format app.c
numas@gnunix ~ $ ./a.out 
256 0
numas@gnunix ~ $

Ну а теперь, гореосилятор мой, объясни мне как свазана строка форматирования и аргументы?

По строке форматирования printf читает аргументы со стека. У него нет никакой другой информации о типах, кроме как предоставленной в строке форматирования.

Правильно - никак, архументо управляет конпелятор и засунь ты туда хоть что - оно будет работать.

Правильно работать оно скорее всего не будет. В особо тяжёлых случаях оно будет даже сегфолтиться.

Так размер параметров-то разный будет. А переход к следующему параметру рассчитывается по размеру текущего.

Стек, в моём amd64? А ещё что?

man amd64 abi, и да я клал на то, что происходит в твоём ущербном 32битном х86.

Если я что-то буду писать то, что должно работать где-то ещё - я погляжу как там работает принтф, да и я принфюзаю его максимум для дебага, ибо он ущербен.

Вы только что плюнули в лицо всему СПО.

Я не плюнул в лицо спо - я плюнул на одну из его ущербность.

некоторые спошники, ведомые «законами» юникса и сишки поверили, что можно делать всё и для всего и теперь их код состоит на 90% из кастылей для мёртвых архитектур.

Это порочно, ибо рано или поздно они будут погребены под своими кастылями. Я не считаю это вменяемым.

Стек, в моём amd64? А ещё что?

Даже на amd64 не все аргументы могут влезть в регистры.

Обрубите дереву корни, и посмотрите что будет дальше.

Хотя я не об этом. В первую очередь, программы должны быть стабильными. Основываясь на этой стабильности, они и становятся большими.

Эгоизм проходит, я надеюсь.

В амд64 стек юзается максимум для дампа регистров, не более.

Я не пишу такого кода, в котором они даже не влезают в регистры.

Я не пишу такого кода, в котором они даже не влезают в регистры.

Да ты вообще кроме hello world'ов ничего не пишешь.

Т.е. вы продолжите кормить трупы, будите с ними говорить и т.п.?

Архитектура умерла - её поддержка выпиливается из кода и живёт отдельно в своей ветке.

Программы должны быть простыми, вменяемыми и хорошими. А кастыль на каждом углу даст тебе лишь пустую трату времени.

Становятся большими они из-за человекачасов, да и большие - это порочно. Чем больше, тем ущербней, чем универсальней, тем ущербней.

Вместо простой и предсказумой работы вы выбираете непредсказуемую кучу ущербностей - это ваш выбор, но мой отказ от вашей идеологии не делает меня эгоистом.

Я думаю о ком-то, когда это ЕМУ НУЖНО, а о когда это ЕГО БЛАЖЬ - это меня не интересует.

Я надеюсь, ты это сейчас netcat'ом запостил?

Идём в гугл, смотришь сколько регистров у х86.

Вменяемый гцц, вменяемый притф юзает регистры даже на 7 аргументов, а стек юзает с 8байтным выравниванием. И правильно делает, если на твоей архитектуре это не так - это твои проблемы, если стек не выравнивается по размеру регестра - выкинь свой конпелятор.

Мой код никогда, даже на твоём тухлом 32битном х86 не умрёт, ибо я юзаю типы для 32 и 64битных типов.

Поэтому ты очередной балабол, который сказал фигню и рад.

А и да, давай я тебе тоже объясню, почему ты не прав.

Ты заюзал 64битную переменную на ущербном 32битном х86, что дало тебе фейл. Я же юзаю типы для 32 и 64битных значений.

Юзать их для значений меньше 32бит смысла нет, даже на твоей плохой архитектуре.

Поэтому это не мой эгоизм, а твоё неосиляторство, не более.

Я не отбираю у вас игрушку. Хочу что бы вы взглянули на мир более глобально.

Вы пишете не в машинных командах, не на ассемблере, а на Си. Это очень далеко отдаляет вас от архитектуры. Компилятор решает как ваш код будет исполнятся на ЭВМ. Не нравиться, спускайтесь ниже.

Универсальный код будет просто работать. Будет приносить пользу.

Не читал, но осуждаю? =))))

Ты хоть бы аргументы привел, почему мой код работать не будет, иначе это просто пердеж в никуда

о каком оверхеде идет речь?

Мой код сам следит за памятью - ему просто за ней следить не надо, ибо он неуязвим по определению

что будет если функция create_id0 и create_id1 вызывается произвольное число раз, заранее не определенное? скажем ввод данных от пользователя?

Как хорошо что вы это заметили. В универсальном коде, этой проблемы бы не наблюдалось. Это ваша ошибка.

А теперь подумайте что может ждать ваш код в будущем? Я надеюсь на ваше прозрение.

Смотри - ты хранишь массив класов, а каждый класс хранит метаифу - это таблица методов и прочая байда. Это байт 8. Ты юзаешь массив указателей, чтобы хранить свои классы - это ещё 8байт.

Уже 16байт на елемент. Плю там ещё всякая мелачёвка, плюс насилование кешей тоннами стл-выхлопа. Да на х86 с его метрами и десятками килобайт л1 это не мало заметно - на какй-нибудь слабой архитектуре это у тебяб удет тормазить дай дороги из-за кешмисов 24/7.

Твой код линкуется с полуметрами стл-кишков, что не особо вкатывает.

Плюс, аллокатор, какт ы будешь «выделять» память под свои классы? new/malloc на каждый класс? Это ещё 16-32байта оверхеда на елемент.

Если ты не захочешь юзать маллок - тебе прийдётся делать свой аллокатор, который будет работать так же, как мой код.

И в конечном итоге ты поймёшь, что я имел ввиду.

Это будет маллок на 36бит.

Нет, это проблемы нет и у меня, а у тебя есть лишная работа.

Если и можно юзать такой код, то только царю, который понимает что и как можно юзать. Поэтому почти все должны юзать универсальщину, но не надо меня обвинять в том, что у меня есть какие-то фейлы, которых у меня нет.

Мой код будет работать, если понадобится другой код - будет написан другой код. Мне не жалко понтартить 30секунд, чтобы переписать эту портянку.

И заметь, моя портянка работает в разы лучше, быстре, абсалютно не зависит ни от чего и написана на чистых сях без либц.

С++ код мало того, что состоит из больших строк, тормазит и даёт дохренуа оверхеда - он тащит за сабой стл - т.е. на самом деле он ещё больше - там строк 700 в конечном итоге будет.

Дак вот, отгадай что лучше?

Насрать на твой amd64. Есть стандарт языка и если ты ему не следуешь без уважительной причины - ты быдлокодер.

Профи. Давай тесты что ли устроим. Я возьму С++, а ты что хочешь. Покажешь мне на каком-нибудь хорошем примере тормоза плюсов?

я вас правильно понял? на вопрос:

Мой код сам следит за памятью - ему просто за ней следить не надо, ибо он неуязвим по определению

что будет если функция create_id0 и create_id1 вызывается произвольное число раз, заранее не определенное? скажем ввод данных от пользователя?

ответ:

Это будет маллок на 36бит.

условия только в начале с ним очень точно обговори, условия правильности решения. а то бесполезно.

Спасибо кэп. Ну будет небольшой оверхед и что?
Программа медленнее станет? Да не факт.

В любом случае ты не знаешь как правильно использовать цпп.

И ты тут про амд64 пердел, а тут про медленные архитетуры заговорил. Ты уж определись под что ты пишешь и на сколько твои оптимизации ускорят реальное приложение.

Я ему следую с уважительной причной - я знаю лучше стандарта что и как юзать.

Стандарт и либц - это просто такое описание языка и функцией, не более. Там есть какие-то рекомендации, но это рекомендации нужны тем, кто понимает Си на уровне либц и стандарта.

Все рекомендации пишут для обывателя. По твоей логике я не должен даже вендоус сам переустанвливать, не то, что железо менять, бп разбирать и прочее.

В таком случае у тебя будет куча #ifdef-ов с абсолютно разным кодом. Поддерживать такое та еще задача. А это говнокод.

Вообще твои оптимизации в большинстве случаев не нужны в реальном мире, ибо купить железку получше обходится дешевле, чем поддерживать говнокод.

Соглашайся уже, что твой код гавно и закончим на этом =).

Небольшой? 32-50байт на 16байт данных - нибольшой оверхед.

А если у тебя данных 50метров, а оперативки 100метров? ЧТо ты будешь делать? Так же ныть про «небольшой оверхед»?

Да, станет медленней.

Ты веришь в то, что амд64 медленней 32битного х86? Я на винфакечтоле?

Давай так - напиши мне код, который может записывать тысячи елементов - т.е. с алокатором и т.п.

Я напишу свой - поглядим на оверхед.

Ну давай у нас есть 2-4типа данных. У них есть аккумулятор и пару перменных + функция - функция должна складывать значения все переменных, кроме аккумулятора и класть их в аккумулятор.

Потом мы берём пару тысяч елементов - запоняем ими массив, вызвает для всех этих тысяч функции, а потом их удаляем.

Ты пишешь код на стл, а я пишу на сишке и сравним.

Он следит, но адреса-то у него откуда возмутся? Вот дай ему адреса, а дальше он всё сделает сам.

Давай так - напиши мне код, который может записывать тысячи елементов - т.е. с алокатором и т.п.

по конкретней пожалуйста. тысячи каких элементов? сколько тысяч? записывать откуда? записывать куда? записывать и все?

Я не очень тебя понял. Можно кодом?

все равно не понял, там вопрос, даже не один был, но к одному сводился. может быть вы его не увидели.

вопрос: что будет если функция create_id0 вызывается неизвестное на этапе компиляции число раз?

код примерно такой:

while(!flag_end)
{
  pull = create_id0(pull, 100123, 100223, 100323);
  // некоторый код изменяющий по ответу пользователя flag_end
}

Есть 4 типа елментов, которые хранят 3, 4, 5, 6 переменных + на каждый тип функцию-конструктор и функцию-метод.

Конструктор берёт 2 - 5 значений и записывает их в твой класс. Функция методом складывает все значения и помещает их в переменную acc, которая есть в каждом типе.

Ты берёшь конструируешь по 1к елементов каждого типа добавляешь их последовательно в хранилище.

Потом для каждого елемента вызваешь его метод.

Потом удаляешь хранилище.

У тебя памяти в среднем 36бит максимум. Это 30+гигов. Ты юзаешь маллок на 30+гигов и у тебя адреса кончатся до того момента, когда у тебя кончится память.

Функции вида create_id* могут вызвается бесконечное число раз, если у тебя есть бесконечное число адресов.

И давай еще random-access к элементам запилем, ок?