LINUX.ORG.RU

Вышла первая версия компилятора D, написанная на D

 


3

6

Сегодня состоялся очень важный релиз компилятора языка D — DMD 2.069.0. До настоящего момента компилятор D был написан на С++, однако новая версия теперь написана на самом D. Процесс конвертации исходного кода с С++ на D занял значительный промежуток времени, однако позволил многократно упростить поддержку компилятора.

Значительным улучшениям подверглась стандартная библиотека Phobos. Теперь ещё больше функций в ней были рэнджефицированы (ranges — концепция, позволяющая упростить доступ и переборку элементов структур и классов).

DMD теперь поддерживает формат mscoff, используемый в библиотеках VS2015.

Активно ведутся работы над поддержкой мобильных платформ. В настоящий момент сообщается, что рантайм языка и библиотека Phobos проходят практически все тесты на устройствах Android. О полноценной поддержке разработки под iOS пока говорить нельзя, однако благодаря усилиям проекта LDC-iphone несложные приложения на D под iOS писать можно уже сегодня.

Для пользователей Linux выложена первая пробная версия компилятора Calypso, позволяющая в D использовать практически все существующие С++-библиотеки, даже такие большие и сложные, как Qt5 и Ogre3D.

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

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

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

Новая версия сервера DCD, реализующая автодополнения исходного кода, также готова к использованию с новой версией DMD.

>>> Подробности

★★

Проверено: Shaman007 ()

Ответ на: комментарий от anonymous

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

Не хотелось бы препираться, но все же это не проблема языка.

Я сходу вообще не могу придумать легитимного применения указателей в D, кроме интерфейсинга с C-кодом (поправьте, если это не так).

tired_eyes ()
Ответ на: комментарий от asaw

No comment.

Это кого-то удивляет? Десктоп это очень много усилий (ибо GUI) и очень мало денег. Я не представляю, при каких условиях такие проекты вообще могут появиться (кроме как в виде хобби). Весь новый бизнес это SaaS в том или ином виде.

А нафига он нужен?

Это Ph. D. проект демонстрирующий нестандартный подход к JIT-типизации динамических языков. Нужен, как следствие, в научных целях ;) Ну и в качестве примера нетривиального и законченного приложения на D.

А вам шашечки или ехать?

Dicebot ()
Ответ на: комментарий от tired_eyes

Я сходу вообще не могу придумать легитимного применения указателей в D, кроме интерфейсинга с C-кодом (поправьте, если это не так).

Ну вот открыл тот самый vibe.d, первый же файл:

https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/core/args.d

Вот они указатели, родимые.

anonymous ()
Ответ на: комментарий от asaw

Почитал про этот Higgs. Оказывается, он ещё более бесполезный, чем я предполагал. Просто студенческая поделка. Его авторша даже не пыталась сделать его полезным. Зато нашла проблемы со сборкой мусора в D, которые перекочевали в этот Higgs: http://pointersgonewild.com/2014/09/09/ds-garbage-collector-problem/ В общем, всё как всегда.

asaw ★★★★★ ()
Ответ на: комментарий от asaw

В общем, всё как всегда.

Как всегда, пришёл и обосрал, да? Все вокруг бесполезны.

Vudod ★★★★★ ()
Ответ на: комментарий от Dicebot

А вам шашечки или ехать?

Мне вот именно что ехать, а не ждать пока там Александреску перепишет GC в D: Вышла первая версия компилятора D, написанная на D (комментарий) Впрочем, похоже, что ему надоело играть в изобретателя языков и он снова переключился на C++.

asaw ★★★★★ ()
Ответ на: комментарий от tired_eyes

vibe - это объемный и сложный проект, критичный к производительности.

Ага, т.е. в данном файле выполняется очень сложная и критичная к производительности задача. Ясно. Ну и значит на D безопасно надо писать только небольшие, примитивные и тормозящие программы. Спасибо что объяснили.

anonymous ()
Ответ на: комментарий от asaw

