Вышли новые версии оригинальных компиляторов языков D2 и D1

>> у D есть либа для работы с сетью?

как минимум есть привязка к Qt - QtD

Qt для работы с сетью? O_o

http://www.digitalmars.com/d/2.0/phobos/std_socket.html

http://www.dsource.org/projects/tango/docs/stable/

это довольно значимое преимущество для D, go, ooc, vala и им подобных. Ты как будто никогда буст не конпелировал, и про Continuous Integration не знаешь.

языков D2 и D1

Ждём выпуска компиляторов языков Е2 и Е4

>Никаких подвохов. Просто когда я процитирую это:

Because the implementation uses reference counting, cycles of shared_ptr instances will not be reclaimed.

я хочу, чтобы цитата пришла со ссылки, которую дал ты.

Цитатой на цитату:

Конкретно по смарт-поинтерам: shared_ptr/weak_ptr отлично работают с циклическими структурами.

shared_ptr/weak_ptr

(может и про weak_ptr поглядишь заодно, раз уж читать начал)

> это довольно значимое преимущество для D, go, ooc, vala и им подобных. Ты как будто никогда буст не конпелировал, и про Continuous Integration не знаешь.

Буст компилировал (долго, но один раз - потом можно просто линковаться) , Continuous Integration занимаюсь. Проблем не встречал.

> ибо ниша, на которую он ориентирован, занята Java

хорошо - вот ты написал C, питон, джава, возьмем типичный себе десктоп на маке или винде, ну и софт - AutoCAD, фотожоп, офис, браузер, почтовик, матлаб, игры и пр. и пр., что из этого на Java/питон?

> Qt для работы с сетью? O_o

т.е. вы считаете, что по ссылке имеется все достаточное для работы с сетью и перекрывает функционал QtNetwork?

> Цитатой на цитату:

Конкретно по смарт-поинтерам: shared_ptr/weak_ptr отлично работают с циклическими структурами.

Цитата из анонимуса не катит. Можно ссылку на документацию, которая утверждает, что shared_ptr правильно работает с циклическими ссылками? То, что shared_ptr из Boost этого не умеет, мы уже выяснили.

>Цитата из анонимуса не катит. Можно ссылку на документацию, которая утверждает, что shared_ptr правильно работает с циклическими ссылками? То, что shared_ptr из Boost этого не умеет, мы уже выяснили.

«shared_ptr правильно работает с циклическими ссылками» - это твое утверждение, почему я должен искать этому подтверждение в документации? Регистранты совсем на голову анонимусам сели. Свое утверждение я процитировал дважды: связка из shared_ptr/weak_ptr работает с циклическими структурами. weak_ptr и нужен для того, чтобы два взаимных shared_ptr не циклились друг на друге.

> weak_ptr и нужен для того, чтобы два взаимных shared_ptr не циклились друг на друге.

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

Все кроме игр полностью на С или С++, ибо тяжелое наследие прошлого. А вот игры используют правильный путь: движок на С, остальное на Python (реже Ruby, Lua и т.д.).

> А вот игры используют правильный путь: движок на С, остальное на Python (реже Ruby, Lua и т.д.).

o_O вообще-то раз игры как раз в большинстве своем С++, линуксовые поделки( толсто, но правда ) не в счет

>не - для его использования надо думать, не подходит

с таким условием весь C++ сразу пролетает

> «shared_ptr правильно работает с циклическими ссылками» - это твое утверждение, почему я должен искать этому подтверждение в документации?

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

Регистранты совсем на голову анонимусам сели.

Анонимус уже не торт.

связка из shared_ptr/weak_ptr работает с циклическими структурами.

Это утверждение не имеет никакой ценности. Обычные указатели тоже работают с циклическими структурами.

Ты уверен в том, что сказал? Как раз большинство «игр» в Linux написаны на С и С++ полностью. А в индустрии люди давно уже открыли для себя скриптовые языки, у них игры на 2-3 порядка объемнее и писать все это на С или С++ никто в добром здравии не будет.

> Ты уверен в том, что сказал?

да

А в индустрии люди давно уже открыли для себя скриптовые языки, у них игры на 2-3 порядка объемнее и писать все это на С или С++ никто в добром здравии не будет.

да, даже очень давно, но:

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

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

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

