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

E>Меня еще терзают смутные сомнения, что и код SRC (C++): конверсия UTF-8 <--> Unicode на итераторах

Автор: 0xDEADBEEF
Дата: 03.11.05

можно прорефакторить. Только там все еще хуже: в одном цикле и continue, и goto. Про такой код хочется сказать вот так же: Re: Прокоментируйте код

Автор: eao197
Дата: 30.11.05

Пожалуйста. Никогда не претендовал на "истину в последней инстанции". Более того, за варианты рефакторинга, которые меня (хотя бы) заинтрересуют, сполна отвешу оценками — минусов обещаю не ставить . Но... только за варианты рефакторинга. А то звиздеть здесь многие горазды, а вот код писать... увы...

ЗЫ. Изначально этот код был написан за час. Для С-строк.
Затем, в итоге нескольких отладочных сессий, маленько подправлен (появились '?' и goto).
Затем, как проект сдался, я его отложил в "копилку" и формализовал под итераторы.
Затем, после примерно полугода, у меня возникла блажь выложить его здесь.

Отличный пост

Из цитаты выпала подпись

Здравствуйте, Глеб Алексеев, Вы писали:

ГА>This book is dedicated, in respect and admiration, to the spirit that lives in the computer.

ГА>``I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.''

Alan J. Perlis (April 1, 1922-February 7, 1990)

0xDEADBEEF wrote:
>
> Это означает, что в развесистом исходнике, какой-то совершенно левый
> индус, которого ты и в лицо не видел, решит задействовать ТВОЮ функцию
> для СВОИХ целей. Естественно, он, как "грамотный программист" обьявит ее
> в своем гадюшнике. А потом ТЫ (через полгода), маленько подправив СВОЮ
> функцию, с удивлением обнаруживаешь что ты(именно ТЫ!!!) ЗАВАЛИЛ БИЛД!
> Или на тебя свалилась куча БАГОВ.

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

Еще, наверное, от части индусов должны помогать названия функций типа
kill_the_cow()

GlebZ wrote:
>
> Pzz>Тогда уж еще и Биллу Гейтсу — влияние его империи еще сильнее.
> Не пойдет. Гейтс — менеджер и финансист. Ему другая премия
> полагается(хотя не знаю, нужна ли она ему).

Ну, Страуструп тоже не ученый. Мы же говорили о _влиянии_. Влияние Билла
Гейтса, без сомнения, сильнее.

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

E>>Не уверен. При нынешних оптимизирующих компиляторах я бы не стал что-либо утвержать без замеров.
DEA>Обьясни плз свой оптимизм по поводу любого из вариантов. Заметь, я говорю что и твой и мой варианты по большому счету — эквивалентны. Впрочем, в понедельник я предоставлю результаты (source tree на работе находится).

Да дело в том, что недавно в темах "C++ Culture" (и некоторых других) я сделал несколько примеров на C++ с замерами производительности. Речь шла о возврате из функций объектов по значению или ссылке, а так же передачу в функцию объектов по ссылкам или значению. Так вот интересные результаты там получались. Посмотри, например, одна ветка обсуждения начинается здесь: Re[15]: С++ culture

Автор: eao197
Дата: 10.11.05

. И еще вот здесь: Re[11]: История одной оптимизации

Автор: eao197
Дата: 31.10.05

или Re[24]: История одной оптимизации

Автор: eao197
Дата: 09.11.05

. Но самый интересный тест показал eugals: Re[21]: История одной оптимизации

Автор: eugals
Дата: 09.11.05

-- там передача объектов по значению оказывается эффективнее. Так что гадать о предполагаемой производительности особенно не хочется.

DEA>А мой пессимизм основывается на... моем опыте. Посмотрим что сильнее. Кстати, полных исходников не дам — они — коммерческая тайна.

Да и не надо, у меня своих -- хоть залейся

E>>А теперь представь, если бы ты так функцию обозвал: skip_to_highest_1bit(...) -- ни комментариев, ни места лишнего, ни оверхеда в run-time.
DEA>Я не понимаю, почему я должен выносить этот кусок в отдельную функцию.
DEA>Он (а)он прост и очевиден (для тех кто знает как работать с битами, конечно) (б)используется только в одном месте (б)не требует введения дополнительных переменных. (с)логически является частью этого и только этого алгоритма.
DEA>Так, что, поподробнее: какие преимущества?