Впрочем, похоже, что ему надоело играть в изобретателя языков и он снова переключился на C++

Мне даже страшно представить, что может происходить в голове у человека, который это написал :)

Dicebot ()
Ответ на: комментарий от asaw

Попробуй представить что происходит в голове Александреску))

Примерно вот это : https://www.reddit.com/r/programming/comments/3ioy9b/andrei_alexandrescu_c_gu...

Любой, кто знаком с Александреску, удивился бы словам «снова переключился на С++».

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

Dicebot ()
Ответ на: комментарий от tired_eyes

Собственно, на Java, которая по идее должна быть «нишевым уродцем», написано много всего и разного.

Java хорош тем, что в процессе его использования как раз и выявились все недостатки GC. И развеялись все сказки, о безопасном программировании на языках с GC.

А так, он и есть нишевый уродец, который натянули на область, для него не подходящую.

anonymous ()
Ответ на: комментарий от DarkEld3r

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

Это не аргумент. Тогда не юзай классы, ведь там везде форфан вызывающиеся деструкторы и счётчики/флаги, которые пытаются нивелировать эти вызовы.

Если там треадсейв счётчики, то это не проблема кути. Проблема только в том, что это не отключается. Но не крестам об этом говорить - треадсейв в unique_ptr то же не включается.

Вообще-то я сразу оговорился, что с удобством Qt-шных строк согласен

Ты согласен не только с удобством кутишных строк, но и с убожетством стандартной библиотеки крестов.

А так же с удобством io в кути, форматирования в кути.

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

Это не проблема кути, если там утф16, то так будет всегда.

Утф слишком убог, чтобы там работала какая-то внятная индексация. утф32 никак не спасает от комбинированных символов. Тут проблема в днк.

и речь шла про остальные контейнеры

Где это она там шла. Нигде. Остальные контейнеры такие же более фичастые - я там выше писал про тейк и прочее.

Тут проблема даже не в 4-х убогих контенерах, которые есть в стл и не в том, что они убоги - проблема в том, что их нет.

Сейчас это пытаются фиксить - это типичный показтель того, что с этим есть проблема.

Что есть в стл? Хеш/бревномапа + вектор + бесполезные связные списки. Дека - убогая пародия на arraylist. Бесполезный сет - всё.

Всякое убожество, типа стек/очередь/сортированная очередь - нахрен не упало, ибо деблирует вектор и дек(arraylist).

Т.е. реально в стл есть вектор(массив) и arraylist, а так же мапа, которая нихрена не контейнер и никакие «алгоритмы» над ней нахрен делать не упало.

И чего тут? Где контейнеры? А нету их.

А для них пользы от реплейса не вижу.

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

То же самое и с твоим стл - при наличии std::sort, метод sotr() понапихан куда угодно.

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

PotentialCppTsar ()
Ответ на: комментарий от PotentialCppTsar

Но не крестам об этом говорить - треадсейв в unique_ptr то же не включается.

Слышь, пародия на царя, ты бы перестал народ смешить своими убогими потугами вещать что-то про кресты.

anonymous ()
Ответ на: комментарий от yetanother

В D есть интерфейсные файлы .di, которые компилятор генерирует на основе .d файлов.

Интересно. А они сами по себе используются для чего-то? Вряд ли, ведь только для чтения сорцов сделано?

DarkEld3r ★★★★★ ()
Ответ на: комментарий от Dicebot

Ты хоть сам то читаешь ссылки, которые даешь? Он же там русским языком пишет, что основной его доход - с консультирования, а основное консультирование - по C++:

Most consulting I do is for C++,

То есть вот чувак ушел из FB, якобы, чтобы посвятить свое время D, при этом консультирует по C++ и выступает на конференциях по C++ вместо этого. Что я не так написал, спрашивается?

asaw ★★★★★ ()
Ответ на: комментарий от anonymous

Вот ты сможешь назвать язык более сложный чем D?

