Ой, не, это я не знаю. Тебе , я же говорил, копать надо... Ну и IIS -- не самый популярный сервак, ты фиг по нему кого найдёшь.

Ну я же вопросы сюда не вместо копания накидываю, а в дополнение к нему :)

Здравствуйте, подскажите, есть ли в каких-нибудь библиотеках готовая реализация виртуальной памяти. Например, есть класс виртуальной памяти, которому я могу отдать сколь угодно много отдельный кусков памяти (указатель и размер), а этот класс бы реализовывал мне непрерывную память с доступом как к указателю, проще говоря, имел все те же операторы, что у обычного указателя.

Чем тебе память OS не устраивает?

я такие абстракции нигде не видел

А я видел. Лучше бы не видел...

Я не понял, как вы с виртуальной памяти на модули IIS переключились.

препутали, очевидно

Чем тебе память OS не устраивает?

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

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

Пока не звучит как задача, в которой нужен кастомный аллокатор, пожалуй.

Как, прости, COM может узнать как и где ты выделил память?

COM объект не должен это знать. Он сам под себя память выделяет, и сам же освобождает.

Я с COM не работал, но насколько знаю, там нужно наследоваться от специального класса со счётчиком ссылок, а в интерфейсах модуля никакого наследования нет

Этот класс -- базовый интерфейс CON IUnknown

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

Ну, добирайся, при чём тут память?

COM объект не должен это знать. Он сам под себя память выделяет, и сам же освобождает.

Вот именно этого и не происходит. Там фабрика делает что-то навроде CHttpModule* module = new CMyModule(); *PPModule = module; и привет. Даже если собственно имплементация CMyModule будет правильно освобождать свою память в каком-нибудь Dispose методе, то, где выделен собственно сам module COM понятия не имеет. Это может быть new, это может быть std::allocator, это может быть HeapAlloc, etc.

Здравствуйте, подскажите, есть ли в каких-нибудь библиотеках готовая реализация виртуальной памяти. Например, есть класс виртуальной памяти, которому я могу отдать сколь угодно много отдельный кусков памяти (указатель и размер), а этот класс бы реализовывал мне непрерывную память с доступом как к указателю, проще говоря, имел все те же операторы, что у обычного указателя.

Ну и главная причина, почему это не нужно -- будет очень медленно.

Ну и главная причина, почему это не нужно -- будет очень медленно.

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

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

С какго тут вообще копирование нужно?

С какго тут вообще копирование нужно?

например, уже были написаны парсеры на памяти OS, что бы их не переписывать.

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

Ты не думай, ты делай. Есть такое оружие, "бритва Уильяма из Оккама" называется. Вот её вооружись, и никакая виртуальная память тебе будет не нужна.

например, уже были написаны парсеры на памяти OS, что бы их не переписывать.

Чета ты бред какой-то выдаёшь... Ну ладно. Дело твоё, пиши искусственную виртуальную память

например, уже были написаны парсеры на памяти OS, что бы их не переписывать.

Любая память приложения на С++ -- это память OS. Другой нет. Если у тебя есть парсер, то он может работать в ЛЮБОЙ памяти

например, уже были написаны парсеры на памяти OS, что бы их не переписывать.

Ты хочешь своим парсерам передать кастомный аллокатор.

(но не факт, что он у тебя будет быстрее стандартного)

например, уже были написаны парсеры на памяти OS, что бы их не переписывать.

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

Вот именно этого и не происходит. Там фабрика делает что-то навроде CHttpModule* module = new CMyModule(); *PPModule = module; и привет. Даже если собственно имплементация CMyModule будет правильно освобождать свою память в каком-нибудь Dispose методе, то, где выделен собственно сам module COM понятия не имеет. Это может быть new, это может быть std::allocator, это может быть HeapAlloc, etc.

Я вроде бы понял Дефолтная имплементация Dispose в исходниках : delete this; Так что, видимо, в этом методе нужно самовыпиливаться

Ну да, так и делают в COM.

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

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

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

Ну тогда тут скорее не память, а поток данных. Научите парсера эти читать из потока, и по не му же ходить. А потом подсовывайте то, что может изображать из себя поток