Часть фразы про движок ты тоже не прочитал. Молодец, ничего не скажешь.

а) это совсем не питон( за очень редкими исключениями )

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

> Сейчас набралось достаточно игрушек с питоном в качестве скриптового языка.

Например? Я помню только старую Blade of Darkness.

Вроде же Lua сейчас в фаворе.

> Я там в скобках перечислил пару других. Конкретный язык здесь сути не меняет.

Часть фразы про движок ты тоже не прочитал. Молодец, ничего не скажешь.

ты постоянно пишешь взаимоисключающие и неправдивые вещи - то у тебя питон язык №1( что наглое 4.2 ), то оказывается есть еще и другие, то у тебя движки оказывается все сплошь на С, а С++ не используется, то оказывается, что поверх движка все сразу пишут игру на lua, например, не надоело врать? может просто скачаешь любую современную качественную игру и просто поковыряешь файлы?

>Я считаю, что ни одна реализация смарт-пойнтеров не работает правильно с циклическими ссылками. Пока что никто не привел ссылок в опровержение моей точки зрения.

правильно

Видишь, а начал-то ты с того, что смарт-поинтеры вообще бесполезны при циклических структурах. Расскажешь теперь, что значит «правильно»?

Это утверждение не имеет никакой ценности. Обычные указатели тоже работают с циклическими структурами.

Это пример так называемой толстоты. Можно написать дерево с кучей циклических ссылок, которое будет спокойно себе удаляться при отсутствии ссылок на узел, как во взрослом ГЦ. Сбацаешь на обычных указателях?

Например? Я помню только старую Blade of Darkness.

Civilization IV

Vampire: The Masquerade — Bloodlines.

> Можно написать дерево с кучей циклических ссылок, которое будет спокойно себе удаляться при отсутствии ссылок на узел, как во взрослом ГЦ.

Я не сомневаюсь, что это возможно. Меня интересует, возможно ли это с использованием _только_ shared_ptr из TR1 или Boost.

Сбацаешь на обычных указателях?

Надо будет - сбацаю без проблем.

>Я не сомневаюсь, что это возможно. Меня интересует, возможно ли это с использованием _только_ shared_ptr из TR1 или Boost.

Возможно с использованием _только_ ( shared_ptr и weak_ptr ) из tr1 или boost.

Надо будет - сбацаю без проблем.

Хоть намекни, как будешь ссылки отслеживать на обычные указатели.

>> Я не сомневаюсь, что это возможно. Меня интересует, возможно ли это с использованием _только_ shared_ptr из TR1 или Boost.

Возможно с использованием _только_ ( shared_ptr и weak_ptr ) из tr1 или boost.

weak_ptr - это наполовину ручное управление памятью. Кстати, насчет цклических ссылок - циклы сделаны как раз через weak_ptr?

Хоть намекни, как будешь ссылки отслеживать на обычные указатели.

Напишу консервативный сборщик мусора. Ах да, Boehm GC уже написан...

> Ах да, Boehm GC уже написан...

еще оказывается и C++ поддерживает:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_alloc_exC.txt

но раз вы про него не упомянули, значит он чем-то вас не устраивает?

Ах да, Boehm GC уже написан...

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

У меня разрыв шаблона. Как оно может работать?!!

> но раз вы про него не упомянули, значит он чем-то вас не устраивает?

По-моему, OpenCM использовала именно его, и это был кошмар. Насколько я помню, в нетривиальных Си-программах начинались практически неуловимые глюки, когда в них использовался Boehm. Так что... пусть лучше сборка мусора будет интегрирована в язык, и отлажена как неотъъемлимая часть рантайма.

> У меня разрыв шаблона. Как оно может работать?!!

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

Boehm GC медленный по сравнению с GC того же окамла. В чем профит от его использования, если можно просто взять окамл?

Товарищ John Harrop утверждает, что Boehm GC течет в нетривиальных случаях...

> Я считаю, что ни одна реализация смарт-пойнтеров не работает правильно с циклическими ссылками.

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

> Хоть убейте, не могу выдумать примера такого алгоритма, где у пряморукого кодера

Ни разу в жизни не встречал пряморукого кодера.

а gcc какой там сейчас версии?

Ну вроде и 4.5 заявлена:

Supported GCC versions

• GCC 4.1.x
• GCC 4.2.x
• GCC 4.3.x
• GCC 4.4.x
• GCC 4.5.x

