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

RB>Что тогда было бы с современными языками программирования?
RB>Где тогда были бы Java или .Net, и были бы они вообще???

RB>ЗЫ Просто флейм...

а что было бы если бы не было флеймеров?
где тогда были бы модераторы, и были бы они вообще???

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

RB>Возможно (только не бейте!!!), если бы в C++ изначально был встроен сборщик, возникла бы идея сделать ЕГО кроссплатформенным, а не городить с Джавой...

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

Язык С++ позиционировался как язык "С с классами", т.е. язык, такой же низкоуровневый, генерирующий код, такой же быстрый, такой же компактный, такой же не нуждающися в большом рантайме, язык, позволяющий контролировать все и вся, включая захват и освобождение ресурсов, как и язык С, на котором, вперемешку с ассемблером(!), в то время писалось фактически все, и который и по сей день составляет основу кода всех популярных операционных систем и многих известных программ.

Так вот, я расскажу, где бы был язык С++, если бы там "изначально был сборщик мусора". Тогда С++ бы так бы и остался чисто академическим проектом среди большого колчиества таких же никому не нужных в то время уродцев.

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

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

К>Просто к слову. Garbage Collection — это не ЖЦ, а, скорее, ГК. То есть Городская Канализация

Кстати, если пользоваться этой метафорой, то в С++ельской местности канализацию не прокладывают, обходясь более или менее обустроенными индивидуальными удобствами — во дворе (Си) или в пристройке, возможно, "био" (С++).
А вот в городе без центральной канализации (включающей не только сортиры, но и водосборники, и ливневую канализацию) была бы не жизнь.

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

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

Например, Smalltalk 72 и LISP

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

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

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

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

RB>Что тогда было бы с современными языками программирования?
RB>Где тогда были бы Java или .Net, и были бы они вообще???
Для С++ есть сборщики мусора . Используется т. н. пессемистическая схема.
http://www.cs.kent.ac.uk/people/staff/rej/gc.html#Software

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

RB>Что тогда было бы с современными языками программирования?
RB>Где тогда были бы Java или .Net, и были бы они вообще???

RB>ЗЫ Просто флейм...

А что было бы с Джавой если бы там не было сборщика мусора?

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

RB>Что тогда было бы с современными языками программирования?
RB>Где тогда были бы Java или .Net, и были бы они вообще???

RB>ЗЫ Просто флейм...

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

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

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


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

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

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

И особо

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

здесь

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

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

G>>Для С++ есть сборщики мусора . Используется т. н. пессемистическая схема.
G>>http://www.cs.kent.ac.uk/people/staff/rej/gc.html#Software

RB>Ну исскуственные, понятно, есть.
RB>Только чтобы использовать их, нужно поддерживать ряд ограничений.
Основное ограничение — не хитрить, и хранить указатели как нормальные указатели.
RB>Пойнтеры, там, специальные, правила всякии (сильные-слабые дескрипторы и пр.).
Пойнтеры самые обычные, ничего специального. Я же сказал, пессемистическая схема. Что это означает?
Если кратко, то все считается потенциальным указателем, и проверяется GС на совпадение с началом выделенного блока памяти. А если вообще — то www.memorymanagement.org

RB>К тому же, могут быть проблемы с многопоточностью, производительностью, и ресурсами...
Проблем с многопоточностью не будет. С ресурсами — тоже. Производительность — ну несколько
медленнее чем обычный GC.

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

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

B>а что было бы если бы не было флеймеров?
а также матершинников, баянистов, оверклокеров, просто хамов и т.д.

B>где тогда были бы модераторы, и были бы они вообще???
наверно и форумов бы не было...

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

M>Чем тебя auto_ptr не устраивает?
а чем он может устраивать???

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

M>Чем тебя auto_ptr не устраивает?

Тем, что это одна из возможных, к тому же, прямо скажем, ублюдочная политика владения.

Про владеющие и невладеющие умные указатели лучше медитировать на книгах Джефа Элджера и Андрея Александреску, чем на несчастном auto_ptr.

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

VD>Поверь если бы это было так, то никто не городил бы огород, а просто приделал бы ЖЦ к С++. У МС на это точно ресурсов и смелости хватило бы.

Просто к слову. Garbage Collection — это не ЖЦ, а, скорее, ГК. То есть Городская Канализация

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

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

