Есть ли под С++ годные библиотеки для веб девелопмента?

вообще не понял смысл сентенции

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

Важен алгоритм поиска мусора или достижимых объектов.

ну рассказывай свой алгоритм. Жду с нетерпением. Только чур без магии. И без ссылок на какие-то алгоритмы для C++. Рассказывай про СВОЙ, ГОДНЫЙ.

Глядишь, я просвятлюсь, и каши в моей голове поубавится...

Покажь, как

Конечно, один. С кем-нибудь в команде никогда не работал, не работаю и не собираюсь работать. Я лучше уж сам, чем в чужом разбираться...

у меня тут есть одна идейка, и я думаю, тебя она заинтересует. Речь про поля Галуа, ты про них что-то знаешь?

Слыхал, но не ковырялся в теории.

Так рассказывали тебе уже. Ты пропустил мимо ушей? Все эти GC-карты для классов, функций и пр. тебе ни о чем не говорят?

а в сях просто делаешь union

И получаешь непереносимый код.

как будто на этих ваших смалталкояворубепитонах код переносимый, ага

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

Проблемы при использовании(а не реализации) данного алгоритма в С++: получение смещений полей-ссылок типа, обход рутовых ссылок(на стеке, регистрах, статических ссылок, обычной кучи и т.п.), перемещение объектов.

И пофиг.

Проблемы при использовании(а не реализации) данного алгоритма в С++: получение смещений полей-ссылок типа, обход рутовых ссылок(на стеке, регистрах, статических ссылок, обычной кучи и т.п.), перемещение объектов.

почему ты так упорно пользуешься глупыми указателями? Почему, если C++, то ОБЯЗАТЕЛЬНО нужно юзать какие-то «адреса в памяти»? Почему в своей жабке нет никаких адресов, а в C++ ты без них не можешь обходится?

Ты сам ведь объяснешь мне, что сделать нормальный GC с глупыми указателями невозможно. В чём проблема? НЕ ИСПОЛЬЗУЙ ГЛУПЫЕ УКАЗАТЕЛИ В GC. GC должен работать с умным указателем, у которого нет никаких «адресов» и «смещений». И который НЕ МОЖЕТ лежать на стеки, в куче, или быть глобальным. НЕ МОЖЕТ. Это абстракция, и все твои рассуждения попросту к ней неприменимы. Вот в твоей любимой жабке ссылка помнит на что она ссылается? Да? Если ссылка сдохла, но на неё что-то ещё ссылается, то ссылка не дохнет, так? Значит — помнит. А вот глупый указатель — не помнит. В этом-то вся и проблема: если у тебя есть глупый указатель *x, и его копия *y, то указатель *x НЕ ПОМНИТ, что у него есть копия *y. А в твоей жабке — помнит.

Что мешает тебе сделать умный указатель X, который потому и умный, что помнит, что у него есть копия Y, религия?

ты путаешь ссылки и объекты. на ссылку ничего не ссылается.

ты путаешь ссылки и объекты. на ссылку ничего не ссылается.

я ничего не путаю. Объект может быть ссылкой. А может и не быть (лист, leaf). Выше были примеры ссылки B на A, когда A это ссылка на B, и те, кто такие примеры приводил, утверждали, что это «обычное дело». В этом случае лист вообще отсутствует.

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

Почему в своей жабке нет никаких адресов, а в C++ ты без них не можешь обходится?

Для GC адреса есть. Для С++ реализации ты можешь определить свой умный указатель. Или несколько, если нужно. Никто не запрещает. Распиши алгоритм сборки только.

GC должен работать с умным указателем, у которого нет никаких «адресов» и «смещений».

Пусть работает. Опиши как.

И который НЕ МОЖЕТ лежать на стеки, в куче, или быть глобальным. НЕ МОЖЕТ

А где он будет лежать? Понятно, что объект будет лежать в куче GC, а «ссылка»-то где будет лежать сама?

Вот в твоей любимой жабке ссылка помнит на что она ссылается? Да? Если ссылка сдохла, но на неё что-то ещё ссылается, то ссылка не дохнет, так?

На ссылку никто не может ссылаться. Ссылка сама ссылается на объект, ссылку же можно только держать у себя. Ссылаться на нее саму(а не объект, на который она ссылается) нельзя.

если у тебя есть глупый указатель *x, и его копия *y, то указатель *x НЕ ПОМНИТ, что у него есть копия *y. А в твоей жабке — помнит.

Нет, в жабке не помнит. С чего ты взял? За нее «помнит» jit, в процессе анализа, интерпретации и выполнения кода.

Что мешает тебе сделать умный указатель X, который потому и умный, что помнит, что у него есть копия Y

Ничего. Дальше-то что ты собрался делать?

Он ничего про глупые указатели не писал. Ты опять фантазируешь.

«смещение», «адрес в памяти», и прочее, это по твоему не глупые указатели?

Иди, подучи матчасть, потом возвращайся.