Я совсем не «адепт D» и согласен, что в языке дофига всяких разных «фич», но всё-таки кажется, что порог входа (для этого не надо знать всё-всё) меньше, чем в плюсы или тот же раст.

Как ещё один пример «сложного языка» можно взять скалу.

DarkEld3r ★★★★★ ()
Последнее исправление: DarkEld3r (всего исправлений: 1)
Ответ на: комментарий от asaw

Я то выразился так. И кто поумнее, тот мысль уловил сразу.

Это ты так про себя в единственном числе?

От тебя по теме вообще ничего. Сплошное «ну ка поспорьте с моими бредовыми утверждениями».

DarkEld3r ★★★★★ ()
Ответ на: комментарий от Dicebot

Rust изначально создавался с очень чётким пониманием целевой ниши

(К сожалению?) это не совсем так. Изначально там ГЦ был, например. Да и в остальном подход и цели эволюционировали со временем.

DarkEld3r ★★★★★ ()
Ответ на: комментарий от anonymous

Rust прост как пробка

Ну не скажи. Лайфтаймы - это всё-таки новая дополнительная штука, которую надо понимать. Макросы, опять же, мощный и не такой уж простой инструмент.

DarkEld3r ★★★★★ ()
Ответ на: комментарий от Dicebot

На Rust нельзя написать ни одной программы, не имея хорошего понимания lifetime & ownership. Это автоматически делает его очень сложным.

В сложных программах это понимание всё равно нужно, иначе (на плюсах/сях) у нас будут утечки и всё такое. Так что мне кажется, что проблема преувеличена. А для простых вещей глубокого понимания и не требуется. Другое дело, что сам раст «для простых вещей» вряд ли нужен.

DarkEld3r ★★★★★ ()
Ответ на: комментарий от DarkEld3r

От тебя по теме вообще ничего. Сплошное «ну ка поспорьте с моими бредовыми утверждениями».

Я тут никого не прошу спорить с моими утверждениями. Началось с того, что я задал вопрос: Вышла первая версия компилятора D, написанная на D (комментарий) И, конечно же, толпа фанбоев и C++хейтеров не заставила себя долго ждать. Но поскольку примеров полезных программ, которые они бы написали на своих любимых язычках у них нет, они занимаются болтовней и выкладыванием содержимого своего заднего прохода. И ты к ним присоединился. Dicebot единственный пытался честно ответить. Но у него получилось совсем неубедительно.

asaw ★★★★★ ()
Последнее исправление: asaw (всего исправлений: 1)
Ответ на: комментарий от anonymous

И вот тогда они стают еще и хламом.

И тогда их имеет смысл выкинуть, но разработчики плюсов всё стоически тащат. А ведь препроцессор - это ещё одна стадия компиляции, что снижает скорость (и имеет ещё кучу недостатков)

Он сложнее С++ хотя бы потому, что он во многом надстройка из фич над ним. И этих фич много и они зачастую сложные.

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

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

Это верно что плюсы позволяют существовать целому зоопарку стилей, но это скорее зло.

KUser ()
Ответ на: комментарий от asaw

Erlang и Common Lisp - такая экзотика, что действительно нужно поискать для чего оно кому-то может быть нужно.

Вы не знаете где и когда нужен Erlang? Ну да редко, но что из этого следует?

anonymous ()
Ответ на: комментарий от KUser

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

Их нет смысла выкидывать. Зачем ломать совместимость с С и старым кодом? Это только все испортит. Есть смысл параллельно добавить модули, и этим занимаются. А когда большинство переползет на модули, можно будет уже подумать и про «выкинуть».

и многие стали возможны потому что старые костыли убрали.

Например?

Это верно что плюсы позволяют существовать целому зоопарку стилей, но это скорее зло.

В D их может быть еще больше.

anonymous ()
Ответ на: комментарий от anonymous

Вы не знаете где и когда нужен Erlang?

С чего ты взял?