А про плагин - честно не в теме.

> Все кроме игр полностью на С или С++, ибо тяжелое наследие прошлого.

Да ну? Работаю в молодой компании с большими инвестициями. Основной проект пишется с нуля на С++ (за исключением ГУИ фронт-енда), ибо ассемблер не тянем, а реализации на других языках не укладываются с системные требования.

Boehm GC медленный по сравнению с GC того же окамла.

Я вот не понимаю, почему Страуструп упрямится.

Сделали бы нормальную модульную систему а #include объявили как deprecated.

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

Заменили бы мерзкие шаблоны нормальной системой метапрограммирования с поддержкой с жестких/гибких фасадов и с пользовательскими ошибками компиляции.

Нормальный override, а не этот мерзкий [[override]] в конце концов.

Много чего можно было бы сделать.

спасибо

>weak_ptr - это наполовину ручное управление памятью

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

Кстати, насчет цклических ссылок - циклы сделаны как раз через weak_ptr?

Боюсь, что да.

Напишу консервативный сборщик мусора. Ах да, Boehm GC уже написан...

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

Ах да, почему ты не вспоминал о Гансе, когда утверждал, что в C++ сборщика мусора нет? Как понадобилось - сразу же нашел и козыряешь.

> Ах да, почему ты не вспоминал о Гансе, когда утверждал, что в C++ сборщика мусора нет?

Потому что это из разряда «написать». Да, либа есть, но пользуются ей редко => код не отлажен. И повторять судьбу OpenCM я не хочу.

И получили бы что-то похожее на C++/CLI ?

И получили бы что-то похожее на C++/CLI ?

C++/CLI это ведь костыль для взаимодействия двух чужеродных друг другу систем. Или я не прав?

> Например? Я помню только старую Blade of Darkness.

Frets on Fire, правда памяти выжирает и тормозит, полностью на питоне (и тоже не новая).

А кому этот D вообще нужен? Я просто не знаю, ни одного проекта на нем не встречал. Киньте пруф кто нибуть на преимущества D.

>Потому что это из разряда «написать». Да, либа есть, но пользуются ей редко => код не отлажен. И повторять судьбу OpenCM я не хочу.

Я видел и удачные примеры применения GC, но было бы удобнее, если бы встроили в язык, да. Ганс надеется, что в каком-то виде это будет реализовано разработчиками компиляторов C++0x. Он был как раз одним из авторов предложения.

>Я вот не понимаю, почему Страуструп упрямится.

Страуструп один не решает. Некоторые его предложения отклоняются комитетом.

Сделали бы нормальную модульную систему а #include объявили как deprecated.

Планируется после C++0x.

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

Бюрократия на марше.

пользовательскими ошибками компиляции.

static_assert?

Нормальный override, а не этот мерзкий [[override]] в конце концов.

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

Много чего можно было бы сделать.

C++ - заложник совместимости с существующим кодом и С. Много компаний от этого зависит, изменять что-то очень сложно. Александреску вот плюнул и переметнулся на D.

И костыль тоже :)

Думаю, что отсутствие GC - это характерная черта языков типа Си/Си++. Добавь глобальный GC и сразу все изменится. А если среда умеет GC, то почему тогда язык не гибридно-функциональный? :)

dmd умеет использовать gcc в качестве бэкенда?

Сам dmd не умеет. gcc в качестве бэкенда используется в gdc. В свою очередь, у них в документации написано следующее:

GDC is essentially divided into 3 parts: The DMD Frontend, GCC's Internals, GDC's glue code

(Я позволил себе переформатировать немного). Ну вот и получается, что собственно «DMD frontend» разрабатывается всеми в одном месте и «для всех сразу», в gdc его с минимальными изменениями используют. Поэтому работы над фронтендом языка и над самим gdc никак не связаны и друг друга заменить не могут :(

>Поэтому работы над фронтендом языка и над самим gdc никак не связаны и друг друга заменить не могут :(

Везде бардак кроме оберона.

> Добавлена поддержка HTML5.

ну ппц... теперь на каждом чайнеке и самоваре или унитазе — будут писать «теперь с поддержкой HTML5» :-D

(неважно что HTML5 там и боком непричём — но чтобы лучше продавалось надо использовать модные брэнды :))