Здравствуйте, rus blood, Вы писали:

RB>Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>>Кодт, Вы прелесть!

ЗХ>>Ушло в мой сборник цитат.

RB>Когда ждать это в сентенциях Голубицкого?
Причем тут Голубицкий? Я его даже не видел не разу?

RB>ЗЫ
RB>Я злой.

RB>Флейм задумывался как пародия на соседний "А вот не было бы Билла...", а ушло все в какие-то заумные дебри...
Да блин, вообще помимо "Если бы у бабушки были..." что на такое можно ответить? Вот потому люди и изгаляются кто как может...

Здравствуйте, Шахтер, Вы писали:

Ш>Если бы у бабушки был бы ..., то она была бы дедушкой.

Было бы что?
Если бы у бабушки был мусоросборщик, она была бы дворником.

Здравствуйте, rus blood, Вы писали:

X>>Что касается удобства программирования со сборкой мусора, то во всем есть свои плюсы и свои минусы.
RB>Минусы автоматической сборки можно?

Невозможность гарантировать время выполнения. Для real-time задач не подходит.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Gaperton, Вы писали:

G>Вот так . Так что это вдобавок и не так медленно, как кажется на первый взгляд . Особенно в многопоточных приложениях .

Увы, но GC и в джаве и в дотнете пока что блокируют все потоки.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Gaperton, Вы писали:

G>>Вот так . Так что это вдобавок и не так медленно, как кажется на первый взгляд . Особенно в многопоточных приложениях .

AVK>Увы, но GC и в джаве и в дотнете пока что блокируют все потоки.

If the collector is used in a multithreaded environment and configured for thread-local allocation, it may in some cases significantly outperform malloc/free allocation in time.

Здравствуйте, rus blood, Вы писали:

sc>>Просто нет привычки его использовать.
RB>Нет привычки именно потому, что он не встроен. Был бы встроен, ты бы его использовал на всю катушку, и даже не думал бы, что может быть как-то иначе...

Еще не в пользу коллекторов в C++ по-умолчанию: C/C++ уже давно был взят за стандарт de facto для разработок на микроконтроллерах, встроенной технике и пр. местах, где работа с памятью — наикритичнейшая весчь. и где гарбадж коллектор, при всей его экономии в разработке, был бы смертью в рантайме. поэтому его и небыло изначально. C/C++ ведь тоже кроссплатформенный (только не так как ява — скомпилил и запускай везде, а в другом смысле — есть компилятор под платформу — ты имея исходник сможешь запустить скомпилить его сам где надо), а проблемы с памятью даже сейчас еще НЕ в прошлом.

Короче, перефразируя: Если C/C++а не было бы, его стоило бы придумать. я бы его лично придумал

Т.е. в мире а) есть реальная потребность в простоте разрработки -> нужда в костылях типа ГЦ и б) есть реальная нужда в полном контроле над происходящим в железе на всех уровнях -> ассемблер, C/C++ и дата шиты
и эти потребности не пересекаются в плане применения

Здравствуйте, rus blood, Вы писали:


RB>Можно строить все по кирпичикам, по гвоздикам, заранее прокладывая водопровод и канализацию...
RB>А можно строить блочной (подомной, поквартальной, ...) застройкой, пытаясь их состыковать ...

Что-то это мне напоминает

21.04
Обсуждали проект. Сидоров предлагает крупноблочную архитектуру. Петрович говорит, что блоки громоздкие, плохо стыкуются друг с другом, содержат много лишнего и вообще еще неизвестно, какие у них там внутри трещины. Заявляет, что из блоков строят только законченные ламеры. Hастаивает, что все надо строить по старинке, из кирпича, хоть это и намного дольше. Самый радикальный проект предложил Алекс. Он говорит, что вообще не нужно строить 12-этажный дом, а нужно построить несколько десятков деревянных коттеджей и соединить их подземными туннелями. Дескать, на Западе сейчас так модно. Hапомнили ему, что заказчик требует именно 12-этажный дом. Он отбивался и кричал, что заказчики тупы по определению, и слушают их только законченные ламеры. В самый интересный момент дискуссии кончилось пиво. Решили продолжить завтра.