Ну да редко

Я ровно это и написал.

asaw ★★★★★ ()
Ответ на: комментарий от asaw

Он же там русским языком пишет, что основной его доход - с консультирования, а основное консультирование - по C++

Да, и это был его основной доход _всё это время_. И до работы в Facebook, и во время. Эта часть его деятельности не изменилась. А вот то время, которое раньше он тратил на Facebook, теперь посвящено D Foundation. Как это можно интерпретировать в «уходит от D в сторону C++» - мне не понять :)

Если что, он и в комитете стандартизации C++ до сих пор принимает активное участие. И никогда не прекращал :)

Dicebot ()
Ответ на: комментарий от DarkEld3r

(К сожалению?) это не совсем так. Изначально там ГЦ был, например.

Я не следил за Rust с самых ранних версий, но ЕМНИП GC всегда был second-class citizen в системе памяти. Просто в более поздних версиях поняли, что и синтаксический сахар для него не нужен и можно вынести полностью в библиотеку.

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

Dicebot ()
Ответ на: комментарий от anonymous

А когда большинство переползет на модули, можно будет уже подумать и про «выкинуть».

И это никогда не происходит. А ведь C++ уже довольно старый язык. Убрав совместимость с С удалось нормально реализовать GC.
В плюсах тоже есть реализации, но беда их в том, что они работают не со всеми объектами, а только с теми, которые это поддерживают. И реализаций, на сколько знаю, не одна. Как и классов для работы со строками. К тому же совместимость с С можно было реализовать умнее: обеспечить интерфейс для взаимного вызова функций, но не делать новый язык на базе старого

В D их может быть еще больше.

Тут только время покажет.

KUser ()
Последнее исправление: KUser (всего исправлений: 1)
Ответ на: комментарий от Dicebot

Да, и это был его основной доход _всё это время_. И до работы в Facebook, и во время.

Как он может быть основным, если после ухода совокупный доход сильно меньше? Чем ты читаешь?

I've taken occasional training and consulting gigs for a long time, and I'm booked through the end of this year. The pay is good compared to the overhead, but it will be much lower than my current income.

А вот то время, которое раньше он тратил на Facebook, теперь посвящено D Foundation

А в фейсбуке он не D занимался, можно подумать.

Как это можно интерпретировать в «уходит от D в сторону C++» - мне не понять :)

Вот именно так это и можно интерпретировать.

asaw ★★★★★ ()
Ответ на: комментарий от anonymous

В D их может быть еще больше.

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

Простой пример: std::vector, new и malloc делают одно и то же (естественно, в идеологическом смысле --- массив формируют). И есть ещё есть контейнер из QT, которым многие пользуются. Более того, заставить всех пользоваться одним и тем же способом никто не сможет, потому что мигранты с C будут использовать malloc по-привычки, а мигранты с Явы --- new. А в интернете полно примеров и того и другого. И в книгах оба этих способа встречаются всё ещё чаще «правильного» std::vector. А ведь массивы --- это ключевой элемент языка.

Vudod ★★★★★ ()
Последнее исправление: Vudod (всего исправлений: 1)
Ответ на: комментарий от PotentialCppTsar

Это не аргумент. А типа буст тащить ради формата стал бы?

Вполне себе аргумент. Плюс многое в бусте хедер-онли, так что лишнее «тащить» не надо.

Ну и мой опыт говорит, что в бусте, зачастую, что-то ещё полезное находится. А чтобы Qt брали не для гуя ни разу не видел.

Было.
Тебе сказали, что кути-стиль удобен. Я объяснил почему - ты согласился. Значит аргументы были.

Нет, не было. Изначально человек сказал, что «удобно» вообще без аргументов. Уже потом их привёл ты.

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

Нет, с этим я не согласен. Чего конкретно тебе не хватало раньше появилось в 11 стандарте?

при этом форматирование, io и строки - как были говном так и остались.

Пусть так, но это не часто чувствуется. По крайней мере, в моей практике.