К>>Просто к слову. Garbage Collection — это не ЖЦ, а, скорее, ГК. То есть Городская Канализация

К>Кстати, если пользоваться этой метафорой, то в С++ельской местности канализацию не прокладывают, обходясь более или менее обустроенными индивидуальными удобствами — во дворе (Си) или в пристройке, возможно, "био" (С++).
К>А вот в городе без центральной канализации (включающей не только сортиры, но и водосборники, и ливневую канализацию) была бы не жизнь.

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

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

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

ЗХ>Кодт, Вы прелесть!
А вот этого не надо!

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

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

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

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

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

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

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

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

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

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

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

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

Что тогда было бы с современными языками программирования?
Где тогда были бы Java или .Net, и были бы они вообще???

ЗЫ Просто флейм...

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

RB>Что тогда было бы с современными языками программирования?
RB>Где тогда были бы Java или .Net, и были бы они вообще???

я думаю было бы всё как сейчас.

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

RB>Что тогда было бы с современными языками программирования?
RB>Где тогда были бы Java или .Net, и были бы они вообще???

RB>ЗЫ Просто флейм...
Чем тебя auto_ptr не устраивает?

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

K>я думаю было бы всё как сейчас.
не знаю, не знаю...
поработав с C# отметил про себя особый кайф от того, что не надо особо заботиться о том, какой объект каким "владеет", а у кого просто ссылки и указатели, и о том, кто и когда из объектов умрет. Если бы это изначально было встроено в c++ не знаю, чем бы еще язык C# кардинально отличался от C++...

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

G>Для С++ есть сборщики мусора . Используется т. н. пессемистическая схема.
G>http://www.cs.kent.ac.uk/people/staff/rej/gc.html#Software

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

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

MS>А что было бы с Джавой если бы там не было сборщика мусора?

Не знаю, наверно была "Джава без сборщика мусора".
Меня не интересует Джава сама по себе, я не хочу устраивать "священные войны".
Меня интересует мнение по C++, и его влияние на все остальное...

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

RB>Что тогда было бы с современными языками программирования?
RB>Где тогда были бы Java или .Net, и были бы они вообще???

RB>ЗЫ Просто флейм...

C++ настолько мощный и гибкий язык, что позволяет сделать все, в том числе и сборщик мусора. Просто нет привычки его использовать.
Интересно, а на чем написана виртуальная машина java и .net?
Есть подозрения, что все на том же С++. И в таком случае сборщики мусора написаны на нем же.

Так что все было бы также, как и сейчас))

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

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

RB>>Что тогда было бы с современными языками программирования?
RB>>Где тогда были бы Java или .Net, и были бы они вообще???

RB>>ЗЫ Просто флейм...

sc>C++ настолько мощный и гибкий язык, что позволяет сделать все, в том числе и сборщик мусора.
Флейм не об этом... Я говорю о встроенном сборщике, а не об исскуственном построении...

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

sc>Интересно, а на чем написана виртуальная машина java и .net?
sc>Есть подозрения, что все на том же С++. И в таком случае сборщики мусора написаны на нем же.
Увы, они встроены в java и в языки .net. Флейм по C++.

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

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

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

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

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

RB>Еще раз. Флейм не про то, что их можно сделать.
RB>Флейм про то, что было бы, если бы эти сборщики были бы встроены в язык изначально.
RB>В стандарт, так сказать...

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

Java был создан как многоплатформенный язык программирования. Один раз компилишь и везде выполняешь. Что сокращает расходы на разработку и поддержку.

.Net был создан для повышения скорости, качества разработки. Другими словами для ускорения зарабатывания денег. По крайней мере Майкрософт на нем уже заработала.

Другие языки и технологии тоже были созданы для решения каких-то конкретных задач.

Так что бизнес и экономика никак не связаны со сборщиком мусора.

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

sc>Java был создан как многоплатформенный язык программирования. Один раз компилишь и везде выполняешь. Что сокращает расходы на разработку и поддержку.
Давайте не будем про многоплатформенность. Эта идея была придумана задолго до Java...
К тому же, причем тут тема флейма и многоплатформенность?
Многоплатформенность — это еще не повод включать сборщик в язык. Тем не менее, в Java он включён...

Возможно (только не бейте!!!), если бы в C++ изначально был встроен сборщик, возникла бы идея сделать ЕГО кроссплатформенным, а не городить с Джавой...