так может парсер не только в одну сторону работает, а нужно и вперед и назад

так может парсер не только в одну сторону работает, а нужно и вперед и назад

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

Я всё равно таких библиотек не знаю...

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

Ну вот, сносил мне мозг, задал кучу вопросов, а так и не помог :))

Ну вот, сносил мне мозг, задал кучу вопросов, а так и не помог :))

Мы просто давно не обновляли его

Я сразу сказал, что не знаю. Но может другие прочитают, и скажут. Инфы -то ты точно больше выдал

Новая версияя шустрее соображает

Новая версияя шустрее соображает

Да езжай в свою америку лучше! :-)

Да езжай в свою америку лучше! :-)

я туда только на неделю ?

Я написал реализацию виртуальной памяти, могу поделиться.

Я написал реализацию виртуальной памяти, могу поделиться.

чёт я не понял...

Я написал реализацию виртуальной памяти, могу поделиться.

делись)

Но не факт что она оптимальная, искал что-то похожее у других, в надежде что будет быстрее, и красивее написано

Я написал реализацию виртуальной памяти, могу поделиться.

делись, конечно

без политоты, пожалуйста

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

Стековый аллокатор нужен! Аренного типа, например.

А чего ты прибеднялся? Нормально же написал вроде...

А чего ты прибеднялся? Нормально же написал вроде...

Меня самодельный crc32 там немножко смутил, признаться.

А чего ты прибеднялся? Нормально же написал вроде...

Я подозреваю, что вы просто плохо посмотрели :). Как я уже говорил, что парсеры уже написаны, и они принимают указатель на память ну и размер. Придется менять сигнатуру функций парсера, что собственно не приветствуется, либо порой просто не возможно. У меня не получилась оставить сигнатуру функций парсеров такой, какой они были, при использовании этого класса. Может, у кого-то есть идеи, как сделать, что бы оставить сигнатуру прежней.

Ну пример сигнатуры дай хотя бы. Но вообще да, указатель на этот класс надо передавать вместо указателя на память.

void parse(uint8_t *p, size_t size); - функция приема очередного куска данных. Это как пример.

void parse(uint8_t *p, size_t size); - функция приема очередного куска данных. Это как пример.

Ну, если оставить сигнатуру -- самоцель, можно конечно тут передавать указатель на void через p и потом через reinterpret его кастовать к твоему классу. Но нафига это -- я вот не понимаю. Менять так менять...

Ну напиши кастомный random_access_iterator

Да, кстати, была дурацкая идея, предложить реализовать такой механизм в стандарте, и как-то это поддержать. :)

Действительно дурацкая

В стандарте есть перегружаемый new.

Да не нужно

Ему нужен просто iterator

Ну напиши кастомный random_access_iterator

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

Да, кстати, была дурацкая идея, предложить реализовать такой механизм в стандарте, и как-то это поддержать. :)

Это не очень много кому нужная фича, У меня более кардинальное предложение, давайте запилим в стандарт проект библиотеки, которая сама бы выдавала нужный функционал, только нужно было бы её сделать #include

Привет. Часто вообще используются объединения в коде? Много я потеряю, если пропущу их изучение?

Onion??

Union

Сегодня Union, а завтра захочешь пропустить struct, ну и так далее :)

Привет. Часто вообще используются объединения в коде? Много я потеряю, если пропущу их изучение?

Много

Ok

Привет. Часто вообще используются объединения в коде? Много я потеряю, если пропущу их изучение?

@supapro

Привет. Часто вообще используются объединения в коде? Много я потеряю, если пропущу их изучение?

Редко. Немного. Потом если что подчитаешь...

Спасибо

Много

Тебе просто "особенно повезло" в жизни. В смысле -- специфические проекты.

Спасибо

Но про алиасинг (смежная тема) не пропускай изучить!

Это не очень много кому нужная фича, У меня более кардинальное предложение, давайте запилим в стандарт проект библиотеки, которая сама бы выдавала нужный функционал, только нужно было бы её сделать #include

Во многих OS используется механизм виртуальной памяти, при отображении фрагментированной физической памяти в линейную (виртуальную). Почему же нет такого механизма в стандарте. Может, конечно, потому что его достаточно просто реализовать, или он заведомо будет медленнее, чем специальная реализация.