Насчёт форматирования - берётся буст или пишется своя наколенная поделка один раз и дальше используется.

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

Строки не то чтобы говно, просто они «не строки», а тупо «контейнеры». И как ни странно, часто этого хватает. Не везде нужна локализация и прочая хрень.

Опять же - ты не прав.

Слушай, тебе это настолько важно? Давай я уже скажу, что «я не прав» и дальше будем говорить только по делу?

Какие такие контейнеры и кому они нахрен нужны не ясно.

... Если тебе лень сходить вверх и почитать с чего всё началось, то я повторю: человек говорил именно про контейнеры. Дальше я попросил аргументировать и заранее сказал, что про строки спорить не буду. Тут ты приходишь и спрашиваешь «какие контейнеры?».

Только вот в кути их больше и они фичастей.

Ну давай посчитаем. В стл: 13 (плюс три «адаптера»), в Qt - 10. При этом у Qt в список контейнеров входит ещё, например, стек, который в стл представлен адаптером. Я что-то упустил или ты всё-таки погорячился?

В кути есть take(), который делает то, что нужно мне.

Да, в стл такого нет. Можно тривиально написать, но как минус засчитывается.

Ещё несколько примеров?

При этом выше ты называл тот же аргумент, который сам же назвал убогим - «интеграция». Ты понимаешь в чём твоя проблема, либо мне пояснить?

Возможно, я тебя понял. Но тут такой момент - последствием того, что стл предлагает такой интерфейс является возможность комбинировать контейнеры и алгоритмы из стандартной библиотеки, буста и Qt. А всякие Q_DECLARE_METATYPE полезны только при использовании Qt.

Если ты говорил о другом, то поясни.

причём интерфейс stl, которая к крестам не имеет никакого отношения, а то, что её впилили в стандарт - ничего не значитл.

Почему же не значит? По моему, значит.

В целом - мне не ясно как ты связал интерфейс stl'а и крестов. Как ты вывел за плюс stl'a совместимость с ним других реализаций алгоритмов/контейнеров и прочее.

Стл, как ни крути, часть стандарта. Это по первому вопросу.

И мне её интерфейс кажется удачным. Совместимость является плюсом по очевидным причинам. Вот под стримы никто не мимикрирует, хотя казалось бы «облегчение перехода со стандартной на левую», значит не только так мне кажется.

DarkEld3r ★★★★★ ()
Ответ на: комментарий от asaw

Потому что, скажем, servo, про который пишут в твоем this week in rust - совершенно бесполезный с точки зрения пользователя проект.

Там пишут не только про серво, это раз. Во вторых, потенциально, очень даже полезный. Ну а то, что он ещё не готов - так программы, знаешь ли, не за один день пишутся.

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

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

«Язычки», даже если на них не писать ничего «реально полезного» - это, хотя бы, разминка для ума. А от твоих вбросов на лоре и такой пользы нет.

DarkEld3r ★★★★★ ()
Ответ на: комментарий от PotentialCppTsar

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

Как ты точно себя охарактеризовал.

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

псы другой аноним

псы2 растофилы, проваливайте из треда про няшный ди. Раст не нужен, серьёзно.

anonymous ()
Ответ на: комментарий от tired_eyes

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

Всё-таки явный unsafe, как в расте, штука удобная. У D, если не ошибаюсь, тоже есть безопасное подмножество. Но кажется, оно как-то иначе устроено.

DarkEld3r ★★★★★ ()
Ответ на: комментарий от DarkEld3r

Ну а то, что он ещё не готов - так программы, знаешь ли, не за один день пишутся.

Угу, и не за один год. И не за два. И не за три.

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

Я сюда не хвастаться пришел. Кроме того, проектами на C++ нет никакой нужды хвастаться: они кругом. В отличие от растов и Ди.

«Язычки», даже если на них не писать ничего «реально полезного» - это, хотя бы, разминка для ума. А от твоих вбросов на лоре и такой пользы нет.

