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

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

для начала скажи, КАК и ОТКУДА появились у тебя ссылки? Не стесняйся, речь не о детях.

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

ну правильно: ты же хотел циклические ссылки?

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

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

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

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

как именно они работают тоже не знаешь?

КАК и ОТКУДА появились у тебя ссылки?

Например так:

class A
{
public:
    my_supper_smart_ptr<B> field_1;
    my_supper_smart_ptr<C> field_2;
};

Только не придерайся к смарт-поинтерам и пр. - используй тут что хочешь.

к public тоже не придирайся. Пусть будет private.

my_supper_smart_ptr<B> field_1;

1. это объявление некого объекта. Я спрашивал КАК они ВОЗНИКАЮТ?

2. задолбал с шаблонами. ОНИ ТУТ НЕ ПРИЧЁМ!

ты же хотел циклические ссылки?

Да, но твое решение не умеет с ними работать.

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

Это граф. Для него есть алгоритмы. Вопрос в том, как ты будешь этот граф строить.

задолбал с шаблонами. ОНИ ТУТ НЕ ПРИЧЁМ!

Это не шаблон, это поле типа my_super_smart_ptr<B>. И я же просил не придираться. Ты говорил про умные указатели. Скажи, как их обозначать в псевдокоде.

Да, но твое решение не умеет с ними работать.

умеет. Но вот именно этот алгоритм (не забудь погуглить значение слова «например») работает только с односвязанным списком, в т.ч. и с циклическим. Многосвязный граф == расширение односвязанного. Не вижу проблемы.

Это граф. Для него есть алгоритмы. Вопрос в том, как ты будешь этот граф строить.

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

ЗЫЖ наверное ты просто не понимаешь, что такое «создание сущности в C++», я угадал?

Это не шаблон, это поле типа my_super_smart_ptr<B>. И я же просил не придираться. Ты говорил про умные указатели. Скажи, как их обозначать в псевдокоде.

без символов <>, которые мне непонятны. Потому-что в C++ они имеют совершенно особый смысл. Это ШАБЛОНЫ, блжад! Используй что-нить другое. Ёлочки например. «B»

это объявление некого объекта. Я спрашивал КАК они ВОЗНИКАЮТ?

Как обычные поля. В конструкторе. Ну и с operator=. Например, так:

class A
{
public:
    typedef /* GC "ссылка" на объект типа B */ field_type;

    A()
        : field_1() // видимо это будет null-ссылка
    {
    }

    A(int x, const std::string & s)
        : field_1(/*операция создания объекта B в GC куче*/(x, s))
    {
    }

    void set_field_1(field_type field)
    {
        field_1 = field;
    }

    field_type get_field_1(field_type field)
    {
        return field_1;
    }

private:
    field_type field_1;
};

Ты, похоже, не знаешь С++. std::vector<int> - это не шаблон, а конкретный тип. А вот std::vector - это шаблон класса.

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

В моей яве ссылка никуда не вписывается при создании.

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

В какую позицию? С какими связями?

как именно они работают тоже не знаешь?

Меняют значение ссылок.

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

Я не понимаю, что ТЫ под этим понимаешь. Ибо на мой взгляд твой вопрос выглядит глупо. Обычное конструирование.

причем в том же ключе, что сказали next_time и emulek, но я им не мешаю, хотя и могу подключиться

Подключайся. Ты им не помешаешь - они ничего конкретного не говорят, хотя умудряются демонстрировать слабое понимание принципов работы GC. Да и С++ у них тоже хромает, судя по всему.

а вот граф ты будешь создавать в const field_type::operator=(const field_type &)

Ты, похоже, не знаешь С++. std::vector<int> - это не шаблон, а конкретный тип. А вот std::vector - это шаблон класса.

а почему ты не можешь обходится без шаблонов, тем более, что оппонент их по твоему «не знает»? Может ты ещё и свои посты будешь по-китайский писать, что-бы я ничего не понял?

В моей яве ссылка никуда не вписывается при создании.

а как тогда GC об этом узнаёт?

В какую позицию? С какими связями?

в нужную.

как именно они работают тоже не знаешь?

Меняют значение ссылок.

что мешает тебе менять значения полей класса?

Разумно. И вполне поддерживаемо модифицированными вариантами алгоритма подсчёта ссылок. Так в чём проблема, если мы договорились, что счётчик ссылок на плюсах легко реализуем?

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

Я не понимаю, что ТЫ под этим понимаешь. Ибо на мой взгляд твой вопрос выглядит глупо. Обычное конструирование.

ну. «Обычное конструирование». Что мешает во время конструирование сохранить информацию о том, С ЧЕМ связанна эта ссылка?

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

А есть другой способ задания умных указателей? Ты же сам о них вещал. Ну пиши без типа my_smart_ptr field_1

а как тогда GC об этом узнаёт?

jit компилятор составляет карты

в нужную

Как мы ее определяем?

что мешает тебе менять значения полей класса?