И особо

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

здесь

Здравствуйте, Ahven, Вы писали:

A>Что-то это мне напоминает

Все правильно. Это оно и есть...

How is this possible?
C-compatible garbage collectors know where pointers may generally be found (e.g., "bss", "data", and stack), and maintain heap data structures that allow them to quickly determine what bit patterns might be pointers. Pointers, of course, look like pointers, so this heuristic traces out all memory reachable through pointers. What isn't reached, is reclaimed.

Т.е. любые 4 байта на стеке они принимают за потенциальный указатель?
IMHO это хакерство.
Скажем, приложение постоянно выделяет/освобождает память, но никогда не выделяет больше 100 MB.
Если Java и .Net при наличии 100MB памяти обязательно их отдадут программе (потормозят, подвигают память, но отдадут),
то такому GC может померещиться, что память ещё занята, когда реально её уже никто не использует (ну, у int'а оказалось значение, указывающее в кучу), и он зажмёт её.
Работоспособность такого приложения под большим вопросом. Оно может заткнуться в самый неподходящий момент.

Думаю, для работы GC обязательно нужна compile-time информация.
Я понимаю, если бы они анализировали debug info и знали, где лежат указатели, но подозревать указатель в каждой ячейке памяти ...
Хотя в C/C++ даже debug info не достаточно — никто не гарантирует, что то, на что указывает void * не будет в один прекрасный момент приведено к какой нибудь структуре, внутри которой хранятся указатели.

Хотя, признаюсь, что ссылку я пока не читал. Может ими разработано какое-то противоядие?

Здравствуйте, Sergey, Вы писали:

S>Странно только, что ни один из ссылающихся на "Дизайн и эволюцию" не заметил
S>главы, где Страуструп рассуждал насчет сборщика мусора в С++

Почему же? Заметили. Именно тогда и зарадилась мысль о том, что Страуструп потерял связь с рельносью.

Здравствуйте, Шахтер, Вы писали:

Ш>Невозможность гарантировать время выполнения. Для real-time задач не подходит.

1. Можно собирать мустор параллельно с работой основного алгоритма.
2. Можно собирать мусор только в определенных участках кода где не требуется моментальный отклик. Многие СРВ допускают такие участки.
3. Можно иметь две системы исполения и переключаться на резервную когда первичная собирает мусор.

Ну, и наконец елси сборщик мусора опционален, то можно не использовать его в СРВ. А там где можно использовать.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Шахтер, Вы писали:

Ш>>Невозможность гарантировать время выполнения. Для real-time задач не подходит.

VD>1. Можно собирать мустор параллельно с работой основного алгоритма.
А если закончилась память, а критичному ко времени алгоритму она требуется?

VD>2. Можно собирать мусор только в определенных участках кода где не требуется моментальный отклик. Многие СРВ допускают такие участки.
А если закончилась память, а критичному ко времени алгоритму она требуется?

VD>3. Можно иметь две системы исполения и переключаться на резервную когда первичная собирает мусор.
бррррр

VD>Ну, и наконец елси сборщик мусора опционален, то можно не использовать его в СРВ.
А вот это правильно. СРВ и сборщик мусора несовместимы.

Здравствуйте, prVovik, Вы писали:

VD>>1. Можно собирать мустор параллельно с работой основного алгоритма.
V>А если закончилась память, а критичному ко времени алгоритму она требуется?

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

V>А если закончилась память, а критичному ко времени алгоритму она требуется?

Поставь еще один дим. Что тут можно еще постоветовть? "А если" не катят для СВР. Случай два обычно выглядит так: Есть некий набор операций которые должны проходить без прирываний. В таких участах нельзя ни выделять память, ни освобождать. Участки короткие и достаточно просто запретить вызов ЖЦ. Драйверы в виндвс примерно так и живут. Только тоам вообще речь идет о прирываниях, и пока нет ЖЦ.

VD>>3. Можно иметь две системы исполения и переключаться на резервную когда первичная собирает мусор.
V>бррррр

Что бррр? Самый надежный способ. Дорогой, но надежнее избыточности еще ничего не придумали. Если процессы хорошо изолированы (что в дотнете реализуется даже для одного физического процесса), то можно даже востанавливаться после серьезных сбоев.

VD>>Ну, и наконец елси сборщик мусора опционален, то можно не использовать его в СРВ.
V>А вот это правильно. СРВ и сборщик мусора несовместимы.

Это не так. Есть реализации СРВ со сборщиками мусура. Мне помнится кто-то из тех кто писал софт для QNX расказывал, что то ли у них, то ли в самой QNX есть ЖЦ и все ОК.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, prVovik, Вы писали:

VD>А как она закочится если ее постоянно собирают?
Ага, это типа: сборщик мусора с 99% вероятностью будет успевать освобождать память на нашем атомном реакторе

VD>Поставь еще один дим. Что тут можно еще постоветовть? "А если" не катят для СВР.
Вот по этому и требуется абсолютная детерминированность выполнения любых операций.

VD>Случай два обычно выглядит так: Есть некий набор операций которые должны проходить без прирываний. В таких участах нельзя ни выделять память, ни освобождать. Участки короткие и достаточно просто запретить вызов ЖЦ.
Ну если ввести запрет на выделение, то тогда да. А если нет ЖЦ, то и запрет этот ни к чему
Запретик то этот совсем не хилый. Вот представь себе такую СРВ, как компьютерная игра. Как тебе такой запрет: "Во время игрового процесса нельзя ни выделять, ни освобождать память". Не слабо получается

VD>Что бррр? Самый надежный способ. Дорогой, но надежнее избыточности еще ничего не придумали. Если процессы хорошо изолированы (что в дотнете реализуется даже для одного физического процесса), то можно даже востанавливаться после серьезных сбоев.
А постоянную репликацию как делать? Учитывая то, что сборка мусора может начаться в любой момент...

VD>Это не так. Есть реализации СРВ со сборщиками мусура. Мне помнится кто-то из тех кто писал софт для QNX расказывал, что то ли у них, то ли в самой QNX есть ЖЦ и все ОК.
Дык такм же вроде бы все на С....

Здравствуйте, B65E9A83-14B0-4e53-BA61-9F66C7D90A00, Вы писали:

B14>Думаю, для работы GC обязательно нужна compile-time информация.

Либо особые конвенции программирования.
Например, может быть работоспособной такая схема. Все указатели — умные, которые делают следующее:

void* operator new(size_t count);
void operator delete(void* block);

// контролируемый указатель

struct gc_pointer_struct
{
  void* value;
  gc_pointer_struct* next;
};

void register_gc_pointer(gc_pointer_struct* gps, bool onoff);
void notify_gc_pointer_change(gc_pointer_struct* gps, void* old);

// умный указатель

template<class T>
class gc_pointer : private gc_pointer_struct
{
public:
  gc_pointer(T* p = 0)            { value = p;     register_gc_pointer(this,true ); }
  gc_pointer(gc_pointer const& p) { value = (T*)p; register_gc_pointer(this,true ); }
  ~gc_pointer()                   { *this = 0;     register_gc_pointer(this,false); }

  gc_pointer& operator=(T* p) { void* old=value; value=p; notify_gc_pointer_change(this,old); return *this; }
  gc_pointer& operator=(gc_pointer const& p) { *this = (T*)p; }

  operator T*() const   { return  (T*)value; }
  T& operator*() const  { return *(T*)value; }
  T* operator->() const { return  (T*)value; }
};

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