От твоих - и подавно. Я, кстати, не просил тебя со мной спорить.

asaw ★★★★★ ()
Ответ на: комментарий от Dicebot

Можно, но этого никто не делает :)

Ага, спасибо.

А реализация такого интерфейса как выглядеть будет? Примерно как в плюсах?

DarkEld3r ★★★★★ ()
Ответ на: комментарий от asaw

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

Откуда инфа? Судя по последним новостям, как раз наоборот - он ведь ушёл из фейсбука специально чтобы «заниматься продвижение D».

DarkEld3r ★★★★★ ()
Ответ на: комментарий от PotentialCppTsar

Это не аргумент.

Почему? Если мне совсем-совсем не нужен COW, а оверхед какой-никакой имеется, то зачем оно надо?

Если там треадсейв счётчики, то это не проблема кути.

Ну да, это дополнительные «тормоза».

Но не крестам об этом говорить - треадсейв в unique_ptr то же не включается.

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

Или ты хочешь чтобы unique_ptr ещё и доступ к содержимому лочил?

Ты согласен не только с удобством кутишных строк, но и с убожетством стандартной библиотеки крестов.

Нет, зачем ты обманываешь?

Где это она там шла. Нигде.

Ну вообще-то шла, я уже на это отвечал.

Дека - убогая пародия на arraylist. Бесполезный сет - всё.

Подробнее чем дека убога и чем сет бесполезен.

Всякое убожество, типа стек/очередь/сортированная очередь - нахрен не упало, ибо деблирует вектор и дек(arraylist).

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

И чего тут? Где контейнеры? А нету их.

А теперь расскажи что есть в Qt чего нет в стл.

То же самое и с твоим стл - при наличии std::sort, метод sotr() понапихан куда угодно.

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

DarkEld3r ★★★★★ ()
Ответ на: комментарий от KUser

И это никогда не происходит

Происходит. Так переименовали iostream.h в iostream, например. И компиляторы годами предоставляли оба хедера. Может и сейчас кто поддерживает старый вариант.

Убрав совместимость с С удалось нормально реализовать GC.

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

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

Никто не реализовывал совместимость с С, С++ изначально «С с классами».

anonymous ()
Ответ на: комментарий от Vudod

Простой пример: std::vector, new и malloc делают одно и то же (естественно, в идеологическом смысле --- массив формируют).

Да ты норкоман.

anonymous ()
Ответ на: комментарий от asaw

Угу, и не за один год. И не за два. И не за три.

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

Я, кстати, не просил тебя со мной спорить.

А меня просить не надо. (:

DarkEld3r ★★★★★ ()
Ответ на: комментарий от asaw

Ну это полный финиш - считать деньги в чужом кошельке и использовать как аргумент в споре о ЯП.

tired_eyes ()
Ответ на: комментарий от PotentialCppTsar

Вменяемых реализаций «рефлексии» нет, а раз их нет, то в С++ они не нужны.

полным-полно, только во вменяемых языках — а не с++. рефлексия и интроспекция нужна. это в С++ только проблема.

А реализации метаинфы/тайпинфо в крестах реально убоги. Не знаю с чем это связанно - с требованием стандарта, либо с реализациями. Правда не думаю, что в твоих «куллязычках» это реализовано лучше.

а ну-ка, а ну-ка. быстро, решительно: рассказывай, как бы ты сделал неубогую рефлексию/интроспекцию/интерцессию в крестах.

да так, чтобы работало для любых классов и типов, а не начиная со своего «рефлективного» класса. да так, чтобы не заниматься байтодрочерством и битхаком в раскладке класса — как в MFC (с картой сообщений) и той же самой GOODS К. Книжником и его дисера 1999 года.

что-нибудь простое, понятное придумай. да так, чтобы получилось проще чем в D через тайпинфо или в C# через аннотации.

в С++ это же можно сделать проще, же ну? или нет?

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.