Читабельность. Мне не нравится подход, что код нужно выделять в функцию, если он используется хотя бы в двух местах. Мне нравится разделение кода на слои. Тогда вызов функции skip_to_highest_1bit() показывает читателю umodexp, что здесь происходит поиск старшего не нулевого бита. Но не опускает на уровень реализации этого поиска. Если читатель захочет узнать, как это делается, он найдет skip_to_highest_1bit и все увидит. А в твоем варианте ему сразу подсовывают реализацию, через которую ему в любом случае нужно будет пройти.

Ну и еще одно гипотетическое преимущество. Т.к. skip_to_highest_1bit() -- это другой слой логики, то этот слой оказывается изолированным от места его использования. Что позволит нам, при необходимости:
— сменить реализацию skip_to_highest_1bit() на более эффективную или по каким-то другим причинам (разбавить ее assert-ами или отладочными печатями, к примеру);
— сделать ее публичной и использовать ее в других местах.

E>>Это спорный вопрос. Меня лично функции не напрягают. Особенно количество их вызовов. А вот направление goto -- очень даже.
DEA>Еще раз: функция это ОТДЕЛЬНАЯ, НЕЗАВИСИМАЯ сущность. Она "рвет контекст", и вызывает сомнения в своем предназначении. А еще, поселившись в исходнике, она начинает ЖИТЬ САМА ПО СЕБЕ.

DEA>Это означает, что в развесистом исходнике, какой-то совершенно левый индус, которого ты и в лицо не видел, решит задействовать ТВОЮ функцию для СВОИХ целей. Естественно, он, как "грамотный программист" обьявит ее в своем гадюшнике. А потом ТЫ (через полгода), маленько подправив СВОЮ функцию, с удивлением обнаруживаешь что ты(именно ТЫ!!!) ЗАВАЛИЛ БИЛД! Или на тебя свалилась куча БАГОВ.

Не понимаю сути высказанной проблемы? Если skip_to_highest_1bit() объявлена и реализована только в твоем cpp-файле как static или в анонимном пространстве имен, то как индус сможет ее поиспользовать в другом контектсе? А если skip_to_highest_1bit() не static и не член анонимного пространства имен, или вообще объявлена в h-файле -- то о чем вообще речь идет?

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

Z>Влияние функциональных языков, на мой взгляд, и сейчас весьма заметно. C++ STL, например. Или вот вам понравилось передавать функции как параметры в Руби — это оно самое и есть. Функциональный стиль программирования так или иначе поддерживает большая часть вполне мейнстримных языков: Java Script, Python, Ruby, Perl, Lua, C#. Другое дело, что и на них большинство людей будут продолжать писать, как на своем предыдущем Впрочем, вы сами все это знаете.

Это все так, но здесь появляется другой фактор, который не следует упускать из виду: языки становятся мультипарадигменными (как C++, который много за это ругают). И успешное применение мультипарадигменного языка будет требовать от программиста других навыков, чем в чистом ООП или чистом функциональном стиле. В противном случае будут получаться монстры вроде Boost.Mpl или Boost.Lambda. А это означает, что во многих случаях придется "ломать" себя и отказываться от конструкций, которые в любимом Scheme очень удобны (какой-нибудь map или accumulate), а вот в C++ или Ruby корявы и малопонятны. Если эта ломка пройдет успешно, то и программы будут нормальными, и впечатление от работы хорошим. А если нет, то и программа будет корявой, и впечатление ужасным, и язык/среда разработки/операционка будут поноситься со страшной силой. А все потому, что со своим уставом -- в чужой монастырь.

achp,

> ПК>Например, из заметных публично, в Civilization IV используется по крайней мере Boost.Python
>
> Интересно, это по этой причине мне так и не удалось построить три чуда за один тур? (Процесс civilization4.exe съедает 2 Гб виртуальной памяти, после чего игра просто закрывается.)

Есть устойчивое подозрение, что из-за части ".Python". Впрочем, это всего лишь подозрение...

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