sc>.Net был создан для повышения скорости, качества разработки. Другими словами для ускорения зарабатывания денег. По крайней мере Майкрософт на нем уже заработала.
Ну это вообще, просто слова...

sc>Так что бизнес и экономика никак не связаны со сборщиком мусора.
Не скажи... Вспоминая "бабочку Бредбери" можно сказать, нельзя гарантировать, что наличие сборщика никак не повлияло бы на мейнстрим развития языков...

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

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

Поверь если бы это было так, то никто не городил бы огород, а просто приделал бы ЖЦ к С++. У МС на это точно ресурсов и смелости хватило бы.

Hello, Xentrax!
You wrote on Wed, 01 Sep 2004 17:53:20 GMT:

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

X> Язык С++ позиционировался как язык "С с классами", т.е. язык, такой же
X> низкоуровневый, генерирующий код, такой же быстрый, такой же компактный,
X> такой же не нуждающися в большом рантайме, язык, позволяющий
X> контролировать все и вся, включая захват и освобождение ресурсов, как и
X> язык С, на котором, вперемешку с ассемблером(!), в то время
X> писалось фактически все, и который и по сей день составляет основу кода
X> всех популярных операционных систем и многих известных программ.

X> Так вот, я расскажу, где бы был язык С++, если бы там "изначально был
X> сборщик мусора". Тогда С++ бы так бы и остался чисто академическим
X> проектом среди большого колчиества таких же никому не нужных в то время
X> уродцев.

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

With best regards, Sergey.

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

RB>Что тогда было бы с современными языками программирования?
RB>Где тогда были бы Java или .Net, и были бы они вообще???

А вот насколько я помню есть такой gc который и есть сборщик мусора под С++ (на шаблонах писан). Где-то на сурсфордже лежит. ИМХО сборка мусора далеко не самое важное отличие С++ от С#

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

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

RB>>Возможно (только не бейте!!!), если бы в C++ изначально был встроен сборщик, возникла бы идея сделать ЕГО кроссплатформенным, а не городить с Джавой...

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

X>Язык С++ позиционировался как язык "С с классами", т.е. язык, такой же низкоуровневый, генерирующий код, такой же быстрый, такой же компактный, такой же не нуждающися в большом рантайме, язык, позволяющий контролировать все и вся, включая захват и освобождение ресурсов, как и язык С, на котором, вперемешку с ассемблером(!), в то время писалось фактически все, и который и по сей день составляет основу кода всех популярных операционных систем и многих известных программ.
Да я не о том, как и зачем создавался C++. Я о том, что было бы с остальными (не с С++!!!), если бы в него добавили еще и сборщик...


X>Так вот, я расскажу, где бы был язык С++, если бы там "изначально был сборщик мусора". Тогда С++ бы так бы и остался чисто академическим проектом среди большого колчиества таких же никому не нужных в то время уродцев.
Вот не факт. Пример с Джавой...


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

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

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

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

VD>Поверь если бы это было так, то никто не городил бы огород, а просто приделал бы ЖЦ к С++. У МС на это точно ресурсов и смелости хватило бы.

Угу. "Взять C++, добавить сборщик, добавить кроссплатформенное исполнение, убрать всякие непонятные, а потому, наверно, ненужные вещи". И что получим? Наверно, Джава... (ну все, точно в "войны" перенесут... )

Ну а если бы сборщик был бы изначально?

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

RB>Угу. "Взять C++, добавить сборщик, добавить кроссплатформенное исполнение, убрать всякие непонятные, а потому, наверно, ненужные вещи". И что получим? Наверно, Джава... (ну все, точно в "войны" перенесут... )

Это вряд ли. Java сильна единым стандартом, который все разработчики разных JVM поддреживают.А про несоответствие стандарту того или иного C++ компилятора можно писать целые тома.
Таким образом, если я напишу библиотеку на Java, она будет гарантированно работать под все поддерживаемые платформы. А на С++ попробуйте тот же boost запихать под EVC3.0/PPC 2002? Хотя казалось бы просто библиотека шаблонов. А что будет с чем-то посеръезнее аля мультиплатформенный GUI или CORBA? Горы ненужной работы, только для того, чтобы она хотя бы компилировалась где нужно.

