- 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
class socket_exception
{
public:
char *buf;
int ret;
socket_exception()
{
buf=new char[10000];
ret=RET_OK;
}
socket_exception(char *b, int r)
{
buf=new char[10000];
snprintf(buf,9999,"%s",b);
ret=r;
}
socket_exception(vsocket_exception &ex)
{
buf=new char[10000];
snprintf(buf, 9999, "%s", ex.buf);
ret=ex.ret;
}
const char * what (){return buf;}
int get_ret(){return ret;}
~socket_exception(){delete[] buf;}
};
Follow us!
P.S. Что-то хачкель вспомнился... foreign import unsafe pizdec my_external_function, unsafePerformPizdec, {-# LANGUAGE NoImplicitPizdec #-}...
Плохого дизайна?
P.S. socket_exception() создаст объект, у которого what() вернет 10кб мусора... Хорошо, если среди него попадется нолик.
именно
А ещё упаси вас бог присвоить один эксепшен другому
Да подумаешь - одна утечка и одно двойное удаление. Минус на минус дают плюс ;)
Нет, new зануляет. Это вам не malloc. :)
А если еще немного потестить или почитать стандарт? :) Вон ниже есть тест, который показывает, что не зануляет.
Но тогда это вообще абзац. Везде в дизайне крестов чётко и последовательно прослеживается мысль, что аналог "конструктора" для примитивных типов - это инициализация по умолчанию, то есть зануление. Так делает std::vector. Да, я знаю, что примитивные объекты на стеке не зануляются. Но new-то, по логике, как раз должен выполнять инициализацию!
Это не подводные камни, это какие-то подводные скалы уже.
Error E2243 1.cpp 6: Array allocated using 'new' may not have an initializer in function main()
А можно выделять по new таким образозом память, чтобы тривиальные типы, например char, инициализировались значением по умолчанию?
Никто ее не чистит, а вижуалка в дебажных сборках вообще мусором забивает.
P.S. Хотя можно перегрузить операторы new и delete, чтобы они работали через calloc или чистили выделенный кусок сами.
Большие куски всегда зануленны, а питухкеш наверное можно вырубить, ибо на норм ОС он не упал.
Исправлено.
...дай мне силу!
ps: ты не подумай. я загуглил
?
сильно.
Явно пора устроить клуб по интересам при говнокоде.
Но я бы предпочёл Wish You Were Here и A Momentary Lapse of Reason.
> 51 говнокод
Ты тут так давно, но говнокод тебя до сих пор не заметил?
Ну обычно не мусором, а например на x86 однобайтовым кодом вызова прерывания отладчика
Ну с точки зрения кода это будет именно мусор.
В конечном итоге доблестные конпелятора-запильщики создали вам ещё одну проблему, хотя мистическая вера людей в том, что сисколы медленны создавала столько лулзов - вон один мне доказывал, что fopen() с конкатом быстрее 2-х сисколов open() и openat().
Вопрос знатокам насколько конкатенация fopen("/etc"+"passwd", "r"); медленее openat(open("/etc", O_RDONLY), "passwd", O_RDONLY); даже не в долгострочной перспективе, а просто 1 вызов?
Зачем указатели складываешь?
В линуксе:
http://ideone.com/3VdfU2
ps: я всегда буду обновлять страницу
я всегда буду обновлять страницу
я всегда буду обновлять страницу
Когда аллоктор "выделяет" память честно, а не из питухкеша( а выделяет он её честно почти всегда, кроме питухслучая в твоей синтетики malloc(100500); free(); malloc(100500);) она занулена.
new - это слишком низкоуровневая и неынтырпрайзная операция, поэтому для всего прикладного нужно использовать std::vector.
Безусловно. Но в контексте экцепшенов на это всем насрать, т.к. в нормальной программе исключение это все-таки исключительная ситуация, а не то, что вызывается в цикле миллионы раз (привет, питон).
Нормальных программ, особенно на плюсах нет, а те, что есть - это систайл плюсы. И обычно быдлокод даже на ситайл плюсах(привет кути) лучше и удобней, чем новомодные птиухи(привет буст и производные). Ладно буст это тупо api к либам, но ведь есть код который реально написан на новомодных плюсах и фейспалмом себе расшибаешь, когда его читаешь.
Это как мне тут доказывали, что в коде могут быть нулы и мусор, который вводит пользователь - они не слышали о том, что надо разделять внутреннее ядро программы и обвес, с которым контактирует биомасса, если они пишут гуйню за еду.
Возьми - процессор, ваша ОС всё работает так - ОС и процессор не проверяет данные внутри себя, ибо они бы тормазили как питушня, но вы же умнее всех.
Поэтому пусть лучше не юзают вертметоды, ибо пихать они их будут везде, как new.
Рыть в проектах лень.
тему полиморфизм vs ручная эмуляция TVM поднимал сам тарас около года назад
на что я ему кидал скриншот этого пиздеца в сишке в реальном проекте
Поэтому ваши рассказы как всё плохо в сишкапроектах, где сишник есть годовалый студент, который боится указаталей - фигня.
ты поучаствуй хоть в одном реальном проекте для начала, потом суди, кто чего осилил, ок?
например, сделай патч в ядро - начни с лёгкого
хорошо хоть перестал питушиться на каждом шагу
если тебе интересно, я могу наглядно показать разницу между реальным полиморфизмом и сишной эмуляцией
Давай запили пример - не абстрактный, как все эти неосиляторы, а реальный. Который что-то делает.
Причем должен быть таким, что твой полиморфизм для него будет лучше моей "эмуляции", причем на уровне задачи. Дерзай.
например, сложное устройство, в котором реализована куча интерактивных логических процессов
один процесс - это последовательность состояний, в каждом состоянии есть как минимум вывод информации на дисплей и n коллбеков-реакций на внешние события (например, нажатие на кнопку - это одно событие, приход информации от датчика1 - второе, событие от таймера и т.д. - таких коллбеков легко наберется десяток)
состояние в какой-то момент знает, что автомат следует перевести в другое состояние
обычным графом такое не шибко закодируешь, потому что условно в событии кнопки при нажатии на одну кнопку надо перейти в одно состояние, при нажатии на другую - сделать доп. анализ и перейти в какие-то еще (или не перейти)
один процесс - несколько десятоков таких состояний
устройство богато на функционал, и реализует десяток различных процессов
а в сишке это потребует дополнительной работы:
1) тебе надо взять структуру типа struct { on_entry_func_type entry_func; on_timer_func_type on_timer; on_sensor_func_type on_sensor; ... } - это вместо объявления virtual из-коробки
2) и так и так описать тела всех этих функций - только в c++ это будет в пределах неймспейса класса + возможности по наследованию/инкапсуляции, а в С придется делать
state_hello_world_on_entry() { ... }
state_hello_world_on_timer() { ... }
3) отдельно проинициализировать каждое такое состояние - причем, создав экземпляр состояния заранее:
/* global */ state_t hello_world_state = { state_hello_world_on_entry, state_hello_world_on_timer, state_hello_world_on_sensor, state_common_state_on_key_ignore_beep, ... };
// other 100+ states
при этом, т.к. возможностей по наследованию нет - следить вручную, чтобы в нужных коллбеках стояли нужные "базовые" указатели
вот и вся простая разница между полиморфизмом, предоставляющим то же самое из коробки сахарными удобными средствами языка, и ручной эмуляцией оного
ну а компилятор, при должной локальности объявлений этих объектов состояний и глобальной оптимизации, вполне заинлайнит и то, и другое - тут нет особых преимуществ ни в с++, ни в с
> конечный автомат
Не жизнено и не злободневно.
> и т.д.
Не конкретно. Ему нужен конкретизированный реальный, а не абстракный пример.
> обычным графом такое не шибко закодируешь
На ифах намахает. Царю это расплюнуть.
> на ифах
т.е. предполагается что-то вроде 100+ states * 10+ callbacks
удачи ему с ифами, а также с дальнейшим сопровождением проекта по внесению новых состояний и модификации логики в текущих
Давай, ваяй пример, а реализую такую же байду, только на сишке.
ты как всегда даже текст понять не можешь
Потом я реализую тоже самое на сишке, как я хочу и как я считаю нужным, потом мы сравним.
у тебя много свободного времени, у меня же сейчас оно рабочее
если хочешь - жди до вечера, но не факт, что я сам захочу возвращаться к этому примеру
если ты еще не понял - перформанса тут и не нужно, тут нужно удобство кодирования -> сопровождения -> предсказуемой реальной оценки трудозатрат
ты же ссылался на то, что на сишке это займет меньше строк - вот тебе и пример
Это не пример, это описание абстрактной модели. Как ты понимаешь абстрактная модель без конкретики мне ничего не даёт.
А я и не говорю про перфоманс - табличный конечный автомат на калбеках работает медленно на x86. Хотя на amd64 достаточно приемлемо, даже сливает ифы питушков.
Хочешь удобство - я запилю тебе такое удобство, что ты удивишься. Я люблю удобство ещё больше, чем перфоманс, а красоту больше их обоих и это уже давно пора понять.
попробуй просто так же словами описать порядок действий или укажи на ошибку в рассуждениях
это не так сложно, как ты думаешь
Как это делается - делается это таблицой и калбеком на кнопку в простом случае. Датчик - это тоже самое, что кнопка - датчик ид - это индекс в массиве калбеков, а в калбек ты передаёшь значение снятое с датчкика.
Калбек на действие - самая удобная из всех для запила красивого кода. Если у тебя кнопки делают примерно одно и тоже - объекдиняй калбеки, хотя гцц это умеет делать сам и тебе просто надо сделать обёртку.
Таймер - это самосортирующийся массив(пулл), из которого берутся события по ид и юзается калбек. Самая простая и наглядная реализация.
Машина состояний - у тебя банальная структура, на которую неявно действуют все калбеки, если тебе это надо.
вопрос о том, что одно состояние кнопку обрабатывает вот так (например, кнопка 1 означает "выстрел ракеты"), второе состояние - вот так (кнопка 1 означает "собрать картошку, если уже сентябрь, иначе - сказать 'привет, баклан'"), третье состояние на кнопку 1 переходит в первое состояние
если бы любое состояние при нажатии на конкретную кнопку тупо переходило бы в другое состояние, не сделав ничего - то было бы достаточно графа состояний - таблицы, где в ячейке [id состояния, id события] стояло бы -> id таргет события
но такая таблица тут не прокатывает
значит нужна таблица [id состояния, id события] -> коллбек, что суть именно то, что описал выше - state_foo = { all callbacks for this state };
states[] = { &state_foo, &state_boo, ... };
Выстрел рактеты - первый калбек, собрать кортошку - второй, привет баклан - третий.
У тебя несколько путей - несколько таблиц калбеков для каждого состояния. Одна таблица, аля { [kei_id = 0] = {[state_id = 0] = callback, [state_id = 1] = callback1, [state_id = 2] = callback2, }, тут дальше для всех кнопок };
Да - это гццизм, но я клал.
На енумах это выглядит понятно и красиво. А ты будешь создвать по классу на кнопку, потом каждый метод наследовать по 4раза и прочая питушня.
Это будет портянка на 100500 строк, нечитая человеком и абсалютно непригодная для редактирования, а мою заполнит любой человек за 2минуты.
коллбек логически относится к состоянию - состояние знает, что ему делать с пришедшим событием "кнопка", "датчик", "картошка" и т.д.
я не зря говорил про 10 коллбеков, а с учетом, что кнопок, например, 10 - в твоем случае получается уже 100 колонок
в итоге ты получаешь таблицу на енумах - это значит при обращении к этой таблице надо заниматься поиском нужного стейта - возникает проблема обеспечения совместимости таблицы с енумом - чтобы в таблице случайно не оказалось меньше значений, чем в енуме, чтобы в таблице строки шли ровно в порядке, соответствующем енуму (ты же не хочешь линейным поиском искать state_X?)
и что же в итоге?
тебе надо заполнить таблицу коллбеков, не наебавшись, например, назначив callback_for_state_123 состоянию callback_for_state_132
ты знаешь как дорого будет искать подобную ошибку в коде? не факт, что хер заметишь
а ракета пойдет копать картошку
всё то же самое в ООП выглядит просто элементарно: ты тут не наебешься с назначением коллбека - он лежит внутри структуры, ты тут сможешь вообще не переопределять поведение предка, если его поведение на коллбек тебя устраивает
и таки да, строчек получается меньше
Никак не ошибёшься, проще чем твои питухклассы - быстрее и надёжней, а так же понятней.
ой что же это такое?
получилось на гораздо меньше строк и гораздо ниже шанс на ошибку
какой тут кодеген - что я должен описывать? в файле tarasb.pre функции, где кодеген допилит к ним приставки? так я их лучше в структуре tarasb опишу
а в общем и целом - ты описал ровно то, с чего я сделал первый вброс
именно так это уже работает в куче наших сишных проектов, и на ООП это делается гораздо удобнее
Питушара анскильная - ты зачитерил и выпилил вообще половину калбеков. А теперь запили, чтобы каждый говорил свою фразу - получишь облом.
И да, а теперь тебе пришли состояние 2 и 2 - анука заюзай своё фуфло - получи облом.
>а в общем и целом - ты описал ровно то, с чего я сделал первый вброс
>именно так это уже работает в куче наших сишных проектов, и на ООП это делается гораздо удобнее
Ты только что тотально слился и не запилил аналог моего кода.
чтобы ответить на твой вопрос, мне сначала надо понять что такое "мне пришли состояние 2 и 2?"
пока ты думаешь, как это объяснить, на всякий случай уточню - конечный автомат имеет "текущее состояние", это текущее состояние и только оно принимает события, и только текущее состояние принимает решение, что неплохо бы перейти в другое состояние - для этого оно делает return set_new_state(new state), после чего новые события должно будет исполнять это новое состояние
В лучшем. Питух пробалаболил. Ты понимаешь, что я аналог твоей байды запилю 10-ю строчками?
Давай ваяй свою байду - я поржу и солью тебя, питушка. Потом ты правда будешь вонять, что моё не безопасно, но я клал.
свою байду - аналог твоей байды - я уже тебе показал
жду от тебя ответа - что такое 2 и 2?
С такого, что тебе прийдётся описывать их в классах, питух.
>свою байду - аналог твоей байды - я уже тебе показал
Ты привёл не аналог, питух, у тебя 3 калбека уникальных, а не 6 как у меня. Ты просто считерил на том, что фразы одинаковые. Ты сделал m_call[TarasB](key_0);
Я могу так же считерить и тупо сделать в 4строчки say(TarasB, key_2);
>жду от тебя ответа - что такое 2 и 2?
Я откуда знаю, что в твоей питушарской логике 2 и 2. Ты начал питушить, что у тебя активно одно состояние - так питух я так тоже умею. Я жду вменяемого примера, не ссы, ты можешь назвать мой код небезопасным и меня заминусуют и никто даже не заметит как ты слился.
нет, я наглядно показал, что делать состоянию, когда ему достаточно реализованного "общего" поведения
например, проигнорировать сенсор1 или пикнуть два раза при нажатии на ненужную кнопку
> И да, а теперь тебе пришли состояние 2 и 2 - анука заюзай своё фуфло - получи облом.
у тебя же абсолютная память
ты это сказал
я так и не понял что это значит
обознался?
например, проигнорировать сенсор1 или пикнуть два раза при нажатии на ненужную кнопку
Нет, питух, ты считерил и оправдываешься. ВЫПОЛНИ 9 УНИКАЛЬНЫХ КОМБИНАЦИЙ КОДА. Т.е. каждая функция для каждого состояния должна исполнять УНИКАЛЬНУЮ комбинацию кода.
У тебя, питуха, всего 3 уникальных комбинации кода, а не 9. У меня 9. Ты понимаешь разницу?
>у тебя же абсолютная память
>ты это сказал
>я так и не понял что это значит
>обознался?
Жалкая сливалка, ты чего копипастишь месаги из моего предпредышего коммента, питух? Попец заболел? Слейся уже и запомни свою место, анскилябра и не спорь, коли сливаешься на 3-м комменте.
на тебе 9 уникальных
что-то ты совсем уже начинаешь сливаться, я тебя, долбоеб, трижды спросил что ты имел в виду, и ты теперь еще меня укоряешь за это?
притом, что ты до сих пор так и не ответил ЧТО ТЫ БЛЯТЬ ИМЕЛ В ВИДУ
это еще у кого жжение то?
нет, ты!
бгг
Получил больше строк даже на такой примитивщине.
>что-то ты совсем уже начинаешь сливаться, я тебя, долбоеб, трижды спросил что ты имел в виду, и ты теперь еще меня укоряешь за это?
ЧТо я имел ввиду? Тебе приходит key_id(у тебя приходит число - это нажатая кнопка) - для твой питушни тебе надо будет создавать о5 массив калбеков в который загонять свои методы, либо делать свич - мне же не надо.
Для перехода в состояние - тебе надо свичить указатель, а когда у тебя будет 10обработчиков - ты будешь свичить 10указателей, либо фигачать 100500 абстракций на классах.
В конечном итоге у тебя будет всё запутанней и ущербней, чем у меня и ты это знаешь, поэтому ты и ссышся запилить реальный пример.
пришел сигнал - current_state->on_signal(), и т.д.
или по твоему основной цикл не отличает кнопку от реле
вот ведь анскильный питух, ну нихуя же не знает
чья бы корова мычала - твоего кода вообще никто здесь так и не увидел. зато у тебя шикарная коллекция эпичненьких сливов.
чтобы ты не брызгался ничем в мою сторону, то я напомню, что где-то тут я давал ссылку на целый готовый рабочий проект, в котором много хорошего
Иван Фёдорович Крузенштерн - структура данных и алгоритм
Красиво и никаких ООП не нужно.
И чем более сложные проекты ты будешь делать, тем более анскильным питухом ты будешь становиться.
Понимаешь в чём штука - я не буду делать сложны по вашим меркам проекты - я буду делать сложные по объективным меркам, ибо меня не интересует писанье питушни за еду ни в коей мере.
это тебе уже на лоре объяснили
чтобы делать производительные шняги на терабайты данных, необходимо разбираться в структурах данных (а у тебя даже массивы - для питухов)
сейчас ты сидишь на шее у родителей - назови область, где ты сможешь заработать себе на доширак с икрой
это тебе уже на лоре объяснили
Ну вообще-то я слил их в хламину. Мой складыватель 2дмассива работает примерно за 2такта, дальше уже уперается в память. Поидее мой банан должен закончится через пару дней - следи за лором и моим 3-м прешествием.
>чтобы делать производительные шняги на терабайты данных, необходимо разбираться в структурах данных (а у тебя даже массивы - для питухов)
Не в структурах данных, а в устройстве железа. Знание матчасти даёт буст не соизмеримый с твоей питушнёй для студентов.
>сейчас ты сидишь на шее у родителей - назови область, где ты сможешь заработать себе на доширак с икрой
Я не живу с родителями, и не сижу на их шее, лалка. Да любая, вопрос в том нужно ли это мне. 98% лалок в этом мире я солью с закрытыми глазами, а остальные могут что-то только в конкретной области, в которой я их тоже солью покапавшись в ней с месяцок.
Разница в том, что вы работаете за еду в какой-то области, которую я даже не щупал, но мой общий скилл запила, понимания и т.п. на сотни порядков превышает ваши. Поэтому если мы возмём любую рандомную область - то вы сольёте просто в хламину, в этом и суть. Вы любые разговоры и примеры пытаетесь сводить к своему узкому мирку. Тарас свой к гейдеву, ты к своим МКашкам и т.п. - это жалко.
И да, сейчас лор не имеет смысла читать - ибо все мои коменты и темы выпилили оставили только шлак.
именно в структурах данных
на пальцах - надо хранить ~миллиард записей, каждая из которых уникальна по некоему полю Х, которые регулярно и независимо пополняются и удаляются, а пользователю надо сравнительно быстро найти уникальную запись [Х] и десять следующих записей в порядке возрастания X
миллиард тут выбрано как отсечка, показывающая что в оперативную память не влезает, а на диск - без проблем
Хранить - юзай lseek() и read()/write(). Приводи пример своих записей, а не сливайся - я уделаю в хламину любую твою бд.
линейный поиск или бинарный?
Если тебе надо сопоставлять разные индексы - юзай индексацию, но это уже к хранению данных не имеет отношения. Если у тебя разные данные, то ты питух - это уже ФС и попец, но тебя спасут пуллы и индексация.
Работа с файлами ничем не отличается от работы с оперативой, те же блоки, аля кешлайны, те же гиганские задержки на новый блок(кешлайн) и т.п. Файловый кеш, аля л2 - твой кеш в программе, аля л1. Ты можешь юзать свои кеша, что делает работу даже удобней, чем с оперативой на х86.
Никакой сложности нет. Сложность есть, когда ты делаешь индексацию для питухов, а мне не надо делать индексацию для пнскильных питухов, ибо я сам юзаю свои творения, а не питухи.
на пальцах - у меня уже есть 100 записей, я удаляю ИД = 20
что произойдет с файлом?
и опа, уже не катит ИД*sizeof, либо твой файл только растет и растет
но постоянно растущий файл нужен в 0.001% случаев - для хранения он не подходит, только для временной обработки и немедленного удаления, после окончания обработки
предлагай ещё, сложности то нет никакой
>на пальцах - у меня уже есть 100 записей, я удаляю ИД = 20
>что произойдет с файлом?
Ничего, на низком уровне нет никакого удаление. Максимум удаление из индекса, либо зануление.
>и опа, уже не катит ИД*sizeof, либо твой файл только растет и растет
И опа - занули и сожми хвост, опа обреж хвост.
>но постоянно растущий файл нужен в 0.001% случаев - для хранения он не подходит, только для временной обработки и немедленного удаления, после окончания обработки
Нет, все твой БД работают на постоянно растущих файлах, данные не удаляют, а максимум зануляют.
>предлагай ещё, сложности то нет никакой
Что предлогать? Я тебе описал систему хранения, которая уделывает в хламину любую, ибо это массив. Всё остальное в твоей БД строится на индексации этого массива.
я тебе предложил хранить миллиард записей
я удаляю 20ю запись из миллиарда - кто будет переносить этот охулиард из хвоста назад сдвигом на одну запись?
и да, в это время другой пользователь как бы нашёл нужное себе и работает с 100500й записью и знает её расположение в файле
вот он решает её изменить - он может ожидать, что она находится примерно там же, или её надо заново попытаться найти?
как хранит данные БД я в курсе, я как раз тебя подвожу к этому
что будет с файлом, который только растет, если он хранит, например, данные сессий - т.е. ежедневно у тебя ~100000 записей создаются и удаляются, хаотично
Удаление - это есть data[id] = 0; Никаких здвигов нет. Следующая запись - записыватся в свободное ИД, а свободные ИД хранятся в пуллах.
На каждую твою запись - тебе выдаётся ИД, если ты удаляешь запись с ид 100500 - она помещается в пулл свободных ид, а когда ты записываешь новые данные - им присваивается ид=100500, ибо она последние было добавлени в пулл. Если ты записываешь ещё данные - они берутся либо дальше из пула свободных, либо из оставшихся ид, а если ид больше нет - файл растёт.
Ты модешь свободные идешки сортировать, а хваст обрезать во время простоя.
Моё описание структуры данных для твоих сессий идеальна и уделает в хламину любую, сортировкой можно подкоректировать локальность, чтобы кеш работал лучше, но это уже детали.
Это сливает в хламину любую твою бд, ибо это идеал.
я сказал миллиард - значит только под массив id тебе нужно минимум 4GB места
а для 10 миллиардов - 40GB
где оно хранится?
твой массив хранит только свободные id - окей, возьмем файл на 40 миллиардов, в котором живая только последняя запись, что дальше?
и еще - почему это при добавлении записи в файл она должна получить чужое id?
представь ты создаешь ссылку на понравившуюся тебе порнокартинку - она получает имя lolpic/15134523
ты её посылаешь другу, но картинку в это время удаляют, а другой пользователь через мгновение заливает свою
друг, вместо того, чтобы сказать тебе - "кретин, этой картинки уже нет" - видит пидарастическое порно, где армяне жарят друг друга в очко
Обыкновенно.
>я сказал миллиард - значит только под массив id тебе нужно минимум 4GB места
Не нужно - они все будут нулевыми, а их не нужно хранить в пуле, ибо их вообще нет.
>твой массив хранит только свободные id - окей, возьмем файл на 40 миллиардов, в котором живая только последняя запись, что дальше?
А с чего будет жива только последня запись? Даже если будет жива - до неё один фиг будет пустота.
>и еще - почему это при добавлении записи в файл она должна получить чужое id?
Патамучто так должно быть. Почему когда ты удалишь файл, а потом запишешь другой - он будет хранится на том же самом месте.
>ко-ко-ко
Это делается уже в верхнем индексе, а не в нижнем, если тебе это надо.
А представь, что у тебя удалено 100миллиардов картинок через одну, что ты будешь делать? А ты зафейлишься и не поднимаешься и твой индекс умрёт.
какая разница где он будет храниться - у него должен быть свой, уникальный id
например, ты хранил картинку lolpic/15134523, ты её удалил
ты пишешь на диск lolpic/999134523, очень вероятно, что оно заняло место старой - только имя то у нее уже другое
id должны идти хронологически строго по возрастанию
тебе нужно хранить массив ID свободных узлов, доступных под запись
из твоих слов я понял, что это будет именно массив, в который в хвост будут дописывать постоянно очередной освободившийся узел, и затирать из хвоста, если освободившийся узел опять займут
т.о. для таблицы, в которой жило 40G записей, и из которой сейчас удалили 40G-1 запись тебе надо хранить все эти ID свободных узлов
ты ссылаешься на (любую) файловую систему, но даже не знаешь, что она также оперирует "структурами данных сложнее массива"
>тебе нужно хранить массив ID свободных узлов, доступных под запись
из твоих слов я понял, что это будет именно массив, в который в хвост будут дописывать постоянно очередной освободившийся узел, и затирать из хвоста, если освободившийся узел опять займут
Не в хвост, а в свободные места.
>т.о. для таблицы, в которой жило 40G записей, и из которой сейчас удалили 40G-1 запись тебе надо хранить все эти ID свободных узлов
Нет анскилл, если есть следующий индекс, то она может менять индкс твоей 40G-1 на 0, а хваст удалить.
Так же, хранить 40G нулей мне не трудно.
>ты ссылаешься на (любую) файловую систему, но даже не знаешь, что она также оперирует "структурами данных сложнее массива"
Глупый, анскильный питух, оделел съезжать. Хранение данных у неё запиленно именно на массивах, где елемент - это блок.
У тебя есть хард длинной в N - он бьётся на блоки, которым привается уникальный ид - это индекс блока. Это блоки уже пишутся в инноды, аля файл начинаетясн а таком-то id и длинна его столько-то блоков, если же твоя ФС умирает, то пишется что-то аля: block_id, size; next_block_id;size и так весь файл.
В зависимости от структуры ФС и её индексов и фичей это может быть усложененно, но на самом нижем уровне это работет именно так.
где же тут массив, анскильный питушок?
Для хранению файла никакой список не упал, ибо файл - это диапазоны из массива блоков. Список тут - лишний оверхед безпрофитный.
залей на диск N маленьких фоток, удали через одну - получишь физическое хранение модели "решето"
теперь залей порнофильм в хд качестве - который аккуратно размажется по этому решету
как ты думаешь одна часть решета c адресом конца 1000 знает, что за ней следует новая часть решета с адресом начала 5000?
>ибо файл - это диапазоны из массива блоков.
Как думаешь, почему тут написанно диапазоны?
>если же твоя ФС умирает, то пишется что-то аля: block_id, size; next_block_id;size и так весь файл.
Тебе создать файл из 5к блоков, а у тебя есть максимум по 50 блоков в ряд - ты пишешь:
id начальной блока и его длинну, потом ещё так же 10раз - вот у тебя файл. Как думаешь, что будет быстрее питушиный связный список, либо мой вариант? И как думаешь какой вариаент юзает ФС? Правильно - мой вариант, а не питуха.
догадайся, почему она так называется
ну да ладно, простейшие файловые системы для анскильных изимодных питухов
итак, где и в каком виде твоей файловой системой хранится список массив из (id блока, длина) (id блока, длина) (id блока, длина) для файла?
с чего ты решил, что что-то зафейлится?
будет всё достаточно компактно храниться - потому что БД знает про структуры данных, а ты - нет
А всё почему? Патамучто ты даже не знаешь, как работает твоя бд, а знаешь работу БД на уровне индексов и то по желтым книжкам и статейкам.
но B* деревья слишком анскильны для анскильного питуха
Мой же пример для нормально запиленного юзает работает напорядке быстрее твоих деревьев, ибо если ты захочешь в бревне локальности - прошай балансировка - здравствуй массив. Поэтому локальности на бревне ты не получишь, а не получишь локальности - не получишь кеширование, а не получишь кеширование - получишь ИОПСЫ.
у тебя в массив данные добавляются то в хронологическом порядке, то в хаотическом - если заполняют дыры
о какой локальности идёт речь?
твое хранилище не обеспечивает хронологии - оно вообще ничего не обеспечивает
ну да ладно, вернемся к самому главному
итак, у тебя есть твой сплошной массив записей (с дырками) - тебе надо обеспечить быстрый поиск записи по нужному критерию, и как найдешь - линейно пройтись по соседним по тому же критерию записям
твои действия?
но списки для питухов
В некоторых случаях да - будет профит.
>о какой локальности идёт речь?
Неможет ничего так добавляется, ибо это питушиный абстрактный пример. В реальном мире такого не бывает.
Даже если они добавляются как угодно - мой пример уделывает в хлам твоё бревно.
>итак, у тебя есть твой сплошной массив записей (с дырками) - тебе надо обеспечить быстрый поиск записи по нужному критерию, и как найдешь - линейно пройтись по соседним по тому же критерию записям
По какому-такому кретирию? По самим данным? Мой последовательный поиск будет быстрее обхода твоего деерва.
И в чём смысл искать по критерию, о5 питух пытаешься съекхать? У тебя хранится милиард фоточек - какт ы будешь среди них искать ту, на которой больше красного?
если нет индекса - то только перебор, ясен хуй
я хочу продолжить разговор про индексы
он заявит что индекс это такой же ололо просто массив
и тогда я вернусь к теме, сколько будет при первом же удалении записи ребилдиться его ололо индекс и сколько индекс на b*
как это не нужен твоему индексу ребилд - если я удалю запись из исходного массива, то из твоего индекса её тоже надо удалить
кстати, вот в твоему пулле по годам для 1969 года находится 1000 записей
тебе надо удалить из нее запись, ссылка на которую в пулле находится на 2 строчке - ты её зануляешь или сдвигаешь копированием хвост пулла?
а так же - ссылки в пулле каким то образом отсортированы?
О5 очередной питух с ущербной О-нотацией. Цена единицы для дерева и массива стоит порязному, ой как поразному - в райне 2-х порядков.
>как это не нужен твоему индексу ребилд - если я удалю запись из исходного >массива, то из твоего индекса её тоже надо удалить
Не надо. Это тебе не дерево питух, я могу удалять как угодно, а могу вообще не удалять.
>кстати, вот в твоему пулле по годам для 1969 года находится 1000 записей
>тебе надо удалить из нее запись, ссылка на которую в пулле находится на 2 >строчке - ты её зануляешь или сдвигаешь копированием хвост пулла?
>а так же - ссылки в пулле каким то образом отсортированы?
Запись не удаляется, а зануляется. Её ид равен пустоте, на её место потом запишется новая запись.
Никаких ссылок в пуле нет, в пули есть аляуказатели, питух. Это ид твоих структур, по которым ты можешь найти все остальные поля.
причем тут ущербная О нотация?
на пальцах
возьмем миллиард записей
сколько операций диска тебе потребуется, чтобы сделать перепозиционирование на нужное смещение в огромном файле?
возьмем b* дерево, в каждом листе которого хранится, ну например 100 записей - значит, за ~23 чтения ты попадёшь в нужный лист
не забывай это число
далее - теперь про добавление/удаление
итак, мы выяснили, что в твоем пуле "указатели" никак не отсортированы - там лежат просто напросто id, с периодическими дырками в виде нулей
значит, при удалении записи из основного массива, тебе надо линейно перебрать весь пул, чтобы найти нужную тебе строку, и её занулить
линейный поиск - это уже считается оптимально для питушиного оптимизатора?
далее
один пул тебе как бы даёт одну попугайскую точность
что делать, когда нужна точность поменьше? (см вопрос про атомные станции)
>итак, мы выяснили, что в твоем пуле "указатели" никак не отсортированы - там лежат просто напросто id, с периодическими дырками в виде нулей
Питушара - анскильная.
>значит, при удалении записи из основного массива, тебе надо линейно перебрать >весь пул, чтобы найти нужную тебе строку, и её занулить
>линейный поиск - это уже считается оптимально для питушиного оптимизатора?
Упоролся питухчтоли? sizeof(data)*id - O(1) по твоей птиух натации.
>один пул тебе как бы даёт одну попугайскую точность
Моей попугайской точности тебе не даст твоя питухБД.
вот так вот приходят сраные анскильные лохи, и пиздят и пиздят
нихуя у тебя не получится терабайты данных обработать, сосунок, спокойной ночи
Не умеешь оценивать трудоемкость своих поделок - в биореактор, быдло!
Создаёшь по своему пуллу на каждый год и туда записываешь идешки своих структур - потом тупо читаешь весь пул.
Питух тотально слит и уничтожен, а теперь он будет будет балаболить, что типа с таким-то днём - берёшь дни из юникстайма и юзаешь их как ид для пулла.
partitioning
хорошо
теперь всех людей, которые родились конкретно с 10 по 15 мая 1969 года
Читать разучился?
Теперь пулов будет столькоже, сколько дней.
Питух, это самая идеальная выборочная индексация, можешь не продолжать кукарекать.
я централизованно собираю статистику с атомных электростанций
события приходят с точностью миллисекунд
события собираются с 1950 года
сколько пуллов мне надо, чтобы выяснить, какие события происходили 21 июня 1997 года с 15:00 до 18:15?
В твоей бд не будет вставки даже на десятки милисекунд, питух.
Ты пытаешься ещё раз в лужу рожей? Кол-во часов - в лужу рожей. Пулы бесплатны, если ты об этом будешь кукарекать.
с чего ты решил, что не будет вставки? данные уже зарегистрированы, высокоточными датчиками, мне не надо вставлять в бд когда конкретно они вставились в бд, лол, мне надо вставить уже готовые данные, в этих данных есть информация
какое по твоему скилльному мнению число ежесуточных вставок способна выдержать изимодная ненужно БД типа оракла?
>с чего ты решил, что не будет вставки? данные уже зарегистрированы, >высокоточными датчиками, мне не надо вставлять в бд когда конкретно они >вставились в бд, лол, мне надо вставить уже готовые данные, в этих данных есть >информация
Ты что сливаешься животное? Милисекунда - это тысяча вставок в секунду - твоя питух БД не даст тебе тысячу вставок в секунду.
>какое по твоему скилльному мнению число ежесуточных вставок способна выдержать изимодная ненужно БД типа оракла?
Моя миллиадрды вставок в секунду. Оракловское фуфлу тысячи в лучше случае.
миллиарды в секунду? мой проц работает на частоте 4.7GHz, а оперативная память - "1.8GHz"
у тебя с арифметикой проблемы?
Мой вставка стоит единицы тактов - остальное уже задержки и оверхед твоей памяти. Понимаешь разницу?
почитай что такое ACID
TPS - это именно транзакция
транзакции можно сделать commit или rollback, тысяча параллельно исполняющихся транзакций обязаны оставить БД в целостном состоянии, поэтому требуются различные проверки на каждую вставку, удаление, бд может лежать распределенно по нодам кластера, потому что тебе надо в тч обеспечить бесперебойность при выходе из строя железа
ты просто бд крупнее одного однородного файла не видел, поэтому такой школьный вывод, что бд не нужны
или думаешь, что бд нужны только сраным веб-магазинам
откуда уверенность, что очередной прирост его на диске будет именно физически рядом?
Твоя оценка своего уровня знаний конкретно упадёт.
> Понимаешь в чём штука - я не буду делать сложны по вашим меркам проекты - я буду делать сложные по объективным меркам
Этого достаточно, чтобы стать анскильным питухом.
Моя оценка своего уровня крайне объективна. Мои оценки все крайне объективны, ибо меня не интересует что-то, кроме тотального вина. Все мои оценки чего-то строятся относительно абсалюта, а не анскильных сущностей.
>Этого достаточно, чтобы стать анскильным питухом.
Ну я же не становлюсь. С каждым днём моя моё понимание всё лучше и лучше, и с каждым днём мир подо мной всё ниже и ниже. Я не вижу в коде сложности - я вижу лишь сложность в его написании, но меня это не интересует.
Только Ситхи все возводят в абсолют.
А в абсалют только анскильные по русскому питухи.
только в абсАлют?
Это потому что ты не начал заниматься сложными проектами.
А как втянешься, то вдруг... ну тут два пути у тебя, либо ты уйдёшь в микроконтроллеры, там ты должен пригодиться, либо твои нынешние низкоуровневые знания тебе в будущем будут нахрен не нужны, как-то так я вижу.