Pzz>Забавно, что C# это первый язык, который добился широкой известности, не будучи перед этим рожденным в юниксовской среде.
Pzz>Интересно, можно ли на этом основании делать вывод, что C# умрет, так и не осуществив возлагаемых на него надежд? Я склонен думать, что да.
Что-то мне подсказывает что ты сильно недооцениваешь мощь мелкософта.
Pzz>Микрософт при этом совершает совершенно героический поступок, поставив все фишки на технологию, которая не была 20 лет обкатана на юниксе...
Мелкософт в .NET вкладывает столько науки и денег что юниксовым языкам и не снилось. Плюс всей своей мощью проталкивает .NET в качестве основной платформы для Windows разработки, а мелкософт да еще и на своем поле...

reductor wrote:

> C>Это создает проблемы с расшареной памятью — может возникнуть race
> C>condition с другим процессом.
> Сразу видно человека, который не любит теорию. Это кстати и к
> сканированию памяти относится.

Я вам уже говорил, что знаю функционирование GC в мелочах. Вообще,
читайте соседнюю тему.

> C>С++/CLI или Boehm GC — для тех кому это нужно. В большинстве случаев GC
> C>_не_ нужен.
> Знаете, я вам вот что скажу. GC — это вещь фундаментальная для языков
> программирования. Она или есть или ее не может быть. В с++ — не может.
> Boehm проблем не решает как организационно, так и с производительностью.

Ну почему же, Mono вполне успешно живет с Boehm GC уже пять лет.

> ну дайте же мне уплотняющий GC для C++
> дайте tracing copying incremental mark-n-sweep GC, пусть он будет
> двадцатилетней давности

Смотрите tracking_ptr.hpp в xpressive. Там простой mark-and-sweep.

Или вот прямо на RSDN: http://rsdn.ru/article/cpp/GCcpp.xml

Автор(ы): Михаил Чащин
Дата: 18.11.2002

> C>Это не требует GC. Консервативный GC ведь вам не нравится, а точный GC
> C>тянет за собой слона.
> Не тянет. Если это не С++

Смотрите соседнюю тему. Специально создал для обсуждения влияния точного GC.

> C>Только не в языках с GC. Там это норма.
> в языках с GC норма — руками освобождать ресурсы?

Да. Просто ресурсами являются открытые файлы, сетевые соединения,
элементы GUI и т.п. GC работает только с памятью.

Предположим, что у нас есть объект, в одном из полей которого лежит
открытый файл. Когда этот файл будет закрыт в случае использования GC?

> C>Простите, но связь между этими двумя понятиями — одно из самых больших
> C>преимуществ. И вы после этого говорите, что знаете С++????
> Я там вам выше уже все написал про продажу прошлогоднего снега.

RTFM про RAII.

> А вот нормальный GC в С++ невозможен. А у других он просто есть.

Для С++ он просто не нужен.

> C>Нет. В Cyclone нет деструкторов с С++ной семантикой вызова.
> да вы что. серьезно? чего еще там нет?

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

> C>Да (достижение, хотя и не уникальное). Как мне такое сделать в
> OCaml? Вы
> C>*подумайте* как это сделать, и что это за собой влечет для GC.
> Что, как отщипнуть от готового буфера кусок? написать функцию new?

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

Вы так и не ответили на простейший вопрос — как мне создать OCaml-объект
так, чтобы он лежал в shared memory. Я показал как это делается в С++ —
теперь ваша очередь.

> А че для камловского GC это влечет? по-моему, вообще ничего. А по-вашему?

Кучу тараканов.

> C>Можно. Смотрите tracking_ptr.hpp из xpressive в Boost'е, например. В
> C>xpressive используется простой _точный_ GC.
> Вы видимо принципиально не понимаете о чем вообще речь.
> Что со своими аллокациями я могу разобраться, я в курсе. Но речь не
> обо мне, а о С++
> и о чужих объектах с адресной арифметикой и прочим говном.

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

> C>А нафига это в wxWidgets нужно? Там вполне хватает ручного управления
> C>памятью.
> НЕТ. МНЕ не хватает. Я не хочу ничем управлять и создавать объекты в
> строгой последовательности.
> хочу красивой жизни как в нормальных средах.