Так, что не сравнивайте. Java — это единое сообщество, а в С++ каждый сам за себя.

Hello, adb!
You wrote on Thu, 02 Sep 2004 09:24:39 GMT:

a> Это вряд ли. Java сильна единым стандартом, который все разработчики
a> разных JVM поддреживают.А про несоответствие стандарту того или иного
a> C++ компилятора можно писать целые тома. Таким образом, если я напишу
a> библиотеку на Java, она будет гарантированно работать под все
a> поддерживаемые платформы.

Сказки только не надо рассказывать про то, что все JVM одинаковые

With best regards, Sergey.

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

S>Сказки только не надо рассказывать про то, что все JVM одинаковые

По сравнению с _популярными_ компиляторами С++, все JVM можно считать одинаковыми.

Hello, adb!
You wrote on Thu, 02 Sep 2004 10:45:16 GMT:

S>> Сказки только не надо рассказывать про то, что все JVM одинаковые

a> По сравнению с _популярными_ компиляторами С++, все JVM можно считать
a> одинаковыми.

Разве что по сравнению. Однако фраза "Таким образом, если я напишу
библиотеку на Java, она будет гарантированно работать под все поддерживаемые
платформы" правильней от этого не станет.

With best regards, Sergey.

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

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

RB>Еще раз. Флейм не про то, что их можно сделать.
RB>Флейм про то, что было бы, если бы эти сборщики были бы встроены в язык изначально.
RB>В стандарт, так сказать...
Погодите, в третьей версии будут отдельные части (так как слишком большой станет стандарт), и одна из частей явно будет стандартизировать схему сборки мусора для С++
RB>Просто есть мысля, что именно отсутствие сборщиков в C++ сподвигло создавать языки, где он встроен изначально. По крайней мере, вохможно это был один из движущих мотивов.
Да, конечно! Задолбали всех нулевые указатели.

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

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

Можно, Д.Кнут. Том 1. Раздел 2.5 "Динамическое выделение памяти". Очень популярно все описано

Вдогонку к теме — небольшой материалец.
http://www.iecc.com/gclist/GC-faq.html#GC,%20C,%20and%20C++

What do you mean, garbage collection and C?
Rather than using malloc and free to obtain and reclaim memory, it is possible to link in a garbage collector and allow it to reclaim unused memory automatically. This usually even works if malloc is replaced with the garbage collector's allocator and free is replaced with a do-nothing subroutine. This approach has worked with the X11 library, for instance.
It is also possible to program in a style where free still reclaims storage, but the garbage collector acts as a backstop, preventing leaks that might otherwise occur. This style has also been tested with many applications, and it works well. The advantage here is that where it is easy for the programmer to manage memory, the programmer manages the memory, but where it is not, the garbage collector does the job. This doesn't necessarily run any faster than free-does-nothing, but it may help keep the heap smaller.

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.

Хм, прикольно. Все веселее и веселее
Выдержка из инфы к первому GC для С/С++ из списка — The Boehm-Weiser Conservative Collector.

Performance of the nonincremental collector is typically competitive with malloc/free implementations. Both space and time overhead are likely to be only slightly higher for programs written for malloc/free (see Detlefs, Dosser and Zorn's Memory Allocation Costs in Large C and C++ Programs.) For programs allocating primarily very small objects, the collector may be faster; for programs allocating primarily large objects it will be slower. 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.

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

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

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

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

Когда ждать это в сентенциях Голубицкого?

ЗЫ
Я злой.

Флейм задумывался как пародия на соседний "А вот не было бы Билла...", а ушло все в какие-то заумные дебри...

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

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

К>>Просто к слову. Garbage Collection — это не ЖЦ, а, скорее, ГК. То есть Городская Канализация

К>Кстати, если пользоваться этой метафорой, то в С++ельской местности канализацию не прокладывают, обходясь более или менее обустроенными индивидуальными удобствами — во дворе (Си) или в пристройке, возможно, "био" (С++).
К>А вот в городе без центральной канализации (включающей не только сортиры, но и водосборники, и ливневую канализацию) была бы не жизнь.

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

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

Здравствуйте, 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++ и дата шиты
и эти потребности не пересекаются в плане применения

Здравствуйте, 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 * не будет в один прекрасный момент приведено к какой нибудь структуре, внутри которой хранятся указатели.

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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; }
};

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