Это описание реализации сборщика, а не его использования. Как ты собрался работать с памятью без адресов? Как ты собрался перемещать объекты в памяти без адресов? Как ты собрался выделять память без адресов? Ты с ума сошел?

А где он будет лежать? Понятно, что объект будет лежать в куче GC, а «ссылка»-то где будет лежать сама?

а вот сама ссылка может лежать где угодно. Вот только ты почему-то упрямо и тупо считаешь, что «ссылка» — обязательно что-то такое в терминах C++. Нет, ссылка в данном контексте — объект некого класса. Который ссылается на другой объект. Т.е. это НЕ адрес другого объекта! Если ссылка уходит из области видимости(например вызван неконстантный метод или деструктор), то GC помечает объект, на который указывает ссылка, как «предположительно мусор». Ну например уменьшает счётчик ссылок на 1. Мусор — это если счётчик ==0.

На ссылку никто не может ссылаться. Ссылка сама ссылается на объект, ссылку же можно только держать у себя. Ссылаться на нее саму(а не объект, на который она ссылается) нельзя.

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

Вообще-то, на эту тему есть много литературы, и мне лениво её тут пересказывать...

Нет, в жабке не помнит. С чего ты взял? За нее «помнит» jit, в процессе анализа, интерпретации и выполнения кода.

меня не волнует, ЧТО помнит. С т.з. алгоритма GC это не имеет значения. Мальчик с блокнотиком тоже подойдёт.

Ничего. Дальше-то что ты собрался делать?

я уже делал GC. Да, в C++. Теперь ты мне будешь рассказывать, что я сделал невозможное? Ну давай, рассказывай...

а вот сама ссылка может лежать где угодно.

Так вот о том и речь.

Вот только ты почему-то упрямо и тупо считаешь, что «ссылка» — обязательно что-то такое в терминах C++.

Нет. С чего ты взял подобные глупости?

Нет, ссылка в данном контексте — объект некого класса. Который ссылается на другой объект.

Хорошо.

то GC помечает объект, на который указывает ссылка, как «предположительно мусор». Ну например уменьшает счётчик ссылок на 1. Мусор — это если счётчик ==0.

Ты издеваешься? Это не полноценный сборщик, а подсчет ссылок. В его возможности для С++ никто не сомневается. Тем более, что он теперь даже в стандартной библиотеке реализован в виде std::shared_ptr.

я уже делал GC. Да, в C++.

Ну и чего ты тут людей мучаешь? Давно рассказал бы свой алгоритм сборки и в каком виде ты предусмотрел его использование в С++.

Теперь ты мне будешь рассказывать, что я сделал невозможное?

Я(и не только) просто попросил тебя расписать свой алгоритм.

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

Ты опять выдаешь подсчет ссылок за полноценный GC? Все знают, что подсчет ссылок или его аналог может быть реализован на С++.

А зачем?

откройте для себя, наконец, размещающую версию оператора new и не парьте людям мозг

откройте для себя, наконец, размещающую версию оператора new и не парьте людям мозг

Как при помощи размещающего оператора new понять стал уже этот объект мусором или нет?

Я его уже лет 10 как открыл. Какое отношение он имеет к GC?

С помощью размещающего оператора new надо передать объект внешнему сборщику мусора, а он разберётся.

И как внешний сборщик будет строить граф объектов, определять рутовые ссылки и пр.? Сборщик мусора работает не просто с памятью, а с графом объектов.

Каким образом он разберётся? Вопрос то именно в этом.

И как внешний сборщик будет строить граф объектов, определять рутовые ссылки и пр.? Сборщик мусора работает не просто с памятью, а с графом объектов.

да, похоже это можно

у меня есть набросок как сделать точный перемещающий сборщик мусора для с++ (precise moving gc for c++) — причем в том же ключе, что сказали next_time и emulek, но я им не мешаю, хотя и могу подключиться

основная проблема, по-моему, это то, что в момент вызова сборки мусора кое-какие ссылки могут застрять в регистрах (и во временных областях, куда компилятор сбрасывает регистры); поэтому надежно будет использовать счетчики ссылок, а gc будет искать и собирать циклические ссылки

Another solution is to periodically use a tracing garbage collector to reclaim cycles. http://en.wikipedia.org/wiki/Reference_counting#Dealing_with_reference_cycles

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

Так тут по-моему писали, что можно. Просто это будет долго и без мемоизации GC-карты(т.е. карта будет строиться каждый раз для каждой функции/потока исполнения, каждый раз при создании объекта, хотя поля же одни для всех экземпляров класса и т.д.). Во всяких же .NET'ах компилятор помогает сборщику, вставляя информацию о ссылочных полях класса, а jit строит карту GC. Для С++ же это будет делаться только в рантайме и не слишком оптимально.

Или ты собираешься обходится без этой информации и у тебя какой-то хитрый алгоритм?

Твой уровень явно выше emulek, так что делись алгоритмом с общественностью=)