Время жизни и жизненный цикл GUI-объектов в wxWidgets задается системной
GUI-библиотекой. В частности, в многих оконных средах нельзя создавать
GUI-объекты без родителя или менять родителя уже созданных объектов.
Так же обычно нельзя передавать объекты между потоками и т.п. Это и
влечет ограничения wxWidgets. И никакой GC этому не поможет.

Можете сделать эксперимент — закомментировать содержимое всех
деструкторов в wxWidgets и добавить Boehm GC. И убедиться, что ничего не
будет работать (и вовсе не из-за утечек памяти).

> C>Как мне в OCaml перегрузить оператор обращения к члену структуры?
> Оператор. В окамле операторы — это просто функции.
> Но вообще, даже без просто определения функции:
> http://caml.inria.fr/pub/docs/manual-camlp4/manual001.html

Это препроцессор, а не языковая фича. В С++ я тоже могу вместо
операторов -> использовать функцию dereference. Будет тоже самое, но вы
тут первый начали кричать, что нужны фичи языка.

> Что вы там говорили про свое программирование на окамле? не повторите?
> Вы на нем программировали и на хаскеле еще и решили, что они — так себе?

Нет, решил что мне оно не надо — не решает практических проблем.

> Это у вас странное представление как о GC так и об окамле с хаскелем.
> И вы в упор не видите проблем, которые не только вам, но и всем вокруг
> создает С++ и весь этот закат солнца вручную.

Ну да. Закат солнца вручную в виде С/C++ создал нам проблемы в виде
почти всех современных операционных систем, прикладных программ и
остального софта. Языки с GC пока только робко пробиваются в эту область.

> Вообще здорово. А че мешает? Никогда вот delete не вызываю.

Прекрасно, заменить delete на fclose (закрытие файла) и покажите пример.
Вот вам в помощь:
http://groups.google.com/group/fa.caml/browse_frm/thread/2aa0840af287fc4c

Я не хочу закрывать файлы руками — как мне этого добиться в OCaml'е?

Я даже могу сказать как это сделать в большинстве случаев — но подожду
вашего ответа. Мне интересно как вы знаете практические сложности и
способы их решения.

> C>Ткните пальцем.
> тык:
> http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign.html

На конкретный пункт, пожалуйста.

> C>1. Скорость.
> C>2. Уровень интеграции.
> C>3. Трудоемкость сложной интеграции.
> Скорость чего? врапперов?

SOAP-wrapper'ов. Оно в тысячи раз медленнее, чем прямой вызов.

> C>Так ведь не сделали? Значит, что-то мешает.
> А еще не сделали оператор delete, наверное что-то мешает
> и auto_ptr

Так, значит полноценной интероперабельности с реальным софтом на С у нас
в FFI нет. Так и запищем...