Во многих OS используется механизм виртуальной памяти, при отображении фрагментированной физической памяти в линейную (виртуальную). Почему же нет такого механизма в стандарте. Может, конечно, потому что его достаточно просто реализовать, или он заведомо будет медленнее, чем специальная реализация.

Именно заведомо будет медленнее. И твой случай ... Ну как бы совсем нетипичный.

Во многих OS используется механизм виртуальной памяти, при отображении фрагментированной физической памяти в линейную (виртуальную). Почему же нет такого механизма в стандарте. Может, конечно, потому что его достаточно просто реализовать, или он заведомо будет медленнее, чем специальная реализация.

Лучше скажи, зачем тебе сигнатуры сохранять...

Во многих OS используется механизм виртуальной памяти, при отображении фрагментированной физической памяти в линейную (виртуальную). Почему же нет такого механизма в стандарте. Может, конечно, потому что его достаточно просто реализовать, или он заведомо будет медленнее, чем специальная реализация.

простейшая реализация невытесняющей виртуальной памяти - это std::deque

Во многих OS используется механизм виртуальной памяти, при отображении фрагментированной физической памяти в линейную (виртуальную). Почему же нет такого механизма в стандарте. Может, конечно, потому что его достаточно просто реализовать, или он заведомо будет медленнее, чем специальная реализация.

ключевое слово "во многих". Что-то я сомневаюсь что на микроконтроллерах есть виртуальная память. В стандарте вообще понятия стека например нет насколько я знаю.

ключевое слово "во многих". Что-то я сомневаюсь что на микроконтроллерах есть виртуальная память. В стандарте вообще понятия стека например нет насколько я знаю.

Если на линукс RTLinux контроллер, то ведь будет...

плюс резать виртуальную память это все же дело ядра, из юзерспейса для себя нарезать очень нетипичная задача и не уверен, что так вообще можно

Если на линукс RTLinux контроллер, то ведь будет...

ну, линукс без вирт памяти вообще не заведется

насколько я слышал, бывает linux на железках без MMU

Именно заведомо будет медленнее. И твой случай ... Ну как бы совсем нетипичный.

Использование сторонних библиотек, на вашей сколь угодно фрагментированной памяти.

но это весьма специфический линух конечно

https://en.wikipedia.org/wiki/%CE%9CClinux

https://en.wikipedia.org/wiki/%CE%9CClinux

спасибо, не знал что такое есть

Всем привет! Меня зовут Костя и я программирую на С++.

Если кто-то активно использует #xcode и #cmake, то я добавил фичу "XCODE_STARTUP_PROJECT", по аналогии с вижлой. Чтобы замержить это в мастер требуют написать юнит-тест. Если кто любит парсить вручную файл xcode и писать на cmake регулярные выражения - готов все передать чтобы вместе мы сделали мир немного лучше.

Если кто-то активно использует #xcode и #cmake, то я добавил фичу "XCODE_STARTUP_PROJECT", по аналогии с вижлой. Чтобы замержить это в мастер требуют написать юнит-тест. Если кто любит парсить вручную файл xcode и писать на cmake регулярные выражения - готов все передать чтобы вместе мы сделали мир немного лучше.

На гитхаб выложи со ссылкой сюда

Если кто-то активно использует #xcode и #cmake, то я добавил фичу "XCODE_STARTUP_PROJECT", по аналогии с вижлой. Чтобы замержить это в мастер требуют написать юнит-тест. Если кто любит парсить вручную файл xcode и писать на cmake регулярные выражения - готов все передать чтобы вместе мы сделали мир немного лучше.

а как ты сам проверял, что фича заработала? вот им этот тест и нужен

Игорь привет

а как ты сам проверял, что фича заработала? вот им этот тест и нужен

проверял. Им формальный юнит-тест нужен по их процессам

https://gitlab.kitware.com/cmake/cmake/merge_requests/1399#note_341388

а почему ты сам не напишешь?

регулярки на cmake :(((

надо быть специфическим человеком чтобы писать это добровольно

они сейчас там более менее стали

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

они сейчас там более менее стали

звучит неплохо