Надо еще forCe подождать.

а вот сама ссылка может лежать где угодно.

Так вот о том и речь.

ссылка — это просто маленький контейнер на несколько байтов. Её распределением может сам ЯП заниматься, также, как он занимается распределением int & double. Для этих контейнеров не нужен никакой GC.

причина проста: если такими контейнерами управляет компилятор, то он может их загрузить в регистры, и тогда время сократится на порядки(по сравнению со всякими php/java, где это невозможно в принципе).

Нет. С чего ты взял подобные глупости?

да. Под «полноценным сборщиком» ты и понимаешь работу с контейнерами как с глупыми указателями. В твоей jave/php это тоже невозможно в принципе сделать, но ещё и искусственно запрещено даже пытаться. В C/C++ можно попытаться. Получится fail ессно.

то GC помечает объект, на который указывает ссылка, как «предположительно мусор». Ну например уменьшает счётчик ссылок на 1. Мусор — это если счётчик ==0.

Ты издеваешься? Это не полноценный сборщик, а подсчет ссылок.

хорошо. Другой вариант:

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

Плюсы:

1. ссылка может указывать на ссылку, а не только на объект.

2. ссылка может указывать на несколько объектов/ссылок

3. можно циклические битые ссылки, которые ни указывают ни на один объект.

4. можно грабить караваны.

Собственно минус один: поддерживать список очевидно намного дороже поддержки счётчика.

Тем более, что он теперь даже в стандартной библиотеке реализован в виде std::shared_ptr.

открой наконец Страуструпа, и узнай, что ШАБЛОН != КЛАСС. Между ними такая же разница, как между скалкой и гранатой Ф1.

Ну и чего ты тут людей мучаешь? Давно рассказал бы свой алгоритм сборки и в каком виде ты предусмотрел его использование в С++.

я их несколько делал. И я не понимаю, какой именно аспект вам непонятен.

Я(и не только) просто попросил тебя расписать свой алгоритм.

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

Простейший вариант с подсчётом ссылок вас не устраивает. Почему нет? Ну ладно, есть вариант со списком ссылок.

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

макросы я не люблю, и использую только самые примитивные типа MIN(X,Y) (((X)<(Y))?(X):(Y)) Что тебе не нравится в подсчёте ссылок — я так и не понял. ИМХО это уже детали реализации.

И как внешний сборщик будет строить граф объектов, определять рутовые ссылки и пр.? Сборщик мусора работает не просто с памятью, а с графом объектов.

вот new и будет строить граф для GC.

покажите сначала шуруп.

Вы поаккуратней с такими просьбами к анону, а то ведь покажет :)

типа MIN(X,Y) (((X)<(Y))?(X):(Y))

для этого есть inline-функции, вообще-то

Присоединяюсь к вопросу. Вы сначала определитесь, что за сборщик мусорщик нужен, какие к нему требования. И чем конкретно вас не устроил подсчёт ссылок.

для этого есть inline-функции, вообще-то

вообще-то inline функция не умеет работать с int и double одновременно. Да и вообще это НЕ макрос.

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

у него нет для этого информации.

список не решает проблемы циклов

как минимум он должен разруливать циклические зависимости и поддерживать возможность переноса объектов в своей куче.

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

но не говорят — «как».

у него нет для этого информации.

какой именно информации не хватает new?

список не решает проблемы циклов

решает. Ссылка A знает, что на неё ссылается ссылка B, а ссылка B знает, что на неё ссылается ссылка A. Когда GC захочет удалить ссылки A и B, он может распознать этот факт. К примеру GC может одновременно прыгать по списку двумя указателями(один +=1, второй +=2), и если они встретятся, значит список закольцован, и никуда не указывает.

как минимум он должен разруливать циклические зависимости и поддерживать возможность переноса объектов в своей куче.

про циклы см. выше

Про перенос: new отдаёт контейнер, в котором есть указатель на данные. Когда данные надо перенести, мы ищем все контейнеры, переносим данные, и сдвигаем указатели внутри контейнера.

Альтернативный вариант: в контейнере указатель на специальный контейнер, в котором указатель на данные. Мы переносим данные, и меняем один указатель в спец-контейнере.

С вероятностью 95%, в твоём любимом бейсике один из двух вариантов (вероятность 5% я отдаю на какую-то упоротую ещё более сложную организацию)

какой именно информации не хватает new?

О полях-ссылках. Как ты собираешься строить граф?

Ссылка A знает, что на неё ссылается ссылка B, а ссылка B знает, что на неё ссылается ссылка A.

Откуда? У тебя граф получится в итоге, а не линейный список.

К примеру GC может одновременно прыгать по списку двумя указателями(один +=1, второй +=2), и если они встретятся, значит список закольцован, и никуда не указывает.

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

С вероятностью 95%, в твоём любимом бейсике один из двух вариантов

Не знаю, как там в бейсике, но GC так не работают уже лет 20.