> C>Кхм. Вообще-то JIT — это Just-In-Time компляция, не знать этого стыдно
> C>(кстати, в OCaml'е оно есть для байт-кодов). И читайте всю тему, а не
> C>одно сообщение.
> @#$%@#$% я знаю что такое JIT, я не понял какого хрена он делает в
> разговоре об окамле и его GC
> и тему не хочу читать. я и так слишком много всего прочитал уже
> лишнего и глупого.

В той теме разговор шел о Java, так что там поднималась и тема JITа.
Почитайте всю тему, наконец. То что там написано про GC точно так же
применимо и к OCaml.

> C>Ну да, если я уверен, что в моем коде нет алиасинга, то я могу дать
> хинт
> C>оптимизатору с помощью атрибута restrict.
> Я в общем-то желаю вам программировать на С++ как можно дольше. Мне
> кажется это правильно вообще, да.

Ну да, С++ — это не "выучить за два дня". На нем надо уметь писать — и
не каждому это доступно.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

Pzz>Ну, Страуструп тоже не ученый.
Кто тебе такое сказал? Создание C++ это есть исследовательская работа. И оно сильно повлияло на CS.
Pzz>Мы же говорили о _влиянии_. Влияние Билла
Pzz>Гейтса, без сомнения, сильнее.
Билли — глава корпорации, но не непосредственный создатель продуктов. А среди тех корпораций, которые наиболее повлияли на CS, правильнее назвать IBM. И я думаю, по этому показателю вряд ли кто их переплюнет.

С уважением, Gleb.

GlebZ wrote:

> C>Промышленное КОП появилось с появлением VB.
> Вопрос на засыпку, а ты можешь описать разницу между модульностью и
> компонентностью? Этот вопрос настолько узкий, что я подчас сам не
> понимаю этой разницы.

Компонентнгсть все же более узкое понятие. Компонент — это независимый
кусок функциональности, который можно переиспользовать отдельно.

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

> C>И фактически в области
> C>визуального программирования и осталось.
> Нет. В честь чего? COM объекты, которые безусловно компонентны не
> являются областью компонентного программирования. Так же как и на их
> основе DCOM.

COM-объекты все же НЕ компоненты, это скорее один из вариантов
переносимого ООП. На основе COM уже можно сделать компонентную системы
(ActiveX), но вот сами COM-объекты еще ей не являются.

> C>Влияния Вирта тут я уже не вижу
> C>- скорее развитие логически шло от визуальных контролов на формах к их
> C>представлению в виде отдельных пакетов.
> Да нет. Тут как раз именно Вирт был впереди планеты всей. На вопрос
> является ли наш постылый Oberon компонентным языком, можно ответить
> что да, является. Правда в несколько интересном формате, но это факт.

Я бы сказал, что он является модульным, но не компонентным. Например, в
визуальных компонентных языках дошли до, не имеющего аналогов в Обероне,
design-time'а и визуального биндинга свойств. Причем еще в ранних 90-х.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Компонентнгсть все же более узкое понятие. Компонент — это независимый
C>кусок функциональности, который можно переиспользовать отдельно.
Я бы сказал так, компонент — кусок функциональности использовании которого не требует перекомпиляции.

C>Модуль — это уже менее строгое понятие. Например, один компонент может
C>состоять из нескольких модулей.
Точно так же и компонент может состоять из нескольких компонент. Модуль требует перекомпиляции при компиляции используещего кода.
Но вообще компонентность — несколько маркетинговая вещь. Проблема в том, что обычная dll windows также является компонентом. Конечно, там проблем до фигищи типа проблемного контракта и dll-hell, но все условия для компонента она выполняет.

C>COM-объекты все же НЕ компоненты, это скорее один из вариантов
C>переносимого ООП. На основе COM уже можно сделать компонентную системы
C>(ActiveX), но вот сами COM-объекты еще ей не являются.
Нет. ActiveX — всего лишь стандарт наличия COM интерфейсов между сервером и клиентом для визуальных компонентов. COM — компонентен. Особенно при позднем связывании.

C>Я бы сказал, что он является модульным, но не компонентным. Например, в
C>визуальных компонентных языках дошли до, не имеющего аналогов в Обероне,
C>design-time'а и визуального биндинга свойств. Причем еще в ранних 90-х.
При использовании модулей Oberona в частности на Oberon OS(не помню об остальном возможно и без него, давно читал) перекомпиляция не требуется. А это значит, что Oberon — компонентен. Просто у меня такое впечатление, что в те времена об этом никто не знал.

С уважением, Gleb.

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

C>Много чего другого. А вы вместо зубоскальства могли бы и ткнуть пальцем
C>в доку.

C>Нет, как разместить объект в памяти, выделенной каким-то механизмом,
C>отличным от "родного".

C>Вы так и не ответили на простейший вопрос — как мне создать OCaml-объект
C>так, чтобы он лежал в shared memory. Я показал как это делается в С++ —
C>теперь ваша очередь.

Боюсь, что конкретного ответа от reductor-а ты не дождешься. Как показывают обсуждения с его участием -- это не в его стиле. А жаль, на некоторые вопросы очень хотелось бы услышать ответы.

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

[... почти все скипнуто ...]

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

1. Вы так и не прочитали как работает GC у O'Caml И почему к нему не относится то, что относится к GC у Java и MONO
2. Вы так и не прочитали что такое regions у cyclone и почему к нему не относится то, что вы говорили о ручном освобождении как памяти, так и прочих ресурсов.
3. Вы продолжаете смешивать в одну кучу (не хип, а просто кучу) свойства языка и архитектурные решения конкретных приложений, синтаксис языков и возможности стандартной или нестандартной библиотеки некоторых языков и компиляторов.
4. Почему-то вы не замечаете возможности не только в других языках, а даже в С++ разделить управление памятью и другими ресурсами и возможности реализации этого через те же монады и регионы (некоторые ссылки я кидал).
5. Почему-то считаете, что к ресурсам, предоставляемым операционно системой возможен доступ только из С++ и не хотите узнавать как это сделать из других языков/компиляторов.
6. Отказываетесь рассматривать проблему формально, что порождает потоки бессмысленного и беспощадного текста с обеих сторон, опуская уровень дискуссии ниже плинтуса.

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

C>Ну да, С++ — это не "выучить за два дня". На нем надо уметь писать — и
C>не каждому это доступно.

Совершенно и полностью согласен. Я бы даже немножко обобщил.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

C>>>Только не в языках с GC. Там это норма.

R>>в языках с GC норма — руками освобождать ресурсы?
R>>по-моему вы уже заговариваетесь.

ANS>Вообще-то, в словах "управление памятью" напрямую указано, каким именно ресурсом может оперировать сборщик мусора. Но, увы, ресурсом, является не только память программы.

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

reductor wrote:

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

Ресурсы обычно представлены в виде объектов, находящихся в локальных
переменных функции или полях объекта.

Языки с GC обычно не предлагают аналогов автоматического вызова
деструкторов в С++ для стековых переменных, так что ресурсы в локальных
переменных нужно освобождать явно в try..finally (в C# для этого сделали
даже синтаксический сахар в виде using'а).

Если хранить ресурсы в полях объекта, и надеяться на GC и финализаторы —
то получаем resource starvation под нагрузкой (не говоря уж о других
проблемах с финализацией).

--
С уважением,
Alex Besogonov (alexy@izh.com)

reductor wrote:

> Поскльку я уже сказал, что мне слишком дорого время, чтобы тратить его
> на бессмысленные и беспощадные флеймы непонятно о чем и чтобы не
> повторяться, просто сделаю несколько общих замечаний.
> 1. Вы так и не прочитали как работает GC у O'Caml И почему к нему не
> относится то, что относится к GC у Java и MONO

Простите, после ваших откровений об уникальном GC в OCaml'е, который
дошел до идеи двух поколений — я не верю, что вы что-то знаете о GC в Java.

> 2. Вы так и не прочитали что такое regions у cyclone и почему к нему
> не относится то, что вы говорили о ручном освобождении как памяти, так
> и прочих ресурсов.

Еще раз: region inference _элементарно_ делается в С++. Это не требует
НИКАКИХ изменений языка, а просто использованием существующих техник.

Используется из крупных продуктов в Apache 2 (он на С, но на С++ эта
техника переносится без всяких изменений). Читайте:
http://dev.ariel-networks.com/apr/apr-tutorial/html/apr-tutorial-3.html

> 3. Вы продолжаете смешивать в одну кучу (не хип, а просто кучу)
> свойства языка и архитектурные решения конкретных приложений,
> синтаксис языков и возможности стандартной или нестандартной
> библиотеки некоторых языков и компиляторов.

В зеркало посмотрите.

> 4. Почему-то вы не замечаете возможности не только в других языках, а
> даже в С++ разделить управление памятью и другими ресурсами и
> возможности реализации этого через те же монады и регионы (некоторые
> ссылки я кидал).

КАК???? Покажите пример, где будет использоваться _хотя бы_ нормальный
прозрачный refcounted-хэндлер для открытых файлов.

> 5. Почему-то считаете, что к ресурсам, предоставляемым операционно
> системой возможен доступ только из С++ и не хотите узнавать как это
> сделать из других языков/компиляторов.

Как мне разместить объект OCaml в shared memory?

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>reductor wrote:

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

C>Ресурсы обычно представлены в виде объектов, находящихся в локальных
C>переменных функции или полях объекта.

C>Языки с GC обычно не предлагают аналогов автоматического вызова
C>деструкторов в С++ для стековых переменных, так что ресурсы в локальных
C>переменных нужно освобождать явно в try..finally (в C# для этого сделали
C>даже синтаксический сахар в виде using'а).

C>Если хранить ресурсы в полях объекта, и надеяться на GC и финализаторы —
C>то получаем resource starvation под нагрузкой (не говоря уж о других
C>проблемах с финализацией).

Не говорите глупостей, да?

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

reductor wrote:

> Сделайте уже монаду или итератор для нужных вам ресурсов и в них все
> разруливайте.

И чем мне монада поможет, если мне надо _хранить_ открытый файл в
какой-нибудь структуре?

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

Ну так покажите.

Вот пример на С++:

#include <boost/bind.hpp>
#include <boost/shared_ptr.hpp>
#include <boost/function.hpp>
#include <stdio.h>

boost::function<void(FILE*)> file_closer(boost::bind(&fclose,_1));
typedef boost::shared_ptr<FILE> file_ptr;

file_ptr func_1()
{
    file_ptr fl(fopen("test","w"),file_closer);
    fprintf(fl.get(),"Hello, world!\n");
    return fl;
}

struct TestStruct
{
    file_ptr fl;
    TestStruct() : fl(func_1()){}

    void quack() { fprintf(fl.get(),"Quack!\n");}
};

TestStruct test()
{
    TestStruct tst;
    tst.quack();
    return tst;
}

int main()
{
    test().quack();
    //А вот здесь файл уже закрыт.
}

Результат работы:

Hello, world!
Quack!
Quack!

Ваша очередь...

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>reductor wrote:

>> Поскльку я уже сказал, что мне слишком дорого время, чтобы тратить его
>> на бессмысленные и беспощадные флеймы непонятно о чем и чтобы не
>> повторяться, просто сделаю несколько общих замечаний.
>> 1. Вы так и не прочитали как работает GC у O'Caml И почему к нему не
>> относится то, что относится к GC у Java и MONO

C>Простите, после ваших откровений об уникальном GC в OCaml'е, который
C>дошел до идеи двух поколений — я не верю, что вы что-то знаете о GC в Java.

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

>> 2. Вы так и не прочитали что такое regions у cyclone и почему к нему
>> не относится то, что вы говорили о ручном освобождении как памяти, так
>> и прочих ресурсов.

C>Еще раз: region inference _элементарно_ делается в С++. Это не требует
C>НИКАКИХ изменений языка, а просто использованием существующих техник.

Вы что, даже не набрали region inference в гугле и не посмотрели ЧТО это?
использование техник, my ass...
наберите, узнаете много нового и интересного.


C>Используется из крупных продуктов в Apache 2 (он на С, но на С++ эта
C>техника переносится без всяких изменений). Читайте:
C>http://dev.ariel-networks.com/apr/apr-tutorial/html/apr-tutorial-3.html

Great. Приехали. Выведение регионов вручную.


>> 3. Вы продолжаете смешивать в одну кучу (не хип, а просто кучу)
>> свойства языка и архитектурные решения конкретных приложений,
>> синтаксис языков и возможности стандартной или нестандартной
>> библиотеки некоторых языков и компиляторов.

C>В зеркало посмотрите.

Хамите, между прочим.
Почитайте все-таки что такое region inference, просто регионы и научитесь делать итераторы и монады для автоматического управления чего угодно.
О, кстати. Иксепшенами тоже научитесь пользоваться.
Тоже замечательная вещь для многих трюков.

Причем, все эти способы работают без "перегрузки операторов"

А так, почитайте еще про комбинаторы.

>> 4. Почему-то вы не замечаете возможности не только в других языках, а
>> даже в С++ разделить управление памятью и другими ресурсами и
>> возможности реализации этого через те же монады и регионы (некоторые
>> ссылки я кидал).

C>КАК???? Покажите пример, где будет использоваться _хотя бы_ нормальный
C>прозрачный refcounted-хэндлер для открытых файлов.

Что, мне нарисовать здесь итератор, закрывающий файл когда нужно?

>> 5. Почему-то считаете, что к ресурсам, предоставляемым операционно
>> системой возможен доступ только из С++ и не хотите узнавать как это
>> сделать из других языков/компиляторов.

C>Как мне разместить объект OCaml в shared memory?

Вызвать shmget через FFI?



Ну и истерика у вас...
Держите себя в руках, пожалуйста.