Мне? Ничего. А GC это помешает отсутствие знаний о том, какие поля у класса есть.

И вполне поддерживаемо модифицированными вариантами алгоритма подсчёта ссылок.

Например?

И вполне поддерживаемо модифицированными вариантами алгоритма подсчёта ссылок.

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

Либо «перемещать» надо внутренний умный указатель, а клиенту отдать ссылку на этот внутренний указатель. Тогда ссылок у клиента будет много, но указатель один.

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

Что мешает во время конструирование сохранить информацию о том, С ЧЕМ связанна эта ссылка?

Т.е. передавать руками в поле-ссылку указатель на this? Пипец у вас представления о GC.

Как минимум, о том, где содержится эта ссылка(полем какого объекта является). Скажешь, откуда эту информацию брать - продолжим.

А есть другой способ задания умных указателей? Ты же сам о них вещал. Ну пиши без типа my_smart_ptr field_1

ну вот и пиши. А то я не понимаю, при чём тут шаблоны. Ты не забывай, что STL — универсальный костыль для всего. Вот там и шаблоны везде. А мы сейчас просто о GC говорим. Давай сначала с ним разберёмся, а уж потом будем шаблоны городить, если оно конечно нужно.

jit компилятор составляет карты

угу. jit обладает особой магией?

А GC это помешает отсутствие знаний о том, какие поля у класса есть.

Вот именно по этому GC в C++ и не параметризируется. Чего ты так упорно хочешь добиться своими <>. А если-бы ты делал GC на основе классов и наследования, то тогда этот твой GC прекрасно-бы знал про все поля. Те, что его, он бы знал потому, что они ЕГО, а к новым имел-бы доступ через специально обученные чистые виртуальные функции.

IRL делается общий базовый класс, и от него наследуются классы array, integer, string, и так далее.

Т.е. передавать руками в поле-ссылку указатель на this?

зачем этому полю этот this? (как я понимаю, ты про class A, в котором поле?)

class A
{
 f_type f;
};

вот код, в каких случаях A::f может поменяться? Зачем этому f нужен this класса A?

На ум приходит только один случай: ты забыл перезагрузить operator=(), и при копировании A у тебя тупо затёрся твой умный указатель A::f. Ты в таком случае ССЗБ.

Тут про STL никто и не говорил.

Так объект класса A тоже в куче GC находится.

Никакой особой магии. Обычный такой jit. Есть libjit, можешь посмотреть. Еще есть llvm, но там лишь поддержка GC, так что нужен еще компилятор особый. Но таки да, на этом можно сделать свой компилятор c++ с расширением в виде GC. С помощью расширения libjit тоже можно было бы придумать что-нибудь, но использовать это будет крайне неудобно.

зачем этому полю этот this?

Ну каким-то образом надо будет сборщику понимать, что объект класса A имеет два поля, по которым нужно пойти, чтобы пометить объекты как достижимые, если достижим какой-то объект класса A.

ты пропустил. Мотай сам на std::smart_pointer, или как его там?

Так объект класса A тоже в куче GC находится.

ох... A НЕ находится в куче, и A::field тоже НЕ находится в куче.

Никакой особой магии. Обычный такой jit. Есть libjit, можешь посмотреть

ну вот видишь? Прокладка нужна. Я предлагаю юзать классы C++. Ты предлагаешь jit. В чём разница-то?

Вот именно по этому GC в C++ и не параметризируется.

Что эта фраза вообще означает? А где GC параметризуется? Он может настраиваться, можно указать вид и пр.

А если-бы ты делал GC на основе классов и наследования, то тогда этот твой GC прекрасно-бы знал про все поля.

Откуда? Как наследование тебе поможет знать все поля?

Те, что его, он бы знал потому, что они ЕГО

Поля GC? Ты вообще понимаешь, что GC - это отдельный модуль? А то, что пишешь ты - это как сейчас делается в С++. Т.е. ручное управление памятью, разбавленное RAII. Так и делаем, я не против. Но это не GC, а мы тут о GC говорили.

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

И что, в каждом классе мне все это нужно переопределять? Это не GC.

делается общий базовый класс, и от него наследуются классы array, integer, string, и так далее.

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

std::shared_ptr? Это не STL. Я тебе открою тайну, но std::string не STL, равно как и iostream'ы, например.

Объекты класса A тоже находятся в куче. В этом и был смысл примера. Если объект класса A достижим, то достижим и объект, на который ссылается A::field. И т.д. Это и есть тот граф. И тебя тут спрашиваю, как ты собираешься его строить.

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

И где тут GC? В названии класса?

Garbage collection(computer science)

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

нет. Не нужно никаких макров/шаблонов. Смотри:

int main()
{
  A s1 = "Hello";// создание объекта
  A s2 = s1;// создание ссылки
  A s3 = "world";
  s2 = s3;
  s1 = s2 + s3;
  char c = s1[0];// это буква "w"
  return 0;
}// тут GC собирает мусор s